ריכזנו כאן כמה תכונות שאפשר למצוא ברוב מערכות ה-CI.
סביבה
חשוב לבחור את סביבת החומרה והתוכנה שבה המערכת מבצעת את תהליך העבודה, ולהבין אותה. שיקולים חשובים לגבי אפליקציות ל-Android:
- פלטפורמה: Linux, Mac, Windows והגרסאות שלהם.
- זיכרון זמין: פיתוח אפליקציות והפעלת מכונות וירטואליות יכולים להשתמש ב-RAM רב, ולרוב צריך לשנות את הפרמטרים כמו גודל האוסף של JVM כדי למנוע שגיאות של חוסר זיכרון.
- תוכנה מותקנת מראש: בדרך כלל, מערכות CI מספקות קובצי אימג' עם אוסף גדול של כלים שכבר זמינים, כמו Java Development Kit (JDK), Android Software Development Kit (SDK), כלי build, פלטפורמות ומדמילים.
- ארכיטקטורה וקבוצת הוראות של ה-Runner: ARM, x86. חשוב לזכור זאת כשמשתמשים במהדמרים.
- משתני סביבה: חלק מהם מוגדרים על ידי מערכת ה-CI (לדוגמה:
ANDROID_HOME), ואפשר להגדיר משתנים משלכם, למשל כדי להימנע מהטמעה של פרטי כניסה בתהליך העבודה.
יש עוד הרבה היבטים שצריך להביא בחשבון, כמו מספר הליבות הזמינות והאם הופעלה וירטואליזציה להפעלת אמוללטורים.
יומנים ודוחות
אם שלב מסוים נכשל, מערכת ה-CI תודיע לכם ובדרך כלל לא תאפשר לכם למזג את השינוי. כדי לברר מה השתבש, מחפשים שגיאות ביומני המערכת.
בנוסף, תהליך ה-build והבדיקה יוצר דוחות שבדרך כלל נשמרים בתור ארטיפקטים של ה-build הספציפי. בהתאם למערכת ה-CI, אפשר להשתמש ב-plugins כדי להציג גרפית את התוצאות של הדוחות האלה.
זמני הריצה של מטמון ו-CI
מערכות CI משתמשות במטמון build כדי לזרז את התהליך. בצורתם הפשוטה ביותר, הם שומרים את כל קובצי המטמון של Gradle אחרי build מוצלח ומשחזרים אותם לפני build חדש. הפעולה הזו מבוססת על התכונה build cache של Gradle, וצריך להפעיל אותה בפרויקט.
כמה דרכים לשיפור זמני הריצה והאמינות:
- מודולים: זיהוי המודולים שמושפעים משינוי, ופיתוח ובדיקה שלהם בלבד.
- דילוג על מטמון: אם ה-build כולל סקריפטים שמפתח שינה, מתעלמים מהמטמון של ה-build. עדיף לבנות מחדש מהתחלה.
- חלוקה של בדיקות: במיוחד בדיקות עם מכשירי מדידה, כדאי לחלק את הבדיקות לכמה מכשירים. התכונה הזו נתמכת על ידי Android Runner, Gradle Managed Devices ו-Firebase Test Lab.
- חלוקה של גרסאות build: אפשר לפצל את הגרסה היציבה למספר מכונות שרת.
- מטמון מרוחק: אפשר גם להשתמש במטמון המרוחק של Gradle.
ניסיון חוזר בבדיקות שנכשלו
'תנודות' מתייחסות לבדיקות או לכלים שנכשלים לסירוגין. תמיד כדאי לנסות למצוא ולפתור את הבעיות שגורמות לבדיקות ול-builds לא יציבים, אבל חלק מהן קשה לשחזר, במיוחד כשמריצים בדיקות עם מכשירי מדידה. אסטרטגיה נפוצה היא לנסות שוב את הפעלות הבדיקה בכל פעם שהן נכשלות, עד למספר ניסיונות חוזרים מקסימלי.
אין דרך אחת להגדיר ניסיונות חוזרים, כי הם יכולים להתרחש בכמה רמות. בטבלה הבאה מפורטות הפעולות שאפשר לבצע בתגובה לכשלים לא עקביים בבדיקות:
נכשלה |
פעולה |
|---|---|
הסימולטור לא הגיב למשך שנייה, מה שגרם לזמן קצוב לתפוגה |
הרצת הבדיקה שנכשלה מחדש |
אי אפשר להפעיל את המהדר |
הפעלה מחדש של כל המשימה |
אירעה שגיאה בחיבור במהלך שלב הבדיקה של הקוד |
הפעלה מחדש של תהליך העבודה |
חשוב לתעד ולעקוב אחרי החלקים במערכת שאינם יציבים, ולהשקיע בשמירה על מהימנות ומהירות של CI, תוך שימוש רק בניסיונות חוזרים