كيفية إنشاء مسار متعدد في Jenkins

كانت هناك أوقات كنا نقوم بإنشاء وظائف Jenkins باستخدام واجهة المستخدم فقط. لاحقًا ، تم طرح فكرة الخط الأنابيب كرمز لمعالجة التعقيد المتزايد مع وظائف البناء والنشر. في Jenkins 2.0 ، قام فريق Jenkins بإدخال ملف Jenkinsfile لتحقيق الخط الأنابيب كرمز. إذا كنت ترغب في إنشاء خط أنابيب Jenkins المتوقع تلقائيًا على أساس طلبات السحب أو الفروع، فإن خط الأنابيب المتعددة الفروع في Jenkins هو الطريق للذهاب.التكامل المستمر والتسلسل المستمر

نظرًا لأن خط الأنابيب المتعددة الفروع في Jenkins هو بالكامل خط أنابيب قائم على Git كرمز، يمكنك بناء سير عمل CI/CD الخاص بك. الخط الأنابيب كرمز (PaaC) يجعل من السهل تحقيق مزايا الأتمتة ونقل السحابة إلى Selenium الخاص بك. يمكنك استخدام نموذج خط الأنابيب المتعددة الفروع لبناء واختبار ونشر ومراقبة وتقارير وإدارة حسابات Selenium الخاصة بك بسرور وبشكل موثوق به. في هذا البرنامج التعليمي لJenkins، سنلقي نظرة على كيفية إنشاء خط أنابيب متعددة الفروع في Jenkins والمفاهيم الرئيسية المتعلقة بتكوين خط أنابيب متعددة الفروع لاختبار الأتمتة باستخدام Selenium.

هيا بنا نبدأ.

ما هو خط أنابيب متعددة الفروع في Jenkins؟

وفقًا للوثائق الرسمية، نوع وظيفة خط الأنابيب المتعددة الفروع يتيح لك تعريف وظيفة حيث من مستودع Git واحد، سيكتشف Jenkins الفروع المتعددة وينشئ وظائف متنقلة عندما يجد Jenkinsfile.

من التعريف أعلاه، يمكننا فهم أن Jenkins يمكنه مسح مستودع Git لملف Jenkinsfile وإنشاء وظائف تلقائيًا. كل ما يحتاجه منا هو تفاصيل مستودع Git. في هذا المقال، سنستخدم مستودع GitHub عينة. مستودع GitHub العينة لدينا يحتوي على مشروع Spring Boot عينة، والذي يمكن نشره على Tomcat.

في الدليل الجذري للمشروع، لدينا ملف Jenkinsfile. استخدمنا بناء جملة Jenkins Declarative pipeline لإنشاء هذا الملف Jenkinsfile. إذا كنت جديدًا على Jenkins Declarative pipeline، يرجى قراءة مقالنا المفصل هنا.

مثال Jenkinsfile

pipeline {
   agent any
   stages {
       stage('Build Code') {
           steps {
               sh """
               echo "Building Artifact"
               """
           }
       }
      stage('Deploy Code') {
          steps {
               sh """
               echo "Deploying Code"
               """
          }
      }
   }
}

لقد أنشأنا مرحلتين “بناء الكود” و”نشر الكود” في ملف Jenkinsfile الخاص بنا، حيث تم تكوين كل منهما لطباعة الرسائل المناسبة. الآن، لدينا مستودع Git مع Jenkinsfile جاهز.

دعونا ننشئ دليل Jenkins multibranch في خادم Jenkins.

Jenkins Pipeline مقابل Multibranch Pipeline

خوارزمية Jenkins pipeline هي الجديد المثير، لكنها ليست للجميع. والخوارزميات multibranch لا تزال رائعة. في هذا القسم من برنامج التعليمات البرمجية لخوارزمية Jenkins multibranch، دعونا نفهم الاستخدام المثالي لخوارزمية Jenkins pipeline وخوارزمية multibranch pipeline من خلال هذه المقارنة بين Jenkins pipeline وmultibranch pipeline.

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

يسمح لك Jenkins pipeline بالحصول على ملف Jenkinsfile مرن بمراحل لبناء المهمة الخاصة بك. لذا، يمكنك الحصول على مرحلة أولية حيث تقوم بتشغيل الكشف عن الأخطاء، الاختبارات، إلخ، ثم مراحل منفصلة لبناء الأوساط التفاعلية أو نشرها. هذا مفيد للغاية عندما ترغب في القيام بأشياء متعددة في خريطتك.

ماذا لو كان لديك شيء واحد فقط للقيام به؟ أو إذا كانت جميع الأشياء التي ترغب في القيام بها تختلف بناءً على بعض التكوينات؟ هل من المنطقي استخدام Jenkins pipeline هنا؟

Multibranch pipeline هو نهج بديل قد يكون أكثر ملاءمة في هذه الحالات. يسمح Multibranch pipeline بتقسيم المهام إلى فروع ودمجها لاحقًا. هذا مشابه للغاية للطريقة التي تعمل بها فروع Git.

A multibranch pipeline is a pipeline that has multiple branches. The main advantage of using a multibranch pipeline is to build and deploy multiple branches from a single repository. Having a multibranch pipeline also allows you to have different environments for different branches. However, it is not recommended to use a multibranch pipeline if you do not have a standard branching and CI/CD strategy.

الآن، بما أنك رأيت مقارنة Jenkins pipeline مقابل Multibranch pipeline، دعونا نتعرف على خطوات إنشاء Jenkins Multibranch pipeline.

إنشاء Jenkins Multibranch Pipeline

الخطوة 1

افتح صفحة Jenkins الرئيسية (http://localhost:8080 في المحلي) وانقر على “New Item” () من قائمة اليسار.

الخطوة 2

أدخل اسم وظيفة Jenkins, اختر الأنماط كـ “دورة جانبية متعددة,” وانقر على “موافق.”

الخطوة 3

في صفحة “تكوين”، نحتاج فقط إلى تكوين شيء واحد: مصدر Git Repo.

انتقل لأسفل إلى قسم “المصادر الفرعية” وانقر على المنسدلة التي تقول “إضافة مصدر.”

اختر “GitHub” كمصدر لأن مكتبتنا العينة مستضافة هناك.

الخطوة 4

أدخل عنوان URL HTTPS للمستودع كـ https://github.com/iamvickyav/spring-boot-h2-war-tomcat.git وانقر على “تحقق.”

بما أن مستودع GitHub لدينا مستضاف كمستودع عام، لا نحتاج إلى تكوين بيانات الاعتماد للوصول إليه. بالنسبة للمستودعات الخاصة/المؤسسية، قد نحتاج إلى بيانات اعتماد للوصول إليها.

رسالة “بيانات الاعتماد جيدة” تمثل نجاح الاتصال بين خادم Jenkins ومستودع Git.

الخطوة 5

اترك بقية قسم التكوين كما هو الآن وانقر على زر “حفظ” في الأسفل.

عند الحفظ، سيقوم Jenkins تلقائيًا بالخطوات التالية:

المسح لمستودع الخطوة

• افحص مستودع Git الذي تكوناه.
• ابحث عن قائمة الفروع المتاحة في مستودع Git.
• اختر الفروع التي لها Jenkinsfile.

خطوة تشغيل البناء

• قم بتشغيل البناء لكل فرع موجود في الخطوة السابقة باتباع الخطوات المذكورة في ملف Jenkinsfile.

من قسم “مسح سجل المستودع“، يمكننا فهم ما حدث خلال خطوة “مسح المستودع”.

نظرًا لأن لدينا فقط فرع “الفرع الرئيسي” في مستودعنا الجيت، يقول سجل مسح المستودع “تم معالجة فرع واحد.”

بعد اكتمال المسح، سيقوم Jenkins بإنشاء وتشغيل مهمة بناء لكل فرع معالج بشكل منفصل.

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

يمكننا رؤية مهمة بناء أنشئت للفرع الرئيسي في قسم الحالة.

انقر على اسم الفرع لرؤية سجل وحالة مهمة البناء.

“عرض المراحل” يوفر تمثيل بصري لمدة الوقت التي استغرقتها كل مرحلة لتنفيذها وحالة مهمة البناء.

الوصول إلى سجلات تشغيل مهمة البناء

الخطوة 1

انقر على “رقم البناء” تحت قسم “سجل تاريخ البناء”.

الخطوة 2

بعد ذلك، اختر “إخراج وحدة التحكم” من قائمة الجانب الأيسر لرؤية السجلات.

ماذا يحدث إذا كان لدينا أكثر من فرع واحد في مستودعنا الجيت؟ دعونا نتحقق من ذلك الآن.

في مستودع الجيت، تم إنشاء فرع جديد يسمى “الفرع التطوري”.

للتمييز بين بناء الفرع “تطوير“، قمنا بإجراء تغييرات طفيفة في أوامر الطباعة في Jenkinsfile.

Jenkinsfile في فرع الماجستير

pipeline {
   agent any
   stages {
       stage('Build Code') {
           steps {
               sh """
               echo "Building Artifact"
               """
           }
       }
      stage('Deploy Code') {
          steps {
               sh """
               echo "Deploying Code"
               """
          }
      }
   }
}

Jenkinsfile في فرع التطوير

pipeline {
   agent any
   stages {
       stage('Build Code') {
           steps {
               sh """
               echo "Building Artifact from Develop Branch"
               """
           }
       }
      stage('Deploy Code') {
          steps {
               sh """
               echo "Deploying Code from Develop Branch"
               """
          }
      }
   }
}

الآن، لدينا اثنين من Jenkinsfile في فرعين مختلفين. فلنعيد تشغيل مسح المستودع في Jenkins لرؤية السلوك.

يمكننا رؤية الفرع الجديد (فرع التطوير) تم اكتشافه بواسطة Jenkins. ومن ثم، تم إنشاء وظيفة جديدة بشكل منفصل لفرع التطوير.

عند النقر على “تطوير“، يمكننا رؤية السجل لوظيفة بناء فرع التطوير.

في المثال السابق، حفظنا محتويات مختلفة لـ Jenkinsfile في الماجستير وفرع التطوير. لكن هذه ليست الطريقة التي نفعل بها ذلك في تطبيقات العالم الحقيقي. نستخدم كتل when داخل كتلة stage للتحقق من الفرع.

إليك مثالًا بخطوات مجتمعة للماجستير وفرع التطوير. سيتم وضع هذا المحتوى المشترك في كل من Jenkinsfile للماجستير وفرع التطوير.

pipeline {
    agent any
    stages {
        stage('Master Branch Deploy Code') {
            when {
                branch 'master'
            }
            steps {
                sh """
                echo "Building Artifact from Master branch"
                """

                sh """
                echo "Deploying Code from Master branch"
                """
            }
        }
        stage('Develop Branch Deploy Code') {
            when {
                branch 'develop'
            }
            steps {
                sh """
                echo "Building Artifact from Develop branch"
                """
                sh """
                echo "Deploying Code from Develop branch"
                """
           }
        }
    }
}

الخطوة 3

انقر على “استكشاف المستودع” من قائمة اليسار ليكتشف Jenkins التغييرات الجديدة من مستودع Git.

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

ماذا عن تشغيل هذه الخطوة تلقائيًا؟

محرك الزمنية لمسح مشروع Jenkins المتعدد الفروع

الخطوة 1

انقر على “تكوين” من قائمة اليسار.

الخطوة 2

انتقل لأسفل إلى قسم “تشغيل مشروع المستودع” وقم بتمكين مربع الاختيار “بشكل دوري إذا لم يتم تشغيله بطريقة أخرى” واختر فترة الزمن التي يجب أن يعمل فيها المسح بشكل دوري (دقيقتان في مثالنا).

الخطوة 3

انقر على زر “حفظ“.

من الآن فصاعدًا، سيقوم Jenkins بفحص المستودع كل دقيقتين. إذا وجدت الإصدارات الجديدة في أي فرع، سيقوم Jenkins بتشغيل مهمة بناء جديدة لهذا الفرع المحدد باستخدام Jenkinsfile.

أدناه يوجد “سجل فحص المستودع“، والذي يوضح بوضوح المسح المُنشأ كل دقيقتين.

حالات الاستخدام الحية لـ Jenkins Multibranch Pipeline

أدناه بضعة سيناريوهات حيث يمكن استخدام Jenkins multibranch pipeline:

• يجب أن يتم توزيع أي إصدار جديد في الفرع الرئيسي على الخادم تلقائيًا.
• إذا حاول المطور رفع طلب السحب (PR) لتطوير فرع ثم:
  • يجب أن يبنى الكود بنجاح بدون أخطاء تجميع.
  • يجب أن يكون الكود قائمًا على تغطية إختبار بنسبة 80٪ على الأقل.
  • يجب أن يجتاز الكود اختبار جودة الكود SONAR.
• إذا حاول المطور دفع الكود إلى فرع غير الرئيسي أو التطور، يجب أن يجمع بنجاح الكود. إذا لم يفعل، أرسل رسالة تنبيه عبر البريد الإلكتروني.

إليك نموذج Jenkinsfile يغطي بعض من حالات الاستخدام المذكورة أعلاه:

pipeline {
    agent any
    tools {
        maven 'MAVEN_PATH'
        jdk 'jdk8'
    }
    stages {
        stage("Tools initialization") {
            steps {
                sh "mvn --version"
                sh "java -version"
            }
        }
        stage("Checkout Code") {
            steps {
                checkout scm
            }
        }
        stage("Check Code Health") {
            when {
                not {
                    anyOf {
                        branch 'master';
                        branch 'develop'
                    }
                }
           }
           steps {
               sh "mvn clean compile"
            }
        }
        stage("Run Test cases") {
            when {
                branch 'develop';
            }
           steps {
               sh "mvn clean test"
            }
        }
        stage("Check Code coverage") {
            when {
                branch 'develop'
            }
            steps {
               jacoco(
                    execPattern: '**/target/**.exec',
                    classPattern: '**/target/classes',
                    sourcePattern: '**/src',
                    inclusionPattern: 'com/iamvickyav/**',
                    changeBuildStatus: true,
                    minimumInstructionCoverage: '30',
                    maximumInstructionCoverage: '80')
           }
        }
        stage("Build and Deploy Code") {
            when {
                branch 'master'
            }
            steps {
                sh "mvn tomcat7:deploy"
            }
        }
    }
 }

االتزمنا بهذا الملف الجديد Jenkinsfile في الفروع الرئيسية والتطور ، بحيث يمكن اكتشافه بواسطة Jenkins multibranch في المسح المستقبلي للمستودع.

اختبار تحليل النصوص Selenium التشغيلي مع Jenkins Multibranch Pipeline

لنفترض أننا نكتب حالات اختبار تشغيلية لموقع ويب. كلما االتزمت حالة اختبار جديدة في فرع ، نريد تشغيلها والتأكد من أنها تنفذ كما هو متوقع.

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

باستخدام شبكة Selenium LambdaTest ، يمكنك تحسين تغطية متصفحك.

في هذا القسم ، سنرى كيفية الاستفادة من بنية اختبار LambdaTest مع Jenkins multibranch pipeline. للتوضيح ، استضفنا تطبيق عينة للمهام هنا – تطبيق LambdaTest ToDo. تم االتزام حالات اختبار تشغيلية مكتوبة باستخدام Cucumber في المستودع العينة.

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

إعداد متغير البيئة

عندما يتم تشغيل حالة اختبار ، ستبحث عن اسم مستخدم LambdaTest (LT_USERNAME) وكلمة المرور (LT_ACCESS_KEY) في المتغيرات البيئية. لذا ، نحتاج إلى تكوينها مسبقًا.

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

environment {
               LAMBDATEST_CRED = credentials('Lambda-Test-Credentials-For-multibranch')
               LT_USERNAME = "$LAMBDATEST_CRED_USR"
               LT_ACCESS_KEY = "$LAMBDATEST_CRED_PSW"
}

إليك ملفنا النهائي Jenkinsfile:

pipeline {
   agent any
   tools {
       maven 'MAVEN_PATH'
       jdk 'jdk8'
   }
   stages {
       stage("Tools initialization") {
           steps {
               sh "mvn --version"
               sh "java -version"
           }
       }
       stage("Checkout Code") {
           steps {
               checkout scm
           }
       }
       stage("Check Code Health") {
           when {
               not {
                   anyOf {
                       branch 'master';
                       branch 'develop'
                   }
               }
          }
          steps {
              sh "mvn clean compile"
           }
       }
       stage("Run Test cases in LambdaTest") {
           when {
               branch 'develop';
           }
           environment {
               LAMBDATEST_CRED = credentials('Lambda-Test-Credentials-For-multibranch')
               LT_USERNAME = "$LAMBDATEST_CRED_USR"
               LT_ACCESS_KEY = "$LAMBDATEST_CRED_PSW"
           }
          steps {
              sh "mvn test"
           }
       }
   }
}

الآن، سنقوم بإنشاء “وظيفة” جديدة في Jenkins كخط إنتاج متعدد الفروع بتبع الخطوات المذكورة في الأقسام السابقة. دعونا نشير إلى المستودع العيني.

بمجرد اكتمال البناء بنجاح، قم بزيارة tableau تحكم LambdaTest للحصول على سجلات الاختبار.

الخاتمة

مع هذا، تعلمنا كيفية إنشاء خط إنتاج متعدد الفروع في Jenkins، كيفية تكوين مستودع git فيه، خطوات بناء مختلفة لفروع مختلفة، استخدام المسوح التلقائي الدوري للمستودع بواسطة Jenkins والاستفادة من بنية تحكم LambdaTest القوية لأتمتة بناء CI/CD الخاص بنا. آمل أن تكون هذه المقالة مفيدة. يرجى مشاركة تعليقاتك في قسم التعليقات.