דף זה תורגם על ידי Cloud Translation API.

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

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

שלב 1. הגדרת fastlane

מתקינים ומגדירים את fastlane.
כדי להוסיף את App Distribution להגדרות של fastlane, מריצים את הפקודה הבאה מהשורש של פרויקט ה-iOS:
```
fastlane add_plugin firebase_app_distribution
```
אם מופיעה אפשרות בפקודה, בוחרים באפשרות Option 3: RubyGems.org.

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

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

שימוש בפרטי הכניסה של חשבון השירות ב-Firebase

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

מעבירים את קובץ המפתח של חשבון השירות לפעולה firebase_app_distribution. השיטה הזו נוחה אם כבר יש לכם את קובץ המפתח של חשבון השירות בסביבת ה-build.
מגדירים את משתנה הסביבה GOOGLE_APPLICATION_CREDENTIALS כך שיצביע על קובץ המפתח של חשבון השירות. כדאי להשתמש בשיטה הזו אם כבר הגדרתם Application Default Credentials (ADC) לשירות Google אחר (למשל, Google Cloud).

במסוף Google Cloud,בוחרים את הפרויקט ויוצרים חשבון שירות חדש.
מוסיפים את התפקיד Firebase App Distribution אדמין.
יוצרים מפתח JSON פרטי ומעבירים את המפתח למיקום שגלוי לסביבת ה-build. חשוב לשמור את הקובץ הזה במקום בטוח, כי הוא מעניק הרשאת אדמין ל-App Distribution בפרויקט Firebase שלכם.
אם יצרתם את האפליקציה אחרי 20 בספטמבר 2019, אפשר לדלג על השלב הזה: במסוף Google APIs, מפעילים את Firebase App Distribution API. כשמוצגת בקשה, בוחרים את הפרויקט שיש לו את אותו שם כמו הפרויקט ב-Firebase.
מספקים או מאתרים את פרטי הכניסה לחשבון השירות:
1. כדי להעביר את המפתח של חשבון השירות לפעולה firebase_app_distribution של השורה, מגדירים את הפרמטר service_credentials_file עם הנתיב לקובץ ה-JSON של המפתח הפרטי.
2. כדי לאתר את פרטי הכניסה באמצעות ADC, מגדירים את משתנה הסביבה GOOGLE_APPLICATION_CREDENTIALS לנתיב של קובץ ה-JSON של המפתח הפרטי. לדוגמה:
```
 export GOOGLE_APPLICATION_CREDENTIALS=/absolute/path/to/credentials/file.json
```
  למידע נוסף על אימות באמצעות ADC, קראו את המאמר איך מספקים פרטי כניסה לאפליקציה.

כניסה באמצעות ה-CLI של Firebase

במאמר כניסה באמצעות ה-CLI של Firebase מוסבר איך מבצעים אימות של הפרויקט.

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

בנתיב ./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.

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

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

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

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

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, בדף 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. במאמרים הקודמים מוסבר איך לבצע אימות באמצעות פרטי כניסה של חשבון שירות.
`service_credentials_json_data`	תוכן קובץ ה-JSON של חשבון השירות ב-Google. במאמרים הקודמים מוסבר איך לבצע אימות באמצעות פרטי כניסה של חשבון שירות.
`debug`	סימון בוליאני. אפשר להגדיר את הערך הזה ל-`true` כדי להדפיס פלט מפורט של ניפוי באגים.

השלבים הבאים

במאמר רישום מכשירי iOS נוספים מוסבר איך לרשום מכשירים נוספים באופן ידני או פרוגרמטי.
שיטות מומלצות להפצת אפליקציות של Apple למבדקי QA באמצעות CI/CD ו-fastlane