60 lines
5.9 KiB
Markdown
60 lines
5.9 KiB
Markdown
---
|
|
title: Continuous Integration
|
|
localeTitle: التكامل المستمر
|
|
---
|
|
## التكامل المستمر
|
|
|
|
في التكامل الأساسي الأكثر أهمية (CI) هو منهجية تطوير رشيقة يقوم فيها المطورون بدمج التعليمات البرمجية الخاصة بهم بشكل منتظم إلى المصدر الرئيسي ، عادةً فرع `master` بعيد. من أجل ضمان عدم إدخال أي تغييرات في التكسير ، يتم تشغيل مجموعة اختبار كاملة على كل بنية حيادية لاختبار الانحدار الجديد ، أي اختبار أن الشفرة الجديدة لا تكسر الميزات الحالية القائمة.
|
|
|
|
يتطلب هذا النهج اختبارًا جيدًا لقاعدة الرمز ، مما يعني أن أغلبية الشفرة ، إن لم يكن جميعها ، لديها اختبارات تضمن أن ميزاتها تعمل بكامل طاقتها. سوف يمارس التكامل المستمر بشكل مثالي مع [التطوير](https://guide.freecodecamp.org/agile/test-driven-development) الكامل [القائم على الاختبار](https://guide.freecodecamp.org/agile/test-driven-development) .
|
|
|
|
### الخطوات الرئيسية
|
|
|
|
الخطوات الأساسية التالية ضرورية لأداء الأسلوب الحالي الأكثر القياسية للتكامل المستمر.
|
|
|
|
1. الحفاظ على الريبو المركزي وفرع `master` نشط.
|
|
|
|
يجب أن يكون هناك مستودع رمز للجميع للاندماج في وسحب التغييرات من. هذا يمكن أن يكون على جيثب أو أي عدد من خدمات تخزين الأكواد.
|
|
|
|
2. أتمتة البناء.
|
|
|
|
استخدام البرامج النصية الآلية الوقائية الوطنية أو بناء أدوات أكثر تعقيدا مثل الغزل، النخير، Webpack، أو [بلع](https://guide.freecodecamp.org/developer-tools/gulp) ، أتمتة البناء بحيث قيادة واحدة يمكن بناء نسخة تعمل بشكل كامل من المنتج، وعلى استعداد لنشرها في بيئة الإنتاج. الأفضل من ذلك ، يمكنك تضمين النشر كجزء من البنية التلقائية!
|
|
|
|
3. جعل تشغيل بناء جميع الاختبارات.
|
|
|
|
للتحقق من عدم وجود أي شيء في التعليمة البرمجية الجديدة يكسر الوظائف الموجودة ، يجب تشغيل مجموعة الاختبار الكاملة ويجب أن تفشل البنية إذا فشلت أي اختبارات ضمنها.
|
|
|
|
4. يجب على الجميع دمج التغييرات `master` كل يوم.
|
|
|
|
5. كل عملية دمج `master` يجب أن يتم بناؤها واختبارها بالكامل.
|
|
|
|
|
|
### أفضل الممارسات
|
|
|
|
هناك المزيد من أفضل الممارسات التي تستخدم أفضل ما تقدمه CI والتحديات التي تقدمها ، مثل:
|
|
|
|
1. حافظ على سرعة الإنشاء ، بحيث لا يتم إهدار الكثير من وقت التطوير في انتظار الإنشاء.
|
|
|
|
2. اختبار البنية في نسخة كاملة من بيئة الإنتاج.
|
|
|
|
|
|
إذا كان لديك ، على سبيل المثال ، تطبيقًا تم نشره على شيء ما مثل Heroku أو Digital Ocean ، فبإمكانك إجراء اختبار منفصل هناك يمكنك من خلاله نشر اختبارات ، للتأكد من أنها لا تعمل فقط في الاختبارات ولكن في بيئة إنتاج حقيقية. يجب أن تكون بيئة الاختبار هذه متطابقة وظيفياً مع بيئة الإنتاج الفعلية ، وذلك لضمان دقة الاختبار.
|
|
|
|
3. اجعل من السهل البقاء على اطلاع دائم.
|
|
|
|
يجب على الكوداء السحب بانتظام من الفرع `master` للحفاظ على دمج رمزهم مع التغييرات من فريقهم. يجب أيضًا إتاحة الريبو لأصحاب المصلحة مثل مديري المنتجات ، أو مديري الشركات ، أو العملاء الرئيسيين في بعض الأحيان ، بحيث يكون الجميع قادرين على رؤية التقدم بسهولة.
|
|
|
|
4. احتفظ بسجلات للبنود ، بحيث يمكن للجميع الاطلاع على نتائج أي بنية معينة ، سواء نجحت أو فشلت ، ومن أو ما أدخل تغييرات جديدة.
|
|
|
|
5. أتمتة النشر.
|
|
|
|
|
|
حافظ على تحديث تطبيقك تمامًا مع أي تغييرات جديدة عن طريق أتمتة النشر في بيئة الإنتاج كمرحلة أخيرة من عملية الإنشاء ، بعد اجتياز جميع الاختبارات ونجاح عملية اختبار الاختبار في استنساخ بيئة الإنتاج.
|
|
|
|
### خدمات CI
|
|
|
|
توجد الكثير من الخدمات للتعامل مع عملية التكامل المستمر بالنسبة لك ، والتي يمكن أن تجعل من السهل إنشاء خط أنابيب CI صلب أو عملية بناء. عند تقييم ذلك ، ضع في اعتبارك عوامل مثل الميزانية وسرعة الإنشاء ونوع المشروع الذي تعمل عليه. تقدم بعض الخدمات ، مثل [Travis CI](https://travis-ci.org) خدمات مجانية للمشروعات مفتوحة المصدر ، والتي يمكن أن تجعلها خيارًا سهلاً لمشاريع كهذه ، ولكن قد يكون لها أبطأ من الخدمات الأخرى ، مثل [Circle CI](https://circleci.com/) أو [Codeship](https://codeship.com/) ، على سبيل المثال لا الحصر.
|
|
|
|
#### معلومات اكثر:
|
|
|
|
إدخال ويكيبيديا في [التكامل المستمر](https://en.wikipedia.org/wiki/Continuous_integration) . |