تشغيل خطوط الأنابيب وتصورها عند تكوين GitLab CI / CD لعدة مشاريع.
التكامل المستمر (CI) هو ممارسة أتمتة التجميع واختبار الكود قبل دمجها مع الفرع الرئيسي. يسمح للمطورين بحقن الشفرة في كثير من الأحيان وفي وقت مبكر ، مع تقليل مخاطر إدخال أخطاء جديدة في مستودع شفرة المصدر الرئيسي.
على الرغم من أن CI تتحقق من أن الكود الجديد لن ينقطع عند دمجه مع الكود الآخر في نفس الريبو ، إلا أن اجتياز جميع الاختبارات على هذا الريبو ليس سوى الخطوة الأولى. بعد تشغيل CI في التعليمات البرمجية ، من المهم نشر الاختبارات وتشغيلها في بيئة حقيقية. الانتقال من CI إلى التسليم المستمر والنشر (CD) هو الخطوة التالية إلى DevOps "للبالغين". يتيح لك النشر وإعادة الاختبار اللاحقة اختبار رمز مشروع واحد إلى جانب المكونات والخدمات الأخرى التي قد تتم إدارتها بواسطة مشاريع أخرى.
لماذا أحتاج إلى التأكد من أن الكود الخاص بي يعمل مع المكونات الأخرى؟
مثال جيد على ذلك هو بنية الخدمات الصغيرة. عادةً ، تتم إدارة خدمات microservices في مشاريع مختلفة ، حيث يكون لكل خدمة microservice مستودع خاص بها مع خط أنابيب. بالإضافة إلى ذلك ، غالبًا ما يكون كل فريق تطوير مسؤولاً عن الخدمات الدقيقة الفردية وتكوينات خطوط الأنابيب. كمبرمج ، قد ترغب في التأكد من أن التغييرات التي تم إجراؤها على الكود لا تنتهك وظائف خدماتها الصغيرة. لذلك ، يمكنك إجراء اختبارات عليها بالإضافة إلى اختبارات لمشروعك.
مشروع خط أنابيب الصليب
عند بدء تشغيل خط أنابيب المشروع ، ستحتاج أيضًا إلى تشغيل خط أنابيب عبر المشروع ، والذي سينشر أخيرًا ويختبر أحدث إصدار من جميع خدمات micros التابعة. لتحقيق ذلك ، تحتاج إلى طريقة بسيطة ومرنة ومريحة لإطلاق خطوط أنابيب أخرى في إطار CI لمشروعك. يوفر GitLab CI / CD طريقة سهلة لإطلاق خط أنابيب عبر المشاريع من خلال إضافة مهمة خاصة إلى ملف تكوين CI.
GitLab CI / CD ملف التكوين
في GitLab CI / CD ، يتم تحديد خطوط الأنابيب ، وكذلك الوظائف وخطوات مكوناتها في .gitlab-ci.yml لكل مشروع. الملف جزء من مستودع المشروع. تم إصداره بالكامل ، ويمكن للمطورين تحريره باستخدام أي IDE من اختيارهم. لا يحتاجون إلى مطالبة مسؤول النظام أو أمر DevOps بإجراء تغييرات على تكوين خط أنابيب ، حيث يمكنهم القيام بذلك بأنفسهم. يحدد .gitlab-ci.yml هيكل خطوط الأنابيب وترتيبها ، ويقرر ما يجب فعله باستخدام GitLab Runner (الوكيل الذي يدير المهام) ، وما هي القرارات التي ينبغي اتخاذها عند نشوء بعض الشروط ، على سبيل المثال ، عند اكتمال العملية بنجاح أو عند إنهاء العملية نظام.
إضافة وظيفة لتشغيل خط أنابيب المشروع
بدءًا من GitLab 11.8 ، يوفر GitLab بناء جملة تكوين CI / CD جديدًا لتشغيل خطوط أنابيب مشتركة للمشروع ، والتي يمكن العثور عليها في قواعد تكوين خطوط الأنابيب . توضح التعليمة البرمجية التالية كيفية تكوين مهمة جسر لتشغيل خط أنابيب الوصلة الهابطة:
// job1 job deploy: stage: Deploy script: this is my script // job2 bridge job , - Android: stage: Trigger-cross-projects trigger: mobile/android
في المثال أعلاه ، بمجرد نجاح مهمة النشر في مرحلة النشر ، تبدأ مهمة جسر Android. حالتها الأولية ستكون معلقة. ستقوم GitLab بإنشاء خط أنابيب في مشروع الجوال / android ، وبمجرد إنشائه ، ستنجح مهمة Android. في هذه الحالة ، يعد mobile / android هو المسار الكامل لهذا المشروع.
يجب أن يكون لدى المستخدم الذي أنشأ خط الأنابيب الرئيسي حقوق الوصول إلى المشروع المتلقين للمعلومات (في هذه الحالة ، mobile / android). إذا تعذر العثور على المشروع المتلقين للمعلومات أو لم يكن لدى المستخدم حقوق الوصول لإنشاء خط أنابيب هناك ، فستتلقى مهمة Android الحالة الفاشلة.
نظرة عامة على المخططات من خط أنابيب المنبع إلى المصب
يسمح لك GitLab CI / CD بتصور تكوين خط الأنابيب. في الشكل أدناه ، تُعد خطوات التجميع والاختبار والنشر جزءًا من مشروع المنبع. بمجرد اكتمال مهمة النشر بنجاح ، سيتم إطلاق أربعة مشاريع متوازية بالتوازي ، ويمكنك المتابعة إليها من خلال النقر فوق أحد مهام المصب.
في الشكل أدناه ، يمكنك رؤية خط الدفع الهابط "الخدمة - المالية". يمكنك الآن التمرير يسارًا إلى خط الأنابيب التصاعدي ، أو التمرير إلى اليمين مباشرةً إلى خط الأنابيب الهابط ، أو تحديد خط أنابيب تنازلي آخر.
تحديد فرع خط أنابيب الطفل
يمكنك تحديد اسم الفرع الذي سيستخدمه خط الأنابيب الهابط:
trigger: project: mobile/android branch: stable-11-2
استخدم الكلمة الأساسية للمشروع للإشارة إلى المسار الكامل للمشروع المتلقين للمعلومات. استخدم الكلمة المفتاحية للفرع لتحديد اسم الفرع. ستستخدم GitLab الالتزام الموجود حاليًا في فرع HEAD عند إنشاء خط أنابيب الوصلة الهابطة.
تمرير المتغيرات إلى خط أنابيب تنازلي
يوما ما ، قد ترغب في تمرير المتغيرات إلى خط أنابيب تنازلي. يمكنك القيام بذلك باستخدام الكلمات الأساسية للمتغيرات ، كما تفعل مع تعريف الوظيفة العادي.
Android: variable: ENVIRONMENT: 'This is the variable value for the downstream pipeline' stage: Trigger-cross-projects trigger: mobile/android
سيتم تمرير متغير البيئة إلى كل وظيفة محددة في خط الأنابيب التنازلي. سيكون متاحًا كمتغير بيئة في كل مرة يختار فيها GitLab Runner وظيفة.
إجمالي خط أنابيب المشروع
يحدد .gitlab-ci.yml ترتيب مراحل CI / CD ، والمهام التي يجب تنفيذها وتحت أي شروط لبدء المهمة أو تخطيها. يمكن استخدام إضافة "مهمة جسر" trigger إلى هذا الملف لتشغيل خطوط أنابيب المشروع المشترك. يمكننا نقل المعلمات إلى الوظائف في خطوط الأنابيب الهابطة وحتى تحديد الفرع الذي سيستخدمه خط الأنابيب الهابط.
يمكن أن تكون خطوط الأنابيب هياكل معقدة لها العديد من المهام المتتابعة والمتوازية ، وكما تعلمنا للتو ، في بعض الأحيان يمكنها تشغيل خطوط أنابيب أسفل المجرى. لتبسيط فهم تدفق خطوط الأنابيب ، بما في ذلك خطوط الأنابيب الهابطة ، لدى GitLab خطوط أنابيب لعرض خطوط الأنابيب وحالتها.
اقرأ أيضًا مقالات أخرى على مدونتنا: