הגדרת CI/CD לאפליקציות מובייל (iOS/Android)

CI/CD של אפליקציות מובייל: היכן נשבר השחרור

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

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

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

CI/CD של אפליקציות מובייל סוגר בדיוק את הנקודות האלה: תצורה ומפתחות מועברים למחסן מנוהל, הבנייה מופעלת בסביבה נקייה על כל שינוי בקוד, וגרסת בדיקה יוצאת לצוות אוטומטית. להלן — איך זה בנוי בפועל.

מה משתנה לאחר העברת הבניות לצינור

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

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

תסריטי אוטומציה כמו Fastlane מעבירים חתימה, בנייה והעלאת ארטיפקטים לתיאור מנוהל גרסאות — התהליך מפסיק להיות תלוי באדם ש"יודע איך צריך". כששחרור אורך לא חצי יום אלא חצי שעה, הצוות עובר משחרורים חודשיים לשבועיים, והתיקון מגיע למשתמשים ביום הגילוי, ולא במחזור הבא.

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

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

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

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

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

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

הקריטריון המעשי פשוט: מפתח לא ניתן להוציא מחוץ למתחם — היברידי; שחרורים נדירים והצוות קטן — ענן; בדיקות רבות וכבדות — סוכנים עצמיים עם מטמון משותף. היקף התמיכה במתאר גדל עם מספר הסביבות, ולא הפרויקטים, ולכן סכמה משולבת מונהגת יחד עם נהלי גישה לסודות הבנייה.

שלבי יישום: מביקורת בנייה ועד מסירת נהלים

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

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

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

3. הגדרת תרחישי בנייה. מגדירים בנייה ובדיקות, מטמון תלויות, מספור גרסאות, חתימה אוטומטית ויצירת קבצים מוכנים להתקנה. בנפרד בודקים שהחתימה לא נשברת כשמחליפים סביבה ושהבנייה ניתנת לשחזור ממצב נקי.

4. אוטומציה של אספקה. קושרים פרסום לערוצי בדיקה ושליחת בניות לחנויות לתרחישים, והתראות על תוצאה — לערוצי העבודה של הצוות. נוצרת אפשרות להוציא גרסה בלי שלבים ידניים ובאותה מהירות לחזור לגרסה קודמת.

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

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

מתאר בנייה, מפתחות חתימה ונהלי שחרור

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

• תצורת בנייה ל-iOS ו-Android: שלבים, תלויות, משתני סביבה. הבנייה משתחזרת בפקודה אחת על מכונה נקייה.
• סכמת מתאר הבנייה: היכן נמצאים הסוכנים, איך נשמרות תלויות במטמון, מה מופעל על כל שינוי בענף, ומה — רק על תג שחרור.
• שמירת מפתחות חתימה: מפתחות פרטיים ואישורים מוצבים במחסן מאובטח, גישה ניתנת לפי תפקידים, והם לא מגיעים למאגר ולארטיפקטים של הבנייה.
• מדיניות גישה לסביבה: נקבע מי מריץ בניות, מי מפרסם לחנויות האפליקציות, מי רואה סודות ומי מבצע להם רוטציה.
• נהלי שחרור: מספור גרסאות, סדר העלאת מספר בנייה, רשימת בדיקות לפני פרסום ורשימת אישורים שבלעדיהם השחרור לא יוצא.
• הוראות חזרה לאחור: איך להחזיר בנייה קודמת, לעצור פריסה מדורגת ולבטל שחרור מהחנות.
• מפת תמיכה: נקודות הרחבה של המתאר, מגבלות ידועות, אנשי קשר ולוח זמנים לעדכונים מתוכננים.

הנהלים מתוארים בשפת תהליכים, ולא בשפת כלי מסוים: אפשר להחליף כלי בנייה או סביבה בלי לשכתב את הכללים. במסירה עוברים על כל סעיף יחד עם המהנדס שלכם ועונים על שאלות תוך כדי.

איך השחרור הפסיק להיות תלוי במהנדס אחד

לפני השינויים שחרור אפליקציית המובייל נשען על מהנדס אחד: הוא היחיד שידע את סדר השלבים — לבנות בנייה לתצורה הנדרשת, לחתום, לשלוח להפצה. השחרור ארך יום וחצי, שיעור הבניות המוצלחות עמד על כ-55%, ולפני כל שחרור בוצעו ידנית יותר משלושים פעולות. חופשה או מחלה של האדם הזה עצרה את השחרור כולו.

מה שינינו

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

השחרור מסתכם ב-40 דקות במקום יום וחצי, שיעור הבניות המוצלחות עלה ל-92%, והפעולות הידניות הפכו לארבע. בנפרד נעלם סוג כשל בגלל אי-התאמה בין סביבות: בנייה שעברה בדיקה לא נשברת יותר בצד המפיץ בגלל גרסה אחרת של כלים או אישור חסר. חזרה לשחרור קודם — הפעלה מחדש של הצינור בתג הנדרש.

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

במה צינור בנייה שונה מבדיקות אוטומטיות במכשירים

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

בדיקות אוטומטיות במכשירים מתחילות היכן שהארטיפקט כבר נבנה — תפקידן לבדוק את התנהגות האפליקציה בפלטפורמה מסוימת.

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

בדיקות אוטומטיות במכשירים — זה רובד נפרד עם עלות משלו. אמולטורים ומכשירים אמיתיים תופסים דברים שונים: אמולטור מהיר וזול בהרצה במקביל, אבל לא משחזר מצלמה, חיישנים, ביומטריה ומאפיינים של מעטפות ספק.

לכן תרחישים קריטיים עוברים לחוות מכשירים — סט דגמים אמיתיים שבו נבדקים התקנה, עדכון מעל גרסה קודמת, עבודה ברקע והתנהגות ברשת חלשה.

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

ספקות נפוצים: חתימות, מפתחות ובניות בדיקה

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

האם חובה להחזיק שרתים עצמיים?

לא. הבנייה רצה על סוכני בנייה מנוהלים שמתרחבים לפי עומס שיא לפני שחרור — חומרה עצמית לא נדרשת. אם המדיניות הפנימית דורשת מתאר מבודד, פורסים את הבנייה בתשתית שלכם עם אותם שלבים.

אצלנו הכול נבנה ידנית — האם נצטרך לשנות את התהליך?

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

האם צריך חוות מכשירים משלנו?

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

נדון במשימה: מה נבהיר לגבי סכמת השחרור שלכם

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

• סכמת ענפים ומחזור שחרור: באיזו תדירות יוצאות בניות, מי שם תג, מה נחשב ענף שחרור, האם יש מתאר נפרד לתיקונים דחופים.
• סביבות בנייה: היכן הפרויקט נבנה כעת — על מחשבי העבודה של המהנדסים או על סוכנים ייעודיים, האם נדרשות בניות לשתי הפלטפורמות במקביל.
• חתימה ומפתחות: איך נשמרים מפתחות חתימה ופרופילי מכשירים, למי יש גישה אליהם, איך מועברים לסביבת הבנייה. זו נקודת הכשל הנפוצה ביותר באוטומציה, ואותה מנתחים ראשונה.
• ערוצי אספקה: בניות בדיקה לצוות פנימי ובודקים חיצוניים, פרסום בחנויות, פריסה מדורגת ואפשרות לחזור מגרסה ששוחררה.
• סביבות ופרמטרים: כמה סביבות, במה הן שונות, איך כעת מוגדרים כתובות שירותים ומפתחות של אינטגרציות צד שלישי, מה כבר הוצא למשתנים.
• שלבים ידניים: מה בדיוק עדיין נעשה ביד — ניהול גרסאות, בניית הערות שחרור, חיבור ארטיפקטים, שליחה לבדיקה.

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