אתם יכולים להפיץ גרסאות build לבודקים באמצעות fastlane, פלטפורמת קוד פתוח שמאפשרת ליצור אפליקציות ל-iOS ול-Android ולפרסם אותן באופן אוטומטי. הוא פועל לפי הוראות פשוטות שמוגדרות ב-Fastfile
. אחרי שמגדירים את fastlane ואת Fastfile
, אפשר לשלב את App Distribution בהגדרות של fastlane.
שלב 1. הגדרת fastlane
כדי להוסיף את App Distribution להגדרות של fastlane, מריצים את הפקודה הבאה מהשורש של פרויקט ה-iOS:
fastlane add_plugin firebase_app_distribution
אם בפקודה מוצגת אפשרות, בוחרים באפשרות
Option 3: RubyGems.org
.
שלב 2. אימות באמצעות Firebase
כדי להשתמש בפלאגין של נתיב מהיר, צריך לבצע אימות בפרויקט Firebase באחת מהדרכים הבאות. כברירת מחדל, הפלאגין לנתיב מהיר מחפש פרטי כניסה מ-CLI של Firebase אם לא משתמשים בשיטת אימות אחרת.
שלב 3. הגדרת קובץ מהיר והפצת האפליקציה
- בנתיב
./fastlane/Fastfile
, מוסיפים בלוקfirebase_app_distribution
. כדי להגדיר את ההתפלגות, משתמשים בפרמטרים הבאים:פרמטרים של firebase_app_distribution app
חובה רק אם האפליקציה לא מכילה קובץ תצורה של Firebase (
GoogleService-Info.plist
): מזהה האפליקציה ב-Firebase. אפשר למצוא את מזהה האפליקציה במסוף Firebase, בדף General Settings.app: "1:1234567890:ios:0a1b2c3d4e5f67890"
googleservice_info_plist_path
הנתיב לקובץ
GoogleService-Info.plist
, ביחס לנתיב המוצר שעבר לארכיון. כברירת מחדל, הערך מוגדר כ-GoogleService-Info.plist
.הקובץ משמש לאחזור מזהה האפליקציה שלכם ב-Firebase אם הפרמטר
app
לא צוין.firebase_cli_token
אסימון רענון שמודפס כשמאמתים את סביבת ה-CI באמצעות ה-CLI Firebase (מידע נוסף זמין במאמר שימוש ב-CLI עם מערכות CI).
service_credentials_file
הנתיב לקובץ ה-JSON של חשבון השירות של Google. למעלה מוסבר איך לבצע אימות באמצעות פרטי כניסה של חשבון שירות.
ipa_path
החלפה של
apk_path
(הוצא משימוש). הנתיב המוחלט לקובץ ה-IPA שרוצים להעלות. אם לא צוין מיקום, המערכת של fastlane תזהה את המיקום של הקובץ מהנתיב שבו הוא נוצר.release_notes
release_notes_file
נתוני הגרסה של גרסת ה-build הזו.
אפשר לציין את נתוני הגרסה באופן ישיר:
release_notes: "Text of release notes"
לחלופין, אפשר לציין את הנתיב לקובץ טקסט פשוט:
release_notes_file: "/path/to/release-notes.txt"
testers
testers_file
כתובות האימייל של הבוחנים שרוצים להזמין.
אפשר לציין את הבודקים כרשימה של כתובות אימייל מופרדות בפסיקים:
testers: "ali@example.com, bri@example.com, cal@example.com"
לחלופין, אפשר לציין את הנתיב לקובץ טקסט פשוט שמכיל רשימה של כתובות אימייל שמופרדות בפסיקים:
testers_file: "/path/to/testers.txt"
groups
groups_file
קבוצות הבודקים שרוצים להזמין (מידע נוסף זמין במאמר ניהול בודקים). הקבוצות מצוינות באמצעות
כינויים של קבוצות , שאפשר לחפש במסוף Firebase.אפשר לציין את הקבוצות כרשימה מופרדת בפסיקים:
groups: "qa-team, trusted-testers"
לחלופין, אפשר לציין את הנתיב לקובץ טקסט פשוט שמכיל רשימה של שמות קבוצות מופרדים בפסיקים:
groups_file: "/path/to/groups.txt"
test_devices
test_devices_file
סוגי ההפצה הבאים הם חלק מתכונת הבטא של הבודק האוטומטי.
מכשירי הבדיקה שבהם רוצים להפיץ את גרסאות ה-build (מידע נוסף זמין בקטע בדיקות אוטומטיות).
אפשר לציין את המכשירים לבדיקה כרשימה של מכשירים לבדיקה מופרדים בנקודה-פסיק:
test_devices: "model=shiba,version=34,locale=en,orientation=portrait;model=b0q,version=33,locale=en,orientation=portrait"
לחלופין, אפשר לציין את הנתיב לקובץ טקסט פשוט שמכיל רשימה של מכשירי בדיקה המופרדים בנקודה-פסיק:
test_devices_file: "/path/to/test-devices.txt"
test_username
שם המשתמש להתחברות אוטומטית לשימוש במהלך הבדיקות האוטומטיות.
test_password
test_password_file
הסיסמה להתחברות האוטומטית, שתשמש במהלך בדיקות אוטומטיות.
לחלופין, אפשר לציין את הנתיב לקובץ טקסט פשוט שמכיל סיסמה:
test_password_file: "/path/to/test-password.txt"
test_username_resource
שם המשאב של שדה שם המשתמש להתחברות אוטומטית, שישמש במהלך הבדיקות האוטומטיות.
test_password_resource
שם המשאב של שדה הסיסמה לכניסה אוטומטית, שישמש במהלך הבדיקות האוטומטיות.
test_non_blocking
להריץ בדיקות אוטומטיות באופן אסינכרוני. תוצאות הבדיקה האוטומטית מוצגות במסוף Firebase.
debug
סימון בוליאני. אפשר להגדיר את הערך הזה ל-
true
כדי להדפיס פלט מפורט של ניפוי באגים.
לדוגמה:
platform :ios do desc "My awesome app" lane :distribute do build_ios_app(...) # build_ios_app is a built-in fastlane action. release = firebase_app_distribution( app: "1:123456789:ios:abcd1234", testers: "tester1@company.com, tester2@company.com", release_notes: "Lots of amazing new features to test out!" ) end end
כדי שהגרסה היציבה תהיה זמינה לבודקים, מריצים את הערוץ:
fastlane <lane>
הערך המוחזר של הפעולה הוא גיבוב שמייצג את הגרסה שהועלו.
הגיבוב הזה זמין גם באמצעות lane_context[SharedValues::FIREBASE_APP_DISTRO_RELEASE]
.
מידע נוסף על השדות הזמינים בגיבוב הזה זמין במסמכי התיעוד של ה-API ל-REST.
אחרי העלאת הגרסה, הפלאגין של הנתיב המהיר יוצר את הקישורים הבאים. הקישורים הבאים עוזרים לנהל קבצים בינאריים ולהבטיח שלבודקים ולמפתחים אחרים את הגרסה הנכונה:
- קישור למסוף Firebase שבו מוצגת גרסה אחת. אפשר לשתף את הקישור הזה עם מפתחים אחרים בארגון.
- קישור למהדורה בחוויית הבדיקה (קליפס אינטרנט ל-iOS) שמאפשר לבודקים לראות את הערות המוצר ולהתקין את האפליקציה במכשיר שלהם. כדי להשתמש בקישור, למבצע הבדיקה צריכה להיות גישה למהדורה.
- קישור חתום שמוריד ומתקין ישירות את קובץ ה-binary של האפליקציה (קובץ IPA). תוקף הקישור יפוג אחרי שעה.
אחרי הפצת ה-build, הוא יהיה זמין בלוח הבקרה App Distribution שבמסוף Firebase למשך 150 ימים. כשתוקף ה-build נמשך 30 יום מתאריך התפוגה, מופיעה הודעה על התפוגה במסוף וברשימת גרסאות ה-build של הבודקים במכשיר הבדיקה.
בודקים שלא הוזמנו בעבר לבדוק את האפליקציה יקבלו הזמנה באימייל כדי להתחיל. בודקים קיימים מקבלים התראות באימייל על כך שגרסת build חדשה מוכנה לבדיקה. במאמר הגדרה כבודק מוסבר איך להתקין את אפליקציית הבדיקה. אתם יכולים לעקוב אחרי הסטטוס של כל בודק כדי לבדוק אם הוא קיבל את ההזמנה ואם הוא הוריד את האפליקציה במסוף Firebase.
(אופציונלי) כדי להגדיל באופן אוטומטי את מספר ה-build בכל פעם שיוצרים גרסה חדשה ב'הפצת אפליקציה', אפשר להשתמש בפעולה firebase_app_distribution_get_latest_release
ובפעולה increment_build_number
.
הקוד הבא מדגים איך להגדיל את מספר ה-build באופן אוטומטי:
lane :increment_version do
latest_release = firebase_app_distribution_get_latest_release(
app: "<your Firebase app ID>"
)
increment_build_number({ build_number: latest_release[:buildVersion].to_i + 1 })
end
מידע נוסף על התכונה הזו של הפלאגין של Fastlane זמין במאמר קבלת מידע על הגרסה האחרונה של האפליקציה.
שלב 4 (אופציונלי). ניהול הבודקים של ההפצה
אפשר להוסיף ולסמן בודקים לפרויקט או לקבוצה באמצעות הקובץ Fastfile
או על ידי הפעלה ישירה של פעולות fastlane. הפעלת פעולות ישירות מבטלת את הערכים שהוגדרו ב-Fastfile
.
אחרי שמוסיפים בודק לפרויקט Firebase, אפשר להוסיף אותו לגרסאות ספציפיות. לבודקים שהוסרו מפרויקט Firebase כבר לא תהיה גישה לגרסאות בפרויקט, אבל הם עשויים לשמור על גישה לגרסאות שלכם למשך פרק זמן מסוים.
אם יש לכם מספר גדול של בודקים, כדאי להשתמש בקבוצות.
שימוש ב-Fastfile
# Use lanes to add or remove testers from a project. lane(:add_testers) do firebase_app_distribution_add_testers( emails: "foo@google.com,bar@google.com" # or file: "/path/to/testers.txt" group_alias: "qa-team" # (Optional) add testers to this group ) end lane(:remove_testers) do firebase_app_distribution_remove_testers( emails: "foo@google.com,bar@google.com" # or file: "/path/to/testers.txt" group_alias: "qa-team" # (Optional) remove testers from this group only ) end
# Add or remove testers with the terminal
$ fastlane add_testers
$ fastlane remove_testers
הפעלת פעולות ב-Fastlane
fastlane run firebase_app_distribution_create_group display_name:"QA Team" alias:"qa-team"
fastlane run firebase_app_distribution_add_testers group_alias:"qa-team" emails:"foo@google.com,bar@google.com"
fastlane run firebase_app_distribution_remove_testers group_alias:"qa-team" emails:"foo@google.com,bar@google.com"
fastlane run firebase_app_distribution_delete_group alias:"qa-team"
אפשר גם לציין את הבדיקות באמצעות --file="/path/to/testers.txt
במקום --emails
.
המשימות firebase_app_distribution_add_testers
ו-firebase_app_distribution_remove_testers
מקבלות גם את הארגומנטים הבאים:
project_name
: מספר הפרויקט ב-Firebase.group_alias
(אופציונלי): אם מציינים את השדה הזה, הבודקים מצורפים לקבוצה שצוינה (או שהם מוסרים ממנה).service_credentials_file
: הנתיב לקובץ פרטי הכניסה לשירות Google.firebase_cli_token
: אסימון אימות ל-CLI של Firebase.
הערכים service_credentials_file
ו-firebase_cli_token
הם אותם ארגומנטים שבהם משתמשת פעולת ההעלאה.
שלב 5 (אופציונלי). איך מקבלים מידע על הגרסה האחרונה של האפליקציה
תוכלו להשתמש בפעולה firebase_app_distribution_get_latest_release
כדי לאחזר מידע על הגרסה האחרונה של האפליקציה בהפצת אפליקציה, כולל מידע על גרסת האפליקציה, נתוני הגרסה וזמן היצירה. תרחישים לדוגמה כוללים הגדלה אוטומטית של הגרסה והעברת הערות המוצר מהגרסה הקודמת.
ערך ההחזרה של הפעולה הוא גיבוב שמייצג את הגרסה האחרונה.
אפשר לקבל את הגיבוב הזה גם באמצעות lane_context[SharedValues::FIREBASE_APP_DISTRO_LATEST_RELEASE]
.
מידע נוסף על השדות הזמינים בגיבוב הזה זמין במסמכי התיעוד של ה-API ל-REST.
פרמטרים
פרמטרים של firebase_app_distribution_get_previous_release | |
---|---|
app
|
חובה רק אם האפליקציה לא מכילה קובץ תצורה של Firebase ( app: "1:1234567890:ios:0a1b2c3d4e5f67890" |
googleservice_info_plist_path
|
הנתיב לקובץ
הקובץ ישמש לקבלת מזהה האפליקציה ב-Firebase אם לא ציינתם את הפרמטר |
firebase_cli_token
|
אסימון רענון שמודפס כשמאמתים את סביבת ה-CI באמצעות ה-CLI של Firebase (מידע נוסף זמין במאמר שימוש ב-CLI עם מערכות CI). |
service_credentials_file
|
הנתיב לקובץ ה-JSON של חשבון השירות ב-Google. במאמרים הקודמים מוסבר איך לבצע אימות באמצעות פרטי כניסה של חשבון שירות. |
service_credentials_json_data
|
תוכן קובץ ה-JSON של חשבון השירות ב-Google. במאמרים הקודמים מוסבר איך לבצע אימות באמצעות פרטי כניסה של חשבון שירות. |
debug
|
סימון בוליאני. אפשר להגדיר את הערך |
השלבים הבאים
במאמר רישום מכשירי iOS נוספים מוסבר איך לרשום מכשירים נוספים באופן ידני או פרוגרמטי.
שיטות מומלצות להפצת אפליקציות של Apple למבדקי QA באמצעות CI/CD ו-fastlane