تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
في ما يلي بعض الميزات التي يمكنك العثور عليها في معظم أنظمة CI.
البيئة
من المهم اختيار وفهم بيئة الأجهزة والبرامج التي ينفّذ فيها النظام سير العمل. الاعتبارات المهمة لتطبيقات Android هي:
النظام الأساسي: Linux وMac وWindows وإصداراتها.
الذاكرة المتاحة: يؤدي إنشاء التطبيقات وتشغيل المحاكيات إلى استهلاك قدر كبير من ذاكرة الوصول العشوائي،
وغالبًا ما يكون من الضروري تعديل المعلَمات مثل حجم كومة الذاكرة المؤقتة في JVM
لتجنب أخطاء الخروج من الذاكرة.
البرامج المثبتة مسبقًا: توفر أنظمة CI عادةً صورًا تحتوي على مجموعة كبيرة من الأدوات المتاحة مسبقًا، مثل Java Development Kit (JDK)
وAndroid Software Development Kit (حزمة تطوير البرامج Android) وأدوات الإنشاء والأنظمة الأساسية
وأدوات المحاكاة.
بنية برنامج التشغيل ومجموعة التعليمات: ARM، x86. وهذا مهم عند
استخدام أدوات المحاكاة.
متغيرات البيئة: يتم ضبط بعضها من خلال نظام CI (على سبيل المثال:
ANDROID_HOME) ويمكنك ضبط القيمة الخاصة بك على، على سبيل المثال، تجنُّب بيانات اعتماد الترميز الثابت في سير عملك.
وثمة العديد من الجوانب الأخرى التي يجب مراعاتها، مثل عدد النوى المتوفّرة وما إذا كانت المحاكاة الافتراضية مفعّلة لتشغيل المحاكاة.
السجلّات والتقارير
عند فشل خطوة، يرسل إليك نظام CI إشعارًا ولا يسمح لك عادةً بدمج التغيير. يمكنك البحث عن الأخطاء في السجلّات لمعرفة سبب المشكلة.
بالإضافة إلى ذلك، يعمل الإنشاء والاختبار على إنشاء تقارير يتم تخزينها
كأدوات من هذا الإصدار تحديدًا. اعتمادًا على نظام CI، يمكنك استخدام
المكوّنات الإضافية لتصور نتائج تلك التقارير.
أوقات تشغيل ذاكرة التخزين المؤقت وCI
تستخدم أنظمة CI ذاكرة تخزين مؤقت لإصدار لتسريع العملية. في أبسط صورها، تحفظ هذه الخدمة جميع ملفات ذاكرة
التخزين المؤقت لنظام Gradle بعد إنشاء ناجح واستعادتها قبل إنشاء جديد. يعتمد هذا على ميزة ذاكرة التخزين المؤقت لإصدار Gradle ويجب تفعيلها في مشروعك.
تتضمن بعض الطرق لتحسين أوقات التشغيل والموثوقية:
الوحدات: يتم تحديد الوحدات التي تأثرت بالتغيير
وإنشائها واختبارها فقط.
تخطّي ذاكرات التخزين المؤقت: إذا كان الإصدار يتضمن نصوصًا برمجية عدّلها المطوّر، يمكنك تجاهل ذاكرات التخزين المؤقت للإصدار. أصبح التصميم من الصفر أكثر أمانًا.
الاختبارات المفرغة: الاختبارات المُعدّة خصوصًا، فقد يكون من المفيد تقسيم الاختبارات عبر أجهزة متعددة. ويعتمد ذلك على مشغِّل Android وأجهزة Gradle المُدارة وFirebase Test Lab.
إصدارات Shaard: يمكنك تقسيم الإصدار على عدة مثيلات للخادم.
يشير عدم الاستقرار إلى الاختبارات أو الأدوات التي تفشل بشكل متقطع. ينبغي أن تحاول دائمًا العثور على المشكلات التي تؤدي إلى إنشاء إصدارات واختبارات غير مستقرة وإصلاحها، ولكن يصعب إعادة إنتاج بعضها، خاصةً عند إجراء الاختبارات المُعدّة.
تتمثل الإستراتيجية الشائعة في إعادة محاولة إجراء الاختبارات كلما فشلت، بحد أقصى
عدد مرات إعادة المحاولة.
ليست هناك طريقة واحدة لإعداد عمليات إعادة المحاولة، حيث يمكن أن تحدث على مستويات متعددة. يوضّح الجدول التالي الإجراء الذي قد تتخذه استجابةً لفشل الاختبار غير المستقر:
تعذَّر إتمام العملية.
الإجراء
لم يستجِب المحاكي لثانية واحدة، ما أدّى إلى انتهاء المهلة.
إعادة إجراء الاختبار الذي تعذّر إكماله
تعذّر تشغيل المحاكي
إعادة تنفيذ المهمة بالكامل
حدث خطأ في الاتصال أثناء مرحلة التحقق من الرمز.
إعادة بدء سير العمل
من المهم تسجيل وتتبع أجزاء النظام غير المستقرة والاستثمار في الحفاظ على موثوقية وسرعة CI، والاعتماد فقط على إعادات المحاولة
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","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 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],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"]]
