קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
ריכזנו כאן כמה תכונות שאפשר למצוא ברוב מערכות ה-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: אפשר לפצל את הגרסה היציבה למספר מכונות שרת.
'תנודות' מתייחסות לבדיקות או לכלים שנכשלים לסירוגין. תמיד כדאי לנסות למצוא ולפתור את הבעיות שגורמות לבדיקות ול-builds לא יציבים, אבל חלק מהן קשה לשחזר, במיוחד כשמריצים בדיקות עם מכשירי מדידה.
אסטרטגיה נפוצה היא לנסות שוב את הפעלות הבדיקה בכל פעם שהן נכשלות, עד למספר ניסיונות חוזרים מקסימלי.
אין דרך אחת להגדיר ניסיונות חוזרים, כי הם יכולים להתרחש בכמה רמות. בטבלה הבאה מפורטות הפעולות שאפשר לבצע בתגובה לכשלים לא עקביים בבדיקות:
נכשלה
פעולה
הסימולטור לא הגיב למשך שנייה, מה שגרם לזמן קצוב לתפוגה
הרצת הבדיקה שנכשלה מחדש
אי אפשר להפעיל את המהדר
הפעלה מחדש של כל המשימה
אירעה שגיאה בחיבור במהלך שלב הבדיקה של הקוד
הפעלה מחדש של תהליך העבודה
חשוב לתעד ולעקוב אחרי החלקים במערכת שאינם יציבים, ולהשקיע בשמירה על מהימנות ומהירות של CI, תוך שימוש רק בניסיונות חוזרים
דוגמאות התוכן והקוד שבדף הזה כפופות לרישיונות המפורטים בקטע רישיון לתוכן. Java ו-OpenJDK הם סימנים מסחריים או סימנים מסחריים רשומים של חברת Oracle ו/או של השותפים העצמאיים שלה.
עדכון אחרון: 2025-07-27 (שעון UTC).
[[["התוכן קל להבנה","easyToUnderstand","thumb-up"],["התוכן עזר לי לפתור בעיה","solvedMyProblem","thumb-up"],["סיבה אחרת","otherUp","thumb-up"]],[["חסרים לי מידע או פרטים","missingTheInformationINeed","thumb-down"],["התוכן מורכב מדי או עם יותר מדי שלבים","tooComplicatedTooManySteps","thumb-down"],["התוכן לא עדכני","outOfDate","thumb-down"],["בעיה בתרגום","translationIssue","thumb-down"],["בעיה בדוגמאות/בקוד","samplesCodeIssue","thumb-down"],["סיבה אחרת","otherDown","thumb-down"]],["עדכון אחרון: 2025-07-27 (שעון UTC)."],[],[],null,["# CI features\n\nThe following are some features that you can find in most CI systems.\n\nEnvironment\n-----------\n\nIt's important to choose and understand the hardware and software environment in\nwhich the system executes the workflow. Important considerations for Android\napplications are:\n\n- **Platform**: Linux, Mac, Windows, and their versions.\n- **Available memory**: Building apps and running emulators can use a lot of RAM and it's often necessary to tweak parameters such as the JVM's heap size to avoid out-of-memory errors.\n- **Preinstalled software**: CI systems usually provide images with a large collection of tools already available, such as the Java Development Kit (JDK), the Android Software Development Kit (SDK), build tools, platforms and emulators.\n- **Runner architecture and instruction set**: ARM, x86. This is important when using emulators.\n- **Environment variables** : Some are set by the CI system (for example: `ANDROID_HOME`) and you can set your own to, for example, avoid hardcoding credentials in your workflow.\n\nThere are many other aspects you should consider, such as the number of cores\navailable, and whether virtualization is enabled to run emulators.\n\nLogs and reports\n----------------\n\nWhen a step fails, the CI system notifies you and usually doesn't let you merge\nthe change. To find out what has gone wrong, look for errors in the logs.\n\nAdditionally, building and testing generates reports that are usually stored as\nartifacts of that particular build. Depending on the CI system, you can use\nplugins to visualize the results of those reports.\n\nCache and CI run times\n----------------------\n\nCI systems use a build cache to speed up the process. In its simplest form, they\nsave all the Gradle cache files after a successful build and restore them before\na new one. This relies on [Gradle's build cache](https://docs.gradle.org/current/userguide/build_cache.html) feature and should be\nenabled in your project.\n| **Note:** take into account the time that it takes for the cache to download as, if the cache becomes too big and it contains more than is necessary, it could be detrimental to the overall build time.\n\nSome ways to improve run times and reliability include:\n\n- **Modules**: Detecting which modules are affected by a change and only building and testing those.\n- **Skip caches**: If the build includes scripts that a developer has modified, ignore the build caches. It's safer to build from scratch.\n- **Shard tests**: Especially instrumented tests, it can be helpful to shard tests across multiple devices. This is supported by the Android runner, Gradle Managed Devices and Firebase Test Lab.\n- **Shard builds**: You can shard the build across multiple server instances.\n- **Remote cache** : You can also use [Gradle's remote cache](https://docs.gradle.org/current/userguide/build_cache.html).\n\nRetry failed tests\n------------------\n\nFlakiness refers to tests or tools that fail intermittently. You should always\ntry to find and fix the problems that generate flaky builds and tests, but some\nof them are difficult to reproduce, especially when running instrumented tests.\nA common strategy is to retry test runs whenever they fail, up to a maximum\nnumber of retries.\n\nThere is no single way to configure retries, as they can occur at multiple\nlevels. The following table outlines the action you might take in response to a\nflaky test failure:\n\n| Failure | Action |\n|--------------------------------------------------------------|-----------------------|\n| Emulator was unresponsive for a second, triggering a timeout | Rerun the failed test |\n| Emulator failed to boot | Rerun the whole task |\n| There was a connection error during the code checkout phase | Restart the workflow |\n\nIt's important to log and keep track of which parts of the system are flaky and\ninvest in keeping CI reliable and fast, only relying on retries"]]
