تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
في ما يلي بعض أشكال الأتمتة النموذجية التي قد ترغب في استخدامها في نظام CI الخاص بك.
الوظائف الأساسية
الإنشاء: من خلال إنشاء مشروع من الصفر، تحرص على تجميع التغييرات الجديدة بشكل صحيح ومن توافق جميع المكتبات والأدوات مع بعضها.
عمليات التحقق من Lint أو النمط: هذه خطوة اختيارية ولكن يُنصح بها. عند فرض قواعد النمط وإجراء تحليل ثابت، يمكن أن تكون مراجعات الرموز أكثر إيجازًا وتركيزًا.
الاختبارات المحلية أو الاختبارات من جهة المضيف: يتم إجراؤها على الجهاز المحلي الذي يؤدي الإصدار. على نظام التشغيل Android، عادةً ما يكون هذا الجهاز هو جهاز JVM، لذا فهو سريع وموثوق به. كما أنها تشمل اختبارات Robolectric أيضًا.
تتوفّر خيارات متعدّدة لإجراء اختبارات معدّلة على CI:
يمكن استخدام أجهزة Gradle المُدارة لتحديد الأجهزة المطلوب استخدامها (على سبيل المثال،
"محاكي Pixel 2 على واجهة برمجة التطبيقات 27") وهي تعالج عملية إدارة حسابات الأجهزة.
تأتي معظم أنظمة CI مزوّدة بمكوِّن إضافي تابع لجهة خارجية (يُسمّى أيضًا "الإجراء" أو "الدمج" أو "الخطوة") للتعامل مع أدوات محاكاة Android.
تفويض الاختبارات المُعدّة إلى مجموعة أجهزة مثل Firebase Test Lab
تُستخدَم مزارع الأجهزة لتحقيق موثوقية عالية ويمكن تشغيلها على أجهزة محاكاة أو أجهزة مادية.
اختبارات تراجع الأداء
لمراقبة أداء التطبيق، ننصح باستخدام مكتبات مقاييس الأداء.
يتطلب إجراء اختبارات الأداء بشكل تلقائي أثناء التطوير استخدام أجهزة مادية لضمان نتائج اختبار متسقة وواقعية.
قد يستغرق تنفيذ مقاييس الأداء وقتًا طويلاً، خاصةً عندما تكون لديك تغطية كبيرة للرموز البرمجية ورحلات المستخدم التي تُجري قياسًا لها. بدلاً من تنفيذ جميع المعايير لكل ميزة مدمَجة أو الالتزام، يمكنك تنفيذها كجزء من إصدار صيانة مجدول بشكل منتظم، مثل الإصدار الليلي.
مراقبة الأداء
يمكنك رصد أي تراجع في الأداء باستخدام ميزة الملاءمة للخطوات. يحدد ملاءمة الخطوة نافذة دوارة لنتائج الإصدار السابق التي تقارنها
مقابل الإصدار الحالي. يجمع هذا النهج بين العديد من النتائج المعيارية في
مقياس واحد خاص بالانحدار. يمكنك تطبيق ملاءمة الدرج لتقليل الضوضاء أثناء اختبار الانحدار.
يحدّ ذلك من تكرار الحالات الموجبة الخاطئة التي يمكن أن تحدث عندما تكون أوقات مقياس الأداء بطيئة لإصدار واحد، ثم تتم تسويتها مرة أخرى.
عمليات التحقّق من تراجع التغطية
تُعد تغطية الاختبارات مقياسًا يمكن أن يساعدك أنت وفريقك في تحديد ما إذا كانت الاختبارات
تغطي التغيير بشكل كافٍ. ومع ذلك، ينبغي ألا يكون هو المؤشر الوحيد. من
الممارسات الشائعة إعداد فحص انحدار يفشل أو يظهر تحذيرًا عند
انخفاض التغطية بالنسبة إلى الفرع الأساسي.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ 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,["# Types of CI automation\n\nThe following are some typical forms of automation that you might like to use in\nyour CI system.\n\nBasic jobs\n----------\n\n- **Build:** By building a project from scratch, you make sure that the new\n changes compile correctly and that all libraries and tools are compatible with\n each other.\n\n- **Lint or style checks:** This is an optional but recommended step. When you\n enforce style rules and perform [static analysis](/studio/write/lint), code reviews can be more\n concise and focused.\n\n- **[Local, or host-side tests](/training/testing/local-tests):** They run on the local machine that\n performs the build. On Android this is usually the JVM, so they're fast and\n reliable. They include Robolectric tests as well.\n\nInstrumented tests\n------------------\n\n[Tests that run on emulators or physical devices](/training/testing/instrumented-tests) require some provisioning,\nwaiting for devices to boot or be connected and other operations that add\ncomplexity.\n\nThere are multiple options to run instrumented tests on CI:\n\n- [Gradle Managed Devices](/studio/test/gradle-managed-devices) can be used to define the devices to use (for example \"Pixel 2 emulator on API 27\") and it handles device provisioning.\n- Most CI systems come with a third-party plugin (also called \"action\", \"integration\" or \"step\") to handle Android emulators.\n- Delegate instrumented tests to a device farm such as [Firebase Test Lab](https://firebase.google.com/docs/test-lab). Device farms are used for their high reliability and they can run on emulators or physical devices.\n\nPerformance regression tests\n----------------------------\n\nTo monitor app performance we recommend using the [benchmark libraries](/topic/performance/benchmarking/benchmarking-overview).\nAutomation of performance tests during development requires physical devices to\nensure consistent and realistic test results.\n\nRunning benchmarks can take a long time, especially when you have high coverage\nof code and user journeys that you are benchmarking. Instead of running all\nbenchmarks for every merged feature or commit, consider executing them as part\nof a regularly scheduled maintenance build, such as a nightly build.\n\n### Monitoring performance\n\nYou can monitor performance regressions using [step fitting](https://medium.com/androiddevelopers/fighting-regressions-with-benchmarks-in-ci-6ea9a14b5c71). Step\nfitting defines a rolling window of previous build results which you compare\nagainst the current build. This approach combines several benchmark results into\none regression-specific metric. You can apply step fitting to reduce noise\nduring regression testing.\n\nThis reduces the occurrence of false positives which can occur when benchmark\ntimes are slow for a single build and then normalize again.\n\nTest coverage regression checks\n-------------------------------\n\n[Test coverage](/studio/test/test-in-android-studio#view_test_coverage) is a metric that can help you and your team decide if tests\nsufficiently cover a change. However, it shouldn't be the only indicator. It is\ncommon practice to set up a regression check that fails or shows a warning when\nthe coverage goes down relative to the base branch.\n| **Note:** The coverage generated by an instrumentation test is different from that of a unit test as bigger tests typically make fewer assertions per line of tested code and their goal is different. Consider keeping two separate coverage metrics."]]
