استعدادًا لبدء الدورة التدريبية "CI / CD على AWS و Azure و Gitlab" ، قمنا بإعداد ترجمة لمواد مفيدة لك.
يعتبر التكامل المستمر (CI) والتسليم المستمر (CD) ثقافة ، ومجموعة من المبادئ والممارسات التي تمكن المطورين من نشر تغييرات البرامج بشكل متكرر وموثوق.
CI / CD هي إحدى ممارسات DevOps . كما ينطبق أيضًا على الممارسات الرشيقة : تتيح أتمتة النشر للمطورين التركيز على تلبية متطلبات العمل وجودة التعليمات البرمجية والأمان.
تعريف CI / CD
التكامل المستمر هو منهجية تطوير ومجموعة من الممارسات التي يتم فيها إجراء تغييرات صغيرة على الكود مع التزامات متكررة. ونظرًا لأن معظم التطبيقات الحديثة يتم تطويرها باستخدام منصات وأدوات متنوعة ، فهناك حاجة إلى آلية تكامل واختبار التغييرات التي يتم إدخالها.
من الناحية الفنية ، يتمثل هدف CI في توفير طريقة متسقة وآلية لإنشاء التطبيقات وحزمها واختبارها. مع عملية تكامل مستمرة مبسطة ، من المرجح أن يقوم المطورون بالتزامات متكررة ، والتي بدورها ستساعد في تحسين الاتصال وتحسين جودة البرامج.
يبدأ التسليم المستمر حيث ينتهي التكامل المستمر. تعمل على أتمتة نشر التطبيقات في بيئات مختلفة: يعمل معظم المطورين مع بيئة الإنتاج وبيئات التطوير والاختبار.
تساعد أدوات CI / CD على تخصيص إعدادات بيئة معينة تم تكوينها أثناء النشر. كما تقوم أتمتة CI / CD بتنفيذ الطلبات الضرورية لخوادم الويب وقواعد البيانات والخدمات الأخرى التي قد تحتاج إلى إعادة التشغيل أو تنفيذ بعض الإجراءات الإضافية عند نشر التطبيق.
التكامل المستمر والتسليم المستمر يحتاجان إلى اختبار مستمرلأن الهدف النهائي هو تطوير تطبيقات عالية الجودة. غالبًا ما يتم تنفيذ الاختبار المستمر كمجموعة من الاختبارات الآلية المختلفة (الانحدار والأداء وغيرها) التي يتم تنفيذها في خط أنابيب CI / CD.
تسمح الممارسة الناضجة لـ CI / CD بالنشر المستمر: عندما يمر الرمز بنجاح عبر خط أنابيب CI / CD ، يتم نشر التجميعات تلقائيًا في بيئة الإنتاج. يمكن للفرق التي تمارس التسليم المستمر تحمل تكاليف النشر يوميًا أو حتى كل ساعة. ومع ذلك ، تجدر الإشارة هنا إلى أن التسليم المستمر ليس مناسبًا لجميع تطبيقات الأعمال .
التكامل المستمر يحسن الاتصال والجودة
التكامل المستمر هو منهجية تطوير تعتمد على العمليات والأتمتة المنظمة. مع تنفيذ التكامل المستمر ، غالبًا ما يلتزم المطورون بتعليماتهم البرمجية في مستودع الكود المصدري. وتتبع معظم الفرق قاعدة الالتزام مرة واحدة على الأقل يوميًا. التغييرات الصغيرة أسهل في اكتشاف العيوب والمشاكل المتنوعة من التغييرات الكبيرة التي تم العمل عليها على مدى فترة طويلة من الزمن. بالإضافة إلى ذلك ، فإن العمل مع دورات الالتزام القصيرة يقلل من فرص قيام العديد من المطورين بتغيير نفس الجزء من التعليمات البرمجية ، مما قد يؤدي إلى اندماج التعارضات.
غالبًا ما تبدأ الفرق التي تنفذ التكامل المستمر بإعداد نظام التحكم في الإصدار وتحديد سير العمل. على الرغم من حقيقة أن الالتزامات تتم بشكل متكرر ، فإن تنفيذ الميزات وإصلاح الأخطاء يمكن أن يستغرق وقتًا طويلاً. هناك عدة طرق للتحكم في الميزات والكود الجاهز.
يستخدم العديد من الأشخاص علامات الميزات - وهي آلية لتشغيل الوظائف وإيقافها في وقت التشغيل. يتم تغليف الوظيفة التي لا تزال قيد التطوير بعلامات الميزات ويتم نشرها من الفرع الرئيسي إلى الإنتاج ، ولكن يتم تعطيلها حتى تصبح جاهزة للاستخدام بالكامل. حسب دراسة حديثة63 في المائة من الفرق التي تستخدم ميزة العلم قامت بتحسين قابلية الاختبار وتحسين جودة البرامج. هناك أدوات خاصة للعمل مع أعلام الميزات ، مثل CloudBees Rollout و Optimizely Rollouts و LaunchDarkly ، والتي تتكامل مع CI / CD وتسمح بالتكوين على مستوى الميزة.
هناك طريقة أخرى للعمل مع الميزات وهي استخدام الفروع في نظام التحكم في الإصدارات. في هذه الحالة ، تحتاج إلى تحديد نموذج التفريع (على سبيل المثال ، Gitflow) ووصف كيفية دخول الكود في فروع التطوير والاختبار والإنتاج. بالنسبة للميزات ذات دورة التطوير الطويلة ، يتم إنشاء فروع ميزات منفصلة. بعد الانتهاء من العمل على الميزة ، يقوم المطورون بدمج التغييرات من فرع الميزة في فرع التطوير الرئيسي. يعمل هذا النهج جيدًا ، ولكن قد يكون غير مريح إذا تم تطوير العديد من الميزات في نفس الوقت.
مرحلة البناء هي أتمتة حزم البرامج المطلوبة وقاعدة البيانات والمكونات الأخرى. على سبيل المثال ، إذا كنت تقوم بتطوير تطبيق Java ، فسيقوم CI بحزم جميع الملفات الثابتة مثل HTML و CSS و JavaScript جنبًا إلى جنب مع تطبيق Java والبرامج النصية لقواعد البيانات.
لن تقوم CI فقط بحزم جميع مكونات البرامج وقواعد البيانات ، ولكنها ستقوم أيضًا تلقائيًا بإجراء اختبارات الوحدة وأنواع الاختبارات الأخرى. يتيح هذا الاختبار للمطورين الحصول على تعليقات تفيد بأن التغييرات التي أجروها لم تفسد أي شيء.
تسمح لك معظم أدوات CI / CD ببدء إنشاء يدويًا أو بناءً على التزام أو وفقًا لجدول زمني. تحتاج الفرق إلى مناقشة جدول الإنشاء الذي يناسبها بناءً على حجم الفريق والالتزامات اليومية المتوقعة ومعايير أخرى. من المهم أن تكون عمليات الالتزام والبناء سريعة ، وإلا فقد تصبح الإنشاءات الطويلة عقبة أمام المطورين الذين يحاولون الالتزام بسرعة وبشكل متكرر.
الاختبار المستمر هو أكثر من أتمتة الاختبار
تساعد أطر عمل الاختبار الآلي مهندسي ضمان الجودة في تصميم وتشغيل وأتمتة أنواع مختلفة من الاختبارات التي تساعد المطورين على تتبع نجاح البناء. يشمل الاختبار الاختبارات الوظيفية التي تم تطويرها في نهاية كل سباق ودمجها في اختبارات الانحدار للتطبيق بأكمله. تُبلغ اختبارات الانحدار الفريق إذا كانت تغييراتهم قد كسرت شيئًا في مكان آخر في التطبيق.
أفضل الممارسات هي مطالبة المطورين بتشغيل كل أو جزء من اختبارات الانحدار في بيئتهم المحلية. سيضمن ذلك أن يلتزم المطورون برمز تم التحقق منه بالفعل.
اختبارات الانحدار هي مجرد البداية. اختبار الأداء ، واختبار API ، وتحليل الكود الثابت ، واختبار الأمان - يمكن أيضًا أتمتة هذه الأنواع وغيرها من الاختبارات. النقطة الأساسية هي القدرة على تشغيل هذه الاختبارات من سطر الأوامر ، أو عبر خطاف ويب ، أو من خلال خدمة ويب وإرجاع نتيجة التنفيذ: هل كان الاختبار ناجحًا أم لا.
لا يشمل الاختبار المستمر الأتمتة فحسب ، بل يشمل أيضًا دمج الاختبار الآلي في خط أنابيب CI / CD. يمكن أن تكون اختبارات الوحدة والاختبارات الوظيفية جزءًا من CI وتحديد المشكلات قبل أو أثناء إطلاق خط أنابيب CI. غالبًا ما تكون الاختبارات التي تتطلب نشرًا كاملاً للبيئة ، مثل اختبار الأداء والأمان ، جزءًا من القرص المضغوط ويتم تشغيلها بعد نشر البنيات في البيئات المستهدفة.
يقوم خط أنابيب الأقراص المضغوطة بأتمتة تسليم التغييرات إلى بيئات مختلفة
التسليم المستمر هو النشر التلقائي لتطبيق ما إلى بيئته المستهدفة. عادةً ما يعمل المطورون مع بيئة تطوير واختبار واحدة أو أكثر حيث يتم نشر التطبيق للاختبار والمراجعة. لهذا الغرض ، يتم استخدام أدوات CI / CD مثل Jenkins و CircleCI و AWS CodeBuild و Azure DevOps و Atlassian Bamboo و Travis CI.
يتكون خط أنابيب القرص المضغوط النموذجي من خطوات الإنشاء والاختبار والنشر. تتضمن خطوط الأنابيب الأكثر تعقيدًا الخطوات التالية:
- استرجاع التعليمات البرمجية من التحكم بالمصادر وتنفيذ بناء
- تكوين البنية التحتية المؤتمتة من خلال نهج البنية التحتية كرمز.
- نسخ الكود إلى البيئة المستهدفة.
- تحديد متغيرات البيئة للبيئة المستهدفة.
- (-, API-, ).
- , , .
- .
- .
على سبيل المثال ، في ملف Jenkins ، تم تحديد ناقل Jenkins ، والذي يصف الخطوات المختلفة مثل التجميع (البناء) والاختبار (الاختبار) والنشر (النشر). يصف أيضًا متغيرات البيئة والمفاتيح السرية والشهادات والمعلمات الأخرى التي يمكن استخدامها في مراحل خطوط الأنابيب. يقوم قسم النشر بتكوين معالجة الأخطاء والإشعارات.
في مسار القرص المضغوط الأكثر تعقيدًا ، قد تكون هناك خطوات إضافية ، مثل مزامنة البيانات وأرشفة موارد المعلومات وتثبيت التحديثات والتصحيحات. تدعم أدوات CI / CD عادةً المكونات الإضافية. على سبيل المثال ، لدى Jenkins أكثر من 1500 مكون إضافي للتكامل مع منصات الطرف الثالث ، لتوسيع واجهة المستخدم ، والإدارة ، وإدارة كود المصدر ، والبناء.
عند استخدام أداة CI / CD ، يجب على المطورين التأكد من تكوين جميع المعلمات خارج التطبيق عبر متغيرات البيئة. تسمح لك أدوات CI / CD بتعيين قيم هذه المتغيرات ، وإخفاء كلمات المرور ومفاتيح الحساب ، وتخصيصها أثناء النشر لبيئة معينة.
توجد أيضًا في أدوات القرص المضغوط لوحات المعلومات والتقارير. في حالة فشل الإنشاء أو التسليم ، يتم إعلامهم بذلك. من خلال دمج القرص المضغوط مع أدوات التحكم في الإصدار والأدوات الرشيقة ، يكون من السهل العثور على تغييرات التعليمات البرمجية وقصص المستخدم المضمنة في الإصدار.
تنفيذ خطوط أنابيب CI / CD باستخدام Kubernetes و Serverless Architectures
تستخدم العديد من الفرق التي تستخدم خطوط أنابيب CI / CD في السحب حاويات مثل Docker وأنظمة التزامن مثل Kubernetes . تساعد الحاويات في توحيد معايير التعبئة والتسليم وتبسيط التوسع وتدمير البيئات المتقلبة.
هناك العديد من الخيارات لمشاركة الحاويات والبنية التحتية كرمز وخطوط أنابيب CI / CD. يمكنك معرفة المزيد حول هذا الأمر في المقالات Kubernetes مع Jenkins و Kubernetes مع Azure DevOps .
تعد الحوسبة بدون خادم طريقة أخرى لنشر التطبيقات وتوسيع نطاقها. في بيئة بدون خادم ، تتم إدارة البنية التحتية بالكامل بواسطة مزود السحابة ، ويستهلك التطبيق الموارد حسب الحاجة وفقًا لإعداداته. على سبيل المثال ، في AWS ، يتم تشغيل التطبيقات بدون خادم من خلال وظائف AWS Lambda ، والتي يمكن دمج نشرها في خط أنابيب Jenkins CI / CD باستخدام مكون إضافي.
يتيح CI / CD نشر التعليمات البرمجية بشكل متكرر
لذا ، دعونا نلخص. حزم CI واختبارات يبني وإعلام المطورين إذا حدث خطأ ما. يقوم القرص المضغوط تلقائيًا بنشر التطبيقات وتشغيل اختبارات إضافية.
تم تصميم خطوط أنابيب CI / CD للمؤسسات التي تحتاج إلى إجراء تغييرات متكررة على التطبيقات من خلال عملية تسليم موثوقة. بالإضافة إلى توحيد البنيات وتطوير الاختبارات وأتمتة عمليات النشر ، نحصل على سير عمل شامل لنشر تغييرات التعليمات البرمجية. يتيح تطبيق CI / CD للمطورين التركيز على تحسين تطبيقاتهم وعدم إضاعة الوقت في نشرها.
CI / CD هي إحدى ممارسات DevOpsلأنه يهدف إلى محاربة التناقضات بين المطورين الذين يريدون إجراء تغييرات متكررة ، والاستغلال الذي يتطلب الاستقرار. باستخدام الأتمتة ، يمكن للمطورين إجراء تغييرات في كثير من الأحيان ، وتكتسب فرق العمليات بدورها مزيدًا من الاستقرار ، نظرًا لأن تكوين البيئات موحد ويتم إجراء اختبار مستمر أثناء عملية التسليم. أيضًا ، يكون إعداد متغيرات البيئة منفصلًا عن التطبيق وهناك إجراءات رجوع آلية.
يمكن قياس تأثير تنفيذ خطوط أنابيب CI / CD من حيث مؤشرات أداء DevOps الرئيسية (KPIs)... غالبًا ما تتحسن مؤشرات الأداء الرئيسية مثل تكرار النشر وتغيير المهلة ومتوسط وقت الاسترداد مع عمليات نشر CI / CD مع الاختبار المستمر. ومع ذلك ، فإن CI / CD هي مجرد عملية واحدة يمكن أن تساهم في هذه التحسينات. هناك شروط أخرى لزيادة وتيرة التسليم.
لبدء استخدام CI / CD ، يحتاج فريق التطوير والعمليات إلى التعاون بشأن التقنيات والممارسات والأولويات. تحتاج الفرق إلى بناء توافق في الآراء حول الأساليب الصحيحة لأعمالهم وتقنياتهم بحيث يلتزم الفريق باستمرار بالممارسات المختارة بعد تنفيذ CI / CD.
موجز أدوات CICD: Gitlab CI ، Docker ، Ansible