איך ליצור קו עבודה רב-ענף ב-Jenkins

היו פעמים שבהן יצרנו משימות Jenkins רק באמצעות הממשק הגרפי. לאחר מכן, הצעת הרעיון של "צינורית כקוד" הופכת להיות רלוונטית כדי לטפל בעמימות הגוברת עם משימות הבנייה והפריסה. ב-Jenkins 2.0, קבוצת Jenkins הציגה את Jenkinsfile כדי להשיג צינורית כקוד. אם אתה רוצה ליצור צינורית Jenkins מבוססת בקשות משובצות אוטומטיות או מבוססת ענפים רצון רציף והבא רציף, הצינורית המרובעת של Jenkins היא הדרך ללכת.

מאחר שצינורית רב-ענף של Jenkins היא באופן מלא מבוססת git כקוד, אתה יכול לבנות את זרימת העבודה שלך CI/CD. צינורית כקוד (PaaC) מקל על הביצועים של אוטומציה וניידות ענן ל-Selenium שלך. אתה יכול להשתמש במודל צינורית רב-ענף כדי לבנות, לבדוק, לפרוס, לנטר, לדווח ולנהל את בדיקות Selenium שלך במהירות ובאמינות, ועוד הרבה יותר. במדריך Jenkins זה, אנו מסתכלים על איך ליצור צינורית רב-ענף של Jenkins ועל המושגים העיקריים המעורבים בהגדרת צינורית רב-ענף של Jenkins לבדיקות אוטומציה של Selenium.

בואו נתחיל.

מהי צינורית רב-ענף של Jenkins?

על פי התיעוד הרשמי, סוג משימת צינורית רב-ענף מאפשר לך להגדיר משימה שממנה מאחד מאגר git, Jenkins יגילה ענפים מרובים ויצור משימות מקופלות כאשר הוא מוצא Jenkinsfile.

מההגדרה הנ"ל, אנו יכולים להבין שג'נקינס יכול לסרוק את המאגר של גיט לעבור Jenkinsfile וליצור משימות באופן אוטומטי. כל מה שהוא צריך מאיתנו הוא פרטים על המאגר של גיט. במאמר זה, אנו הולכים להשתמש במאגר דוגמה של GitHub. המאגר הדוגמה של GitHub שלנו מכיל פרויקט דוגמה של Spring Boot, שניתן לפרוס ל-Tomcat.

בספריית השורשים של הפרויקט, יש לנו את Jenkinsfile. השתמשנו בתחביר של צינורית הצהלה של ג'נקינס כדי ליצור את Jenkinsfile זה. אם אתה חדש בצינורית הצהלה של ג'נקינס, אנא קרא את המאמר המפורט שלנו כאן.

דוגמה Jenkinsfile

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

יצרנו שני שלבים "לבנות קוד" ו"לפרוס קוד" ב-Jenkinsfile שלנו, כל אחד מהם מותאם כדי להדפיס הודעות מתאימות. עכשיו, יש לנו את המאגר של גיט עם Jenkinsfile מוכן.

בואו ניצור צינורית רב-ענף בשרת ג'נקינס.

צינורית ג'נקינס מול צינורית רב-ענף

צינורית ג'נקינס היא החום החדש, אך היא אינה עבור כולם. וצינוריות רב-ענף עדיין מדהימות. בחלק זה של הדרכת צינורית רב-ענף של ג'נקינס, בואו נבין את המקרים האידאליים לשימוש בצינורית ג'נקינס וצינורית רב-ענף דרך ההשוואה בין צינורית ג'נקינס לצינורית רב-ענף.

זרם Jenkins הוא מערכת קבלן עבודות המאפשרת לך לקבוע זרם של עבודות, שיופעלו אוטומטית על שמך. זרם Jenkins יכול להכיל מספר שלבים וכל שלב יופעל על ידי סוכן יחיד, כולם פועלים על מחשב יחיד או מספר מחשבים. זרם הוא בדרך כלל נוצר עבור ענף ספציפי של קוד מקור. כשאתה יוצר עבודה חדשה, תראה אפשרות לבחירת מאגר הקוד המקור והענף. אתה יכול גם ליצור זרם חדש עבור פרויקט חדש או תכונה חדשה של פרויקט קיים.

זרם Jenkins מאפשר לך לקבל Jenkinsfile גמיש עם שלבים לבניית הבנייה שלך. אז, אפשר לקבל שלב ראשון שבו מרוצים בינטורינג, בדיקות וכו 'ואז שלבים נפרדים לבניית אבטיחים או פריסתם. זה מאוד שימושי כשאתה רוצה לעשות דברים מרובים בזרם שלך.

מה אם יש לך רק דבר אחד לעשות? או אם כל הדברים שאתה רוצה לעשות שונים תלויים בכמה תצורה? האם זה הגיוני להשתמש בזרם Jenkins כאן?

זרם מרובע הוא גישה חלופית שעשויה להתאים יותר במקרים אלה. זרם מרובע מאפשר לך להפריד משימות לסניפים ולשלב אותם בהמשך. זה מאוד דומה לדרך שבה פועל גיט סניפות.

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 לבין זרם מרובע, בוא נלך דרך השלבים ליצירת זרם מרובע Jenkins.

יצירת זרם מרובע Jenkins

שלב 1

פתח את דף הבית של Jenkins (http://localhost:8080 במקום המקומי) ולחץ על "פריט חדש" מהתפריט משמאל.

שלב 2

הזן שם משימת Jenkins, בחר את הסגנון כ“צינורית מרובת סבבים,” ולחץ על “אישור.”

שלב 3

בדף “כונן” צריך להגדיר רק דבר אחד: מקור המאגר Git.

גלול למטה לסעיף “מקורות סבבים” ולחץ על מסתכלת “הוסף מקור”.

בחר “GitHub” כמקור מכיוון שהמאגר הדוגמא שלנו ב-GitHub מאוחסן שם.

שלב 4

הזן את כתובת ה-URL האנתפס של המאגר כ-https://github.com/iamvickyav/spring-boot-h2-war-tomcat.git ולחץ על “אימת.”

מאחר שהמאגר שלנו ב-GitHub מאוחסן כמאגר ציבורי, אין צורך להגדיר זכותות גישה לגישה אליו. למאגרים תעודתיים/פרטיים, עשויים נדרשות זכותות לגישה אליהם.

הודעת “זכותות בסדר” מייצגת את החיבור המוצלח בין שרת Jenkins למאגר Git.

שלב 5

השאר את שאר סעיפי ההגדרה כך לעת עתה ולחץ על כפתור “שמור” בתחתית.

עם השמירה, Jenkins יבצע את הפעולות הבאות אוטומטית:

סריקת מאגר הצעד

• לסרוק את המאגר Git שהגדרנו.
• לחפש את רשימת הענפים הזמינים במאגר Git.
• לבחור את הענפים שיש בהם Jenkinsfile.

צעד הבניה מבוצע

• לרוץ בניה לכל אחת מהענפים שנמצאו בשלב הקודם עם השלבים שצוינו ב-Jenkinsfile.

מהסעיף "Scan Repository Log"אנו יכולים להבין מה קרה במהלך שלב סריקת המאגר.

מאחר ויש לנו רק ענף master branch במאגר ה-git שלנו, הודעת סריקת המאגר אומרת "נבדקו 1 branches were processed."

לאחר שהסריקה הושלמה, Jenkins יוצר וירוץ משימת בניה לכל ענף שנבדק בנפרד.

במקרה שלנו, היה לנו רק ענף בשם master. לכן, הבניה תרוץ רק עבור הענף הראשי שלנו. אנו יכולים לבדוק זאת על ידי לחיצה על "Status" בתפריט השמאלי.

אנו יכולים לראות משימת בניה שנוצרה עבור הענף הראשי בסעיף הסטטוס.

לחץ על שם הענף כדי לראות את יומן משימת הבניה ואת הסטטוס.

"Stage View" מספק ייצוג ויזואלי של כמה זמן לקח לכל שלב לבצע ואת סטטוס משימת הבניה.

גישה ליומני ריצת משימת הבניה

שלב 1

לחץ על "Build number" תחת "Build history" סעיף.

שלב 2

לאחר מכן, בחר ב"Console Output" מהתפריט השמאלי כדי לראות את היומנים.

מה קורה אם יש לנו יותר מענף אחד במאגר ה-Git שלנו? בואו נבדוק את זה עכשיו.

במאגר ה-Git, נוצר ענף חדש בשם "develop".

כדי להבדיל בין ה"בניית ענף פיתוח" בוצעו שינויים קטנים בפקודות echo ב-

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 Multibranch Pipeline

שלב 1

לחץ על "הגדרות" מתפריט הצד השמאלי.

שלב 2

התחל על הפריסת מקלט מסעיף "Scan Repository Triggers" והפעל את התיבת הסימון "Periodically if not otherwise run" ובחר במרווח הזמן שבו הסוק יתבצע באופן תכוף (שתי דקות בדוגמה שלנו).

שלב 3

לחץ על כפתור "Save".

מעתה, Jenkins יסקר את המאגר כל שתי דקות. אם מצאת קומיט חדש בכל ענף, Jenkins יפעיל עבודת בנייה חדשה עבור אותו ענף באמצעות Jenkinsfile.

להלן הודעת ההתראה "Scan Repository Log", שמפרטת בבירור את הסקת המאגר שנעשית כל שתי דקות.

מקרים שימוש בזמן אמת עבור צינורית רב-ענפית Jenkins

להלן מספר תרחישים בהם צינורית רב-ענפית Jenkins יכולה להיות שימושית:

• כל קומיט חדש בענף הראשי צריך להתפרס בשרת באופן אוטומטי.
• אם מפתח מנסה להעלות בקשת משאבה (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 החדש הזה בענפי ה-master ו-develop, כך שיוכל להתגלות על ידי Jenkins multibranch בסריקת המאגר הבאה.

בדיקות אוטומציה של Selenium עם Jenkins Multibranch Pipeline

בואו נניח שאנו כותבים בדיקות אוטומציה לאתר. כשמCommitting בדיקה חדשה בענף, אנו רוצים להפעיל אותן ולוודא שהן פועלות כצפוי.

הפעלת בדיקות אוטומציה על כל שילוב של דפדפן ומערכת הפעלה היא סיוט לכל מפתח. כאן מהפיכת LambdaTest של תשתית הבדיקות האוטומציה יכולה להוכיח את ערכתה.

באמצעות רשת Selenium של LambdaTest, תוכלו להגדיל את כמות הדפדפנים שלכם.

בסעיף זה, נראה כיצד לנצל את תשתית הבדיקות של LambdaTest עם Jenkins multibranch pipeline. להדגמה, ארגנו אפליקציה דוגמא של Todo כאן – אפליקציית LambdaTest ToDo. בדיקות אוטומציה שנכתבו עם Cucumber מו�Committing במאגר הדוגמא.

מ-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 כזרם רב-ענייני על ידי ביצוע השלבים המוזכרים בסעיפים לעיל. בואו נכוון למאגר הדוגמה.

ברגע שהבניה תסתיים בהצלחה, גשו ללוח הבקרה של LambdaTest לבדיקות אוטומציה כדי לקבל את יומני הבדיקות.

מסקנה

עם זאת, למדנו כיצד ליצור זרם רב-ענייני ב-Jenkins, כיצד להגדיר בו מאגר git, שלבי בניה שונים לענפים שונים, באמצעות סריקה אוטומטית תדירה של המאגר על ידי Jenkins ושימוש במבנה בדיקות אוטומציה חזק של LambdaTest כדי לאוטומט בניה ה-CI/CD שלנו. אני מקווה שמצאתם את המאמר הזה מועיל. אנא שתפו את המשוב שלכם בחלק התגובות.