הפצת אפליקציות ל-iOS לבודקים באמצעות fastlane

אפשר להפיץ גרסאות build לבודקים באמצעות fastlane, פלטפורמה בקוד פתוח שמבצעת אוטומציה של תהליך הפיתוח וההפצה של אפליקציות ל-iOS ול-Android. הפלטפורמה פועלת לפי הוראות פשוטות שמוגדרות בקובץ Fastfile. אחרי שמגדירים את fastlane ואת קובץ Fastfile, אפשר לשלב את App Distribution בהגדרות של fastlane.

שלב 1. הגדרת fastlane

  1. התקנה והגדרה של fastlane.

  2. כדי להוסיף את App Distribution להגדרות של fastlane, מריצים את הפקודה הבאה מתיקיית הבסיס של פרויקט iOS:

    fastlane add_plugin firebase_app_distribution

    אם הפקודה מציגה אפשרות, בוחרים באפשרות Option 3: RubyGems.org.

שלב 2. אימות באמצעות Firebase

כדי להשתמש בתוסף fastlane, קודם צריך לבצע אימות בפרויקט Firebase באחת מהדרכים הבאות. כברירת מחדל, הפלאגין fastlane מחפש פרטי כניסה מ-CLI של Firebase אם לא נעשה שימוש בשיטת אימות אחרת.

שלב 3. הגדרת Fastfile והפצת האפליקציה

  1. ב./fastlane/Fastfile נתיב, מוסיפים בלוק firebase_app_distribution. כדי להגדיר את ההפצה, משתמשים בפרמטרים הבאים:
    פרמטרים של הפצת אפליקציות ב-Firebase
    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

    מכשירי הבדיקה שרוצים להריץ עליהם בדיקות של הסוכן לבדיקת אפליקציות.

    אפשר לציין את מכשירי הבדיקה כרשימה של מפרטי מכשירים שמופרדים באמצעות נקודה-ופסיק:

    test_devices: "model=shiba,version=34,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

    אם מגדירים את האפשרות הזו כשמריצים בדיקות של App Testing agent, הפקודה תתחיל את הבדיקות ואז תחזור מיד במקום לחכות שהן יסתיימו. כדי לראות את תוצאות הבדיקה, צריך להיכנס למסוף 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>

ערך ההחזרה של הפעולה הוא גיבוב שמייצג את הגרסה שהועלתה. הגיבוב הזה זמין גם באמצעות lane_context[SharedValues::FIREBASE_APP_DISTRO_RELEASE]. מידע נוסף על השדות הזמינים בגיבוב הזה מופיע במאמרי העזרה של ה-API בארכיטקטורת REST.

פלאגין fastlane מציג את הקישורים הבאים אחרי העלאת הגרסה. הקישורים האלה עוזרים לכם לנהל קבצים בינאריים ולוודא שלבודקים ולמפתחים אחרים יש את הגרסה הנכונה:

  • קישור למסוף Firebase שבו מוצג פריט תוכן יחיד. אפשר לשתף את הקישור הזה עם מפתחים אחרים בארגון.
  • קישור לגרסה בחוויית הבודקים (קובץ webclip ל-iOS) שמאפשר לבודקים לראות את הערות הגרסה ולהתקין את האפליקציה במכשיר שלהם. כדי להשתמש בקישור, הבודקים צריכים לקבל גישה לגרסה.
  • קישור חתום שמוריד ישירות את הקובץ הבינארי של האפליקציה (קובץ IPA) ומתקין אותו. התוקף של הקישור יפוג אחרי שעה.

אחרי שמפיצים את הגרסה, היא זמינה בApp Distribution לוח הבקרה של Firebase המסוף למשך 150 ימים. כשהתוקף של הגרסה עומד לפוג תוך 30 יום, מופיעה הודעה על תפוגה במסוף וברשימת הגרסאות של הבודק במכשיר הבדיקה שלו.

בודקים שלא הוזמנו קודם לבדוק את האפליקציה מקבלים הזמנות באימייל כדי להתחיל. הבודקים הקיימים מקבלים התראות באימייל על כך שגרסת build חדשה מוכנה לבדיקה. במאמר איך מצטרפים לבודקים מוסבר איך להתקין את אפליקציית הבדיקה. אתם יכולים לעקוב אחרי הסטטוס של כל בודק כדי לדעת אם הוא אישר את ההזמנה והוריד את האפליקציה ב-Firebase Console.

(אופציונלי) כדי להגדיל באופן אוטומטי את מספר ה-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_latest_release
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. בתיעוד הקודם מוסבר איך מבצעים אימות באמצעות פרטי כניסה של חשבון שירות.

service_credentials_json_data

תוכן קובץ ה-JSON של חשבון שירות ב-Google. בתיעוד הקודם מוסבר איך מבצעים אימות באמצעות פרטי כניסה של חשבון שירות.

debug

דגל בוליאני. אפשר להגדיר את הערך הזה ל-true כדי להדפיס פלט מפורט של ניפוי באגים.

השלבים הבאים