با مجموعهها، منظم بمانید
ذخیره و طبقهبندی محتوا براساس اولویتهای شما.
موارد زیر برخی از ویژگی هایی است که می توانید در اکثر سیستم های CI بیابید.
محیط زیست
انتخاب و درک محیط سخت افزاری و نرم افزاری که سیستم در آن گردش کار را اجرا می کند، مهم است. ملاحظات مهم برای برنامه های اندروید عبارتند از:
پلتفرم : لینوکس، مک، ویندوز و نسخه های آنها.
حافظه موجود : ساخت برنامه‌ها و شبیه‌سازهای در حال اجرا می‌توانند از مقدار زیادی RAM استفاده کنند و اغلب لازم است پارامترهایی مانند اندازه پشته JVM را تغییر دهید تا از خطاهای خارج از حافظه جلوگیری شود.
نرم‌افزار از پیش نصب‌شده : سیستم‌های CI معمولاً تصاویر را با مجموعه‌ای از ابزارهای موجود از قبل در دسترس هستند، مانند کیت توسعه جاوا (JDK)، کیت توسعه نرم‌افزار اندروید (SDK)، ابزارهای ساخت، پلتفرم‌ها و شبیه‌سازها.
معماری Runner و مجموعه دستورالعمل : ARM، x86. این در هنگام استفاده از شبیه سازها مهم است.
متغیرهای محیطی : برخی از آنها توسط سیستم CI تنظیم می‌شوند (به عنوان مثال: ANDROID_HOME ) و شما می‌توانید متغیرهای خود را طوری تنظیم کنید که، برای مثال، از اعتبارنامه‌های کدگذاری سخت در گردش کار خود اجتناب کنید.
بسیاری از جنبه های دیگر وجود دارد که باید در نظر بگیرید، مانند تعداد هسته های موجود، و اینکه آیا مجازی سازی برای اجرای شبیه سازها فعال است یا خیر.
گزارش ها و گزارش ها
هنگامی که یک مرحله با شکست مواجه می شود، سیستم CI به شما اطلاع می دهد و معمولاً به شما اجازه ادغام تغییر را نمی دهد. برای اینکه بفهمید چه مشکلی رخ داده است، به دنبال خطاها در گزارش‌ها بگردید.
علاوه بر این، ساخت و آزمایش گزارش هایی تولید می کند که معمولاً به عنوان مصنوعات آن ساختمان خاص ذخیره می شوند. بسته به سیستم CI، می توانید از افزونه ها برای تجسم نتایج آن گزارش ها استفاده کنید.
زمان اجرای کش و CI
سیستم های CI از یک build cache برای سرعت بخشیدن به فرآیند استفاده می کنند. در ساده‌ترین شکل، آنها تمام فایل‌های کش Gradle را پس از یک ساخت موفق ذخیره می‌کنند و آنها را قبل از یک فایل جدید بازیابی می‌کنند. این به ویژگی کش ساخت Gradle متکی است و باید در پروژه شما فعال شود.
برخی از راه‌های بهبود زمان اجرا و قابلیت اطمینان عبارتند از:
ماژول ها : تشخیص اینکه کدام ماژول ها تحت تأثیر یک تغییر قرار می گیرند و فقط آن ها را ساخته و آزمایش می کنند.
رد شدن از حافظه پنهان : اگر ساخت شامل اسکریپت هایی است که توسعه دهنده آن ها را اصلاح کرده است، کش های ساخت را نادیده بگیرید. ساختن از ابتدا امن تر است.
تست‌های شارد : به‌ویژه تست‌های ابزاردار، می‌توان تست‌های تکه‌ای را در چند دستگاه مختلف انجام داد. این توسط رانر اندروید، دستگاه های مدیریت شده Gradle و آزمایشگاه تست Firebase پشتیبانی می شود.
Shard builds : می توانید بیلد را در چندین نمونه سرور به اشتراک بگذارید.
پوسته پوسته شدن به تست ها یا ابزارهایی اطلاق می شود که به طور متناوب شکست می خورند. همیشه باید سعی کنید مشکلاتی را که ساختارها و تست‌های پوسته پوسته ایجاد می‌کنند پیدا کرده و برطرف کنید، اما بازتولید برخی از آنها دشوار است، مخصوصاً هنگام اجرای آزمایش‌های ابزاردار. یک استراتژی متداول این است که هر زمان که اجرای آزمایشی با شکست مواجه شد، تا حداکثر تعداد دفعات تکرار، دوباره امتحان کنید.
هیچ راه واحدی برای پیکربندی تلاش های مجدد وجود ندارد، زیرا می توانند در سطوح مختلف رخ دهند. جدول زیر اقداماتی را که ممکن است در پاسخ به شکست تست پوسته پوسته انجام دهید، تشریح می کند:
شکست
اقدام
شبیه ساز برای یک ثانیه پاسخ نمی دهد و باعث ایجاد مهلت زمانی می شود
تست شکست خورده را دوباره اجرا کنید
شبیه ساز بوت نشد
کل کار را دوباره اجرا کنید
در مرحله تسویه کد یک خطای اتصال وجود داشت
گردش کار را مجدداً راه اندازی کنید
مهم است که وارد سیستم شوید و ردیابی کنید که کدام قسمت‌های سیستم ضعیف هستند و فقط با تکیه بر تلاش‌های مجدد، روی اطمینان و سریع نگه داشتن CI سرمایه‌گذاری کنید.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","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-29 بهوقت ساعت هماهنگ جهانی."],[],[],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"]]
