برنامج تعليمي للتوصيل المستمر - بناء خط أنابيب توصيل مستمر باستخدام جينكينز

التسليم المستمر:

التسليم المستمر هو عملية يتم فيها إنشاء تغييرات التعليمات البرمجية واختبارها وإعدادها تلقائيًا للإصدار في الإنتاج.أتمنى أن تكون قد استمتعت بي هنا سأتحدث عن المواضيع التالية:

• ما هو التسليم المستمر؟
• أنواع اختبار البرمجيات
• الفرق بين التكامل المستمر والتسليم والنشر
• ما هي الحاجة للتسليم المستمر؟
• التدريب العملي على استخدام جنكينز وتومكات

دعونا نفهم بسرعة كيف يعمل التسليم المستمر.

ما هو التسليم المستمر؟

إنها عملية يمكنك من خلالها إنشاء برنامج بطريقة يمكن إصدارها للإنتاج في أي وقت.ضع في اعتبارك الرسم البياني أدناه:

اسمحوا لي أن أشرح الرسم البياني أعلاه:

• ستكتشف البرامج النصية المؤتمتة للبناء التغييرات في إدارة كود المصدر (SCM) مثل Git.
• بمجرد اكتشاف التغيير ، سيتم نشر التعليمات البرمجية المصدر إلى خادم إنشاء مخصص للتأكد من عدم فشل الإنشاء وأن جميع فئات الاختبار واختبارات التكامل تعمل بشكل جيد.
• بعد ذلك ، يتم نشر تطبيق الإنشاء على خوادم الاختبار (خوادم ما قبل الإنتاج) لاختبار قبول المستخدم (UAT).
• أخيرًا ، يتم نشر التطبيق يدويًا على خوادم الإنتاج للإصدار.

قبل المتابعة ، سيكون من العدل أن أشرح لك الأنواع المختلفة من الاختبارات.

أنواع اختبار البرمجيات:

بشكل عام ، هناك نوعان من الاختبارات:

• اختبار الصندوق الأسود: إنها تقنية اختبار تتجاهل الآلية الداخلية للنظام وتركز على المخرجات الناتجة مقابل أي إدخال وتنفيذ للنظام. ويسمى أيضًا الاختبار الوظيفي. يتم استخدامه بشكل أساسي للتحقق من صحة البرنامج.
• اختبار Whitebox: هي تقنية اختبار تأخذ في الاعتبار الآلية الداخلية للنظام. ويسمى أيضًا الاختبار الهيكلي واختبار الصندوق الزجاجي. يتم استخدامه أساسًا للتحقق من البرنامج.

اختبار Whitebox:

هناك نوعان من الاختبارات التي تندرج تحت هذه الفئة.

• وحدة التجارب: إنه اختبار وحدة فردية أو مجموعة من الوحدات ذات الصلة. غالبًا ما يتم ذلك بواسطة المبرمج لاختبار أن الوحدة التي قام بتنفيذها تنتج مخرجات متوقعة مقابل مدخلات معينة.
• اختبار التكامل: إنه نوع من الاختبار تكون فيه مجموعة المكوناتمجتمعة لإنتاج الناتج. أيضًا ، يتم اختبار التفاعل بين البرامج والأجهزة إذا كانت مكونات البرامج والأجهزة لها أي علاقة. قد يندرج تحت كل من اختبار الصندوق الأبيض واختبار الصندوق الأسود.

اختبار الصندوق الأسود:

هناك العديد من الاختبارات التي تندرج تحت هذه الفئة. سأركز علىقليلة، والتي من المهم أن تعرفها ، لفهم هذه المدونة:

• الاختبار الوظيفي / القبول: يضمن أن الوظيفة المحددة المطلوبة في متطلبات النظام تعمل. يتم إجراء ذلك للتأكد من أن المنتج الذي تم تسليمه يلبي المتطلبات ويعمل كما توقع العميل
• اختبار النظام: يضمن أنه من خلال وضع البرنامج في بيئات مختلفة (مثل أنظمة التشغيل) فإنه لا يزال يعمل.
• اختبار الإجهاد: يقوم بتقييم كيفية تصرف النظام في ظل الظروف غير المواتية.
• اختبار بيتا: يتم إجراؤه بواسطة المستخدمين النهائيين ، أو فريق التطوير الخارجي ، أو الإفراج العلني عن الإصدار المسبق الكامل للمنتج المعروف باسمبيتاالإصدار. الهدف من الاختبار التجريبي هو تغطية الأخطاء غير المتوقعة.

الآن هو الوقت المناسب بالنسبة لي لشرح الفرق بين التكامل المستمر والتسليم والنشر.

الاختلافات بين التكامل المستمر والتسليم والنشر:

يصل المحتوى المرئي إلى دماغ الفرد بطريقة أسرع وأكثر قابلية للفهم من المعلومات النصية. لذلك سأبدأ برسم تخطيطي يوضح الفرق بوضوح:

في التكامل المستمر ، يتم إنشاء واختبار كل تعليمات برمجية ، ولكنها ليست في حالة ليتم إصدارها. أعني أن تطبيق الإنشاء لا يتم نشره تلقائيًا على خوادم الاختبار من أجل التحقق من صحته باستخدام أنواع مختلفة من اختبارات Blackbox مثل - اختبار قبول المستخدم (UAT).

في 'التسليم المستمر' ، يتم نشر التطبيق باستمرار على خوادم الاختبار لـ UAT. أو يمكنك القول أن التطبيق جاهز للإصدار في أي وقت. لذلك ، من الواضح أن التكامل المستمر ضروري للتسليم المستمر.

النشر المستمر هو الخطوة التالية بعد التسليم المستمر ، حيث لا تقوم فقط بإنشاء حزمة قابلة للنشر ، ولكنك تقوم بالفعل بنشرها بطريقة آلية.

اسمحوا لي أن ألخص الاختلافات باستخدام جدول:

بعبارات بسيطة ، يعد التكامل المستمر جزءًا من كل من التسليم المستمر والنشر المستمر. ويعد النشر المستمر مثل التسليم المستمر ، باستثناء أن الإصدارات تحدث تلقائيًا.

تعرف على كيفية إنشاء خطوط أنابيب CI / CD باستخدام Jenkins On Cloud

لكن السؤال هو ما إذا كان التكامل المستمر كافٍ.

لماذا نحتاج إلى التسليم المستمر؟

دعونا نفهم هذا بمثال.

تخيل أن هناك 80 مطورًا يعملون في مشروع كبير. يستخدمون خطوط أنابيب التكامل المستمر من أجل تسهيل عمليات الإنشاء الآلية. نعلم أن البناء يشمل اختبار الوحدات أيضًا. في أحد الأيام قرروا نشر أحدث إصدار اجتاز اختبارات الوحدة في بيئة اختبار.

يجب أن يكون هذا نهجًا مطولًا ولكن متحكم فيه للنشر قام به أخصائيو البيئة. ومع ذلك ، لا يبدو أن النظام يعمل.

ما هو السبب الواضح للفشل؟

حسنًا ، السبب الأول الذي يعتقده معظم الأشخاص هو أن هناك مشكلة ما في التكوين. مثل معظم الناس حتى اعتقدوا ذلك.لقد أمضوا وقتًا طويلاً في محاولة اكتشاف الخطأ في تكوين البيئة ، لكنهم لم يتمكنوا من العثور على المشكلة.

اتخذ أحد المطورين المدركين منهجًا ذكيًا:

ثم جرب أحد كبار المطورين التطبيق على جهاز التطوير الخاص به. لم ينجح هناك أيضًا.

عاد إلى الإصدارات السابقة والأقدم حتى وجد أن النظام قد توقف عن العمل قبل ثلاثة أسابيع. منع خطأ صغير غامض النظام من البدء بشكل صحيح. على الرغم من أن المشروع كان لديه تغطية اختبار وحدة جيدة.على الرغم من ذلك ، فإن 80 مطورًا ، كانوا عادةً يجرون الاختبارات فقط بدلاً من التطبيق نفسه ، لم يروا المشكلة لمدة ثلاثة أسابيع.

عرض المشكلة:

بدون إجراء اختبارات القبول في بيئة شبيهة بالإنتاج ، فهم لا يعرفون شيئًا عما إذا كان التطبيق يفي بمواصفات العميل ، أو ما إذا كان يمكن نشره والبقاء على قيد الحياة في العالم الحقيقي. إذا كانوا يريدون الحصول على تعليقات في الوقت المناسب حول هذه الموضوعات ، فيجب عليهم توسيع نطاق عملية التكامل المستمرة.

اسمحوا لي أن ألخص الدروس المستفادة من خلال النظر في المشاكل المذكورة أعلاه:

• تختبر اختبارات الوحدة فقط منظور المطور لحل المشكلة. لديهم قدرة محدودة فقط على إثبات أن التطبيق يقوم بما يفترض به من وجهة نظر المستخدمين. هم لا يكفيتحديد المشاكل الوظيفية الحقيقية.
• يعد نشر التطبيق في بيئة الاختبار عملية معقدة ومكثفة يدويًا كانت عرضة تمامًا للخطأ.وهذا يعني أن كل محاولة للنشر كانت تجربة جديدة - عملية يدوية عرضة للخطأ.

الحل - خط أنابيب التسليم المستمر (اختبار القبول الآلي):

لقد أخذوا التكامل المستمر (التسليم المستمر) إلى الخطوة التالية وقدموا اثنين من اختبارات القبول الآلية البسيطة التي أثبتت أن التطبيق يعمل ويمكن أن يؤدي وظيفته الأساسية.غالبية الاختبارات التي يتم إجراؤها أثناء مرحلة اختبار القبول هي اختبارات القبول الوظيفي.

بشكل أساسي ، قاموا ببناء خط أنابيب التسليم المستمر ، من أجل التأكد من نشر التطبيق بسلاسة في بيئة الإنتاج ، من خلال التأكد من أن التطبيق يعمل بشكل جيد عند نشره على خادم الاختبار وهو نسخة طبق الأصل من خادم الإنتاج.

بما يكفي من النظرية ، سأوضح لك الآن كيفية إنشاء خط أنابيب توصيل مستمر باستخدام جينكينز.

خط أنابيب التوصيل المستمر باستخدام Jenkins:

هنا سأستخدم Jenkins لإنشاء خط أنابيب توصيل مستمر ، والذي سيتضمن المهام التالية:

خطوات المشاركة في العرض:

• إحضار الكود من جيثب
• تجميع شفرة المصدر
• اختبار الوحدة وإنشاء تقارير اختبار JUnit
• قم بتعبئة التطبيق في ملف WAR ونشره على خادم Tomcat

المتطلبات المسبقة:

• آلة CentOS 7
• جينكينز 2.121.1
• عامل ميناء
• تومكات 7

الخطوة - 1 تجميع شفرة المصدر:

لنبدأ أولاً بإنشاء مشروع Freestyle في Jenkins. ضع في اعتبارك لقطة الشاشة أدناه:

أعط اسمًا لمشروعك وحدد مشروع Freestyle:

عندما تقوم بالتمرير لأسفل ستجد خيارًا لإضافة مستودع كود المصدر ، حدد git وأضف عنوان URL للمستودع ، في هذا المستودع هناك غرامة pom.xml سنستخدمها لبناء مشروعنا. ضع في اعتبارك لقطة الشاشة أدناه:

الآن سنضيف مشغل البناء. اختر خيار SCM للاستطلاع ، بشكل أساسي ، سنقوم بتهيئة Jenkins لاستقصاء مستودع GitHub بعد كل 5 دقائق للتغييرات في الكود. ضع في اعتبارك لقطة الشاشة أدناه:

قبل المتابعة ، اسمحوا لي أن أقدم لكم مقدمة صغيرة عن دورة Maven Build.

يتم تحديد كل دورة حياة بناء من خلال قائمة مختلفة من مراحل البناء ، حيث تمثل مرحلة البناء مرحلة في دورة الحياة.

فيما يلي قائمة مراحل البناء:

• تحقق - تحقق من صحة المشروع وأن جميع المعلومات اللازمة متوفرة
• ترجمة - تجميع الكود المصدري للمشروع
• اختبار - اختبار الكود المصدري المترجم باستخدام إطار عمل اختبار وحدة مناسب. يجب ألا تتطلب هذه الاختبارات تعبئة الكود أو نشره
• الحزمة - خذ الكود المترجم وقم بحزمه بتنسيقه القابل للتوزيع ، مثل JAR.
• تحقق - قم بإجراء أي فحوصات على نتائج اختبارات التكامل لضمان استيفاء معايير الجودة
• التثبيت - تثبيت الحزمة في المستودع المحلي ، لاستخدامها كعنصر تبعية في مشاريع أخرى محليًا
• النشر - يتم تنفيذه في بيئة الإنشاء ، ويقوم بنسخ الحزمة النهائية إلى المستودع البعيد لمشاركتها مع المطورين والمشاريع الأخرى.

يمكنني تشغيل الأمر التالي ، لتجميع كود المصدر واختبار الوحدة وحتى تغليف التطبيق في ملف حرب:

حزمة نظيفة mvn

يمكنك أيضًا تقسيم وظيفة الإنشاء إلى عدد من خطوات الإنشاء. هذا يجعل من السهل تنظيم التراكيب في مراحل نظيفة ومنفصلة.

لذلك سنبدأ بتجميع شفرة المصدر. في علامة تبويب الإنشاء ، انقر فوق استدعاء أهداف المستوى الأعلى واكتب الأمر التالي:

تجميع

ضع في اعتبارك لقطة الشاشة أدناه:

الحصول على طول مصفوفة جافا سكريبت

سيؤدي هذا إلى سحب الكود المصدري من مستودع GitHub وسيقوم أيضًا بتجميعه (Maven Compile Phase).

انقر فوق حفظ وقم بتشغيل المشروع.

الآن ، انقر فوق خرج وحدة التحكم لرؤية النتيجة.

الخطوة - 2 اختبار الوحدة:

الآن سنقوم بإنشاء مشروع Freestyle آخر لاختبار الوحدة.

أضف نفس عنوان URL للمستودع في علامة تبويب إدارة كود المصدر ، كما فعلنا في الوظيفة السابقة.

الآن ، في علامة التبويب 'Buid Trigger' ، انقر فوق 'إنشاء بعد إنشاء مشاريع أخرى'. هناك اكتب اسم المشروع السابق حيث نقوم بتجميع الكود المصدري ، ويمكنك تحديد أي من الخيارات التالية:

علم البيانات ما هو

• يتم تشغيله فقط إذا كان التصميم مستقرًا
• الزناد حتى لو كان البناء غير مستقر
• تشغيل حتى لو فشل البناء

أعتقد أن الخيارات المذكورة أعلاه تشرح نفسها بنفسها ، لذا حدد أيًا منها. ضع في اعتبارك لقطة الشاشة أدناه:

في علامة التبويب إنشاء ، انقر فوق استدعاء الأهداف المخضرمة ذات المستوى الأعلى واستخدم الأمر التالي:

اختبار

يقوم Jenkins أيضًا بعمل رائع في مساعدتك في عرض نتائج الاختبار واتجاهات نتائج الاختبار.

المعيار الفعلي لتقارير الاختبار في عالم Java هو تنسيق XML يستخدمه JUnit. يستخدم هذا التنسيق أيضًا بواسطة العديد من أدوات اختبار Java الأخرى ، مثل TestNG و Spock و Easyb. يفهم Jenkins هذا التنسيق ، لذلك إذا كان التصميم الخاص بك ينتج نتائج اختبار JUnit XML ، فيمكن لـ Jenkins إنشاء تقارير اختبار رسومية وإحصائيات حول نتائج الاختبار بمرور الوقت ، كما يتيح لك عرض تفاصيل أي إخفاقات في الاختبار. يتتبع Jenkins أيضًا المدة التي تستغرقها اختباراتك للتشغيل ، على مستوى العالم ، وفي كل اختبار - يمكن أن يكون هذا مفيدًا إذا كنت بحاجة إلى تتبع مشكلات الأداء.

لذا فإن الشيء التالي الذي يتعين علينا القيام به هو جعل جينكينز يراقب اختبارات الوحدة لدينا.

انتقل إلى قسم إجراءات ما بعد الإنشاء وحدد خانة الاختيار 'نشر تقرير نتائج اختبار JUnit'. عندما تقوم Maven بتشغيل اختبارات الوحدة في مشروع ، فإنها تقوم تلقائيًا بإنشاء تقارير اختبار XML في دليل يسمى تقارير surefire. لذا أدخل '** / target / surefire-reports / *. xml' في حقل 'Test report XMLs'. تعتبر العلامتان النجميتان الموجودتان في بداية المسار ('**') من أفضل الممارسات لجعل التكوين أكثر قوة قليلاً: فهي تسمح لـ Jenkins بالعثور على الدليل الهدف بغض النظر عن كيفية تكوين Jenkins للتحقق من الكود المصدري.

** / target / surefire-reports / *. xml

احفظه مرة أخرى وانقر على Build Now.

الآن ، تمت كتابة تقرير JUnit إلى / var / lib / jenkins / workspace / test / gameoflife-core / target / surefire-reports / TEST-Conduct.

في لوحة القيادة Jenkinsيمكنك أيضًا ملاحظة نتائج الاختبار:

الخطوة 3: إنشاء ملف حرب ونشره على خادم Tomcat:

الآن ، الخطوة التالية هي تجميع تطبيقنا في ملف WAR ونشره على خادم Tomcat لاختبار قبول المستخدم.

أنشئ مشروعًا مجانيًا آخر وأضف عنوان URL لمستودع كود المصدر.

ثم في علامة تبويب مشغل الإنشاء ، حدد إنشاء عند إنشاء مشاريع أخرى ، ضع في اعتبارك لقطة الشاشة أدناه:

بشكل أساسي ، بعد مهمة الاختبار ، ستبدأ مرحلة النشر تلقائيًا.

في علامة تبويب الإنشاء ، حدد برنامج شل النصي. اكتب الأمر أدناه لحزم التطبيق في ملف WAR:

حزمة mvn

الخطوة التالية هي نشر ملف WAR هذا على Tomcatالخادم. في علامة التبويب 'إجراءات ما بعد الإنشاء' ، حدد نشر war / ear إلى حاوية. هنا ، أعط المسار إلى ملف الحرب وأعطِ مسار السياق. ضع في اعتبارك لقطة الشاشة أدناه:

حدد بيانات اعتماد Tomcat ولاحظ لقطة الشاشة أعلاه. تحتاج أيضًا إلى إعطاء عنوان URL لخادم Tomcat الخاص بك.

من أجل إضافة بيانات اعتماد في Jenkins ، انقر فوق خيار بيانات الاعتماد في لوحة معلومات Jenkins.

انقر فوق النظام وحدد بيانات الاعتماد العامة.

ثم ستجد خيارًا لإضافة بيانات الاعتماد. اضغط عليها وأضف بيانات الاعتماد.

أضف بيانات اعتماد Tomcat ، ضع في اعتبارك لقطة الشاشة أدناه.

انقر فوق موافق.

الآن في تكوين المشروع الخاص بك ، أضف بيانات اعتماد tomcat التي أدخلتها في الخطوة السابقة.

انقر فوق حفظ ثم حدد Build Now.

انتقل إلى عنوان URL الخاص بـ tomcat ، مع مسار السياق ، في حالتي يكون http: // localhost: 8081. أضف الآن مسار السياق في النهاية ، ضع في اعتبارك لقطة الشاشة أدناه:

الرابط - http: // localhost: 8081 / gof

أتمنى أن تكون قد فهمت معنى مسار السياق.

الآن قم بإنشاء عرض خط أنابيب ، ضع في اعتبارك لقطة الشاشة أدناه:

انقر فوق أيقونة علامة الجمع لإنشاء عرض جديد.

قم بتكوين خط الأنابيب بالطريقة التي تريدها ، ضع في اعتبارك لقطة الشاشة أدناه:

لم أغير أي شيء سوى اختيار الوظيفة الأولية. لذلك سيبدأ خط الأنابيب الخاص بي من التجميع. بناءً على طريقة تكوين الوظائف الأخرى ، سيحدث اختبار التجميع والنشر.

أخيرًا ، يمكنك اختبار خط الأنابيب بالنقر فوق RUN. بعد كل خمس دقائق ، إذا كان هناك تغيير في شفرة المصدر ، فسيتم تنفيذ خط الأنابيب بالكامل.

لذلك نحن قادرون على نشر تطبيقنا باستمرار على خادم الاختبار لاختبار قبول المستخدم (UAT).

أتمنى أن تكون قد استمتعت بقراءة هذا المنشور على التسليم المستمر. إذا كانت لديك أي شكوك ، فلا تتردد في وضعها في قسم التعليقات أدناه وسأعود بإجابة في أقرب وقت ممكن.

من أجل بناء خطوط أنابيب CI / CD ، تحتاج إلى إتقان مجموعة متنوعة من المهارات إتقان مهارات DevOps المطلوبة الآن