אתם יכולים להפיץ גרסאות build לבודקים באמצעות fastlane, פלטפורמת קוד פתוח שמאפשרת ליצור אפליקציות ל-iOS ול-Android ולפרסם אותן באופן אוטומטי. היא פועלת לפי הוראות פשוטות שמוגדרות ב-Fastfile
. אחרי שמגדירים את fastlane ואת Fastfile
, אפשר לשלב את App Distribution עם ההגדרות של fastlane.
שלב 1. הגדרת נתיב מהיר
כדי להוסיף את App Distribution להגדרות של fastlane, מריצים את הפקודה הבאה מהשורש של פרויקט ה-iOS:
fastlane add_plugin firebase_app_distribution
אם מופיעה אפשרות בפקודה, בוחרים באפשרות
Option 3: RubyGems.org
.
שלב 2. אימות באמצעות Firebase
כדי להשתמש בפלאגין של fastlane, תחילה צריך לבצע אימות באמצעות הפרויקט ב-Firebase באחת מהדרכים הבאות. כברירת מחדל, הפלאגין של fastlane מחפש פרטי כניסה מ-CLI של Firebase אם לא נעשה שימוש בשיטת אימות אחרת.
שלב 3. הגדרת קובץ מהיר והפצת האפליקציה
- בנתיב
./fastlane/Fastfile
, יש להוסיף חסימתfirebase_app_distribution
. צריך להשתמש בפרמטרים הבאים כדי מגדירים את ההתפלגות:פרמטרים של firebase_app_distribution app
חובה רק אם האפליקציה לא מכילה קובץ תצורה של Firebase (
GoogleService-Info.plist
): מזהה האפליקציה ב-Firebase. שלך אפשר למצוא את מזהה האפליקציה במסוף Firebase, דף ההגדרות הכלליות.app: "1:1234567890:ios:0a1b2c3d4e5f67890"
googleservice_info_plist_path
הנתיב לקובץ
GoogleService-Info.plist
, ביחס לנתיב המוצר שהועבר לארכיון. כברירת מחדל, הערך מוגדר כ-GoogleService-Info.plist
.הקובץ משמש לאחזור מזהה האפליקציה שלכם ב-Firebase אם הפרמטר
app
לא צוין.firebase_cli_token
אסימון רענון שמודפס כשמאמתים את סביבת ה-CI באמצעות Firebase CLI (קריאה) שימוש ב-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
כדי שה-build יהיה זמין לבודקים, צריך להריץ את הנתיב שלך:
fastlane <lane>
הערך המוחזר של הפעולה הוא גיבוב (hash) שמייצג את הגרסה שהועלתה.
הגיבוב הזה זמין גם באמצעות lane_context[SharedValues::FIREBASE_APP_DISTRO_RELEASE]
.
למידע נוסף על השדות הזמינים בגיבוב הזה, אפשר לעיין במאמר
מאמרי העזרה של API ל-REST.
הפלאגין של fastlane יוצר את הקישורים הבאים אחרי העלאת הגרסה. הקישורים האלה עוזרים לכם לנהל קובצי בינארי ולוודא שבדיקות ומפתחים אחרים מקבלים את הגרסה הנכונה:
- קישור למסוף Firebase שבו מוצגת גרסה אחת. אפשר לשתף את הקישור הזה עם מפתחים אחרים בארגון.
- קישור לגרסה באפליקציית הבודקים (קליפ אינטרנט ל-iOS) שמאפשר לבודקים לצפות בנתוני הגרסה ולהתקין את האפליקציה למכשיר שלהם. כדי להשתמש בקישור, למבצע הבדיקה צריכה להיות גישה למהדורה.
- קישור חתום שמוריד ומתקין ישירות את קובץ ה-binary של האפליקציה (קובץ IPA). תוקף הקישור יפוג אחרי שעה.
אחרי הפצת ה-build, הוא יהיה זמין לוח הבקרה של App Distribution במסוף Firebase למשך 150 ימים. כשתוקף ה-build נמצא ב-30 יום ממועד התפוגה, מופיעה הודעת תפוגה במסוף וברשימת גרסאות ה-build של הבודק במכשיר הבדיקה שלו.
בודקים שלא הוזמנו בעבר לבדוק את האפליקציה מקבלים אימייל הזמנות להתחיל. בודקים קיימים מקבלים התראות באימייל ש-build חדש מוכן לבדיקה. במאמר הגדרה כבודק מוסבר איך להתקין את אפליקציית הבדיקה. אפשר לעקוב את הסטטוס של כל בודק כדי לקבוע אם הוא קיבל ואם הם הורידו את האפליקציה מסוף Firebase.
(אופציונלי) כדי להגדיל באופן אוטומטי את מספר ה-build בכל פעם שיוצרים גרסה חדשה ב-App Distribution, אפשר להשתמש בפעולה 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 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
כדי לאחזר מידע על הגרסה האחרונה של האפליקציה בהפצת אפליקציה,
כולל מידע על גרסת האפליקציה, נתוני הגרסה וזמן היצירה. תרחישים לדוגמה
כוללים הגדלה אוטומטית של הגרסה והעברת הגרסה
הערות מהגרסה הקודמת.
הערך המוחזר של הפעולה הוא גיבוב (hash) שמייצג את הגרסה האחרונה.
אפשר למצוא את הגיבוב הזה גם באמצעות 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 באמצעות Firebase CLI (קריאה) שימוש ב-CLI עם מערכות CI לקבלת מידע נוסף). |
service_credentials_file
|
הנתיב לקובץ ה-JSON של חשבון השירות ב-Google. במאמרים הקודמים מוסבר איך לבצע אימות באמצעות פרטי כניסה של חשבון שירות. |
service_credentials_json_data
|
תוכן קובץ ה-JSON של חשבון השירות ב-Google. במאמרים הקודמים מוסבר איך לבצע אימות באמצעות פרטי כניסה של חשבון שירות. |
debug
|
דגל בוליאני. אפשר להגדיר את האפשרות הזו ל- |
השלבים הבאים
כדי לרשום מכשירים נוספים באופן ידני או פרוגרמטי: לרשום מכשירי iOS נוספים.
מידע על שיטות מומלצות להפצה של אפליקציות של Apple לבודקי QA באמצעות CI/CD ו-Fastlane.