פריסת אפליקציות Heroku לסביבות בדיקה וייצור באמצעות GitLab CI/CD

במאמר קודם, בדקנו איך לאוטומט את ההפעלות ל- Heroku בשימוש ב- GitLab CI/CD. ההגדרה הזו הפעילה את האפליקציה בסביבת ההפקה כל פעם שהעלינו קוד לענף main.

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

בנוסף, כמה צוותי הנדסה עוקבים אחר אסטרטגיית Gitflow, שבה יש להם ענף dev וענף main. האסטרטגיה הזו נפילה מאז מחוץ לחן והוחלפה על ידי trunk-based development, אך לא נדיר למצוא ארגונים שעדיין עוקבים אחר המנהג הזה.

היום, נסתכל על איך להגדיר את GitLab CI/CD כדי להפיץ את האפליקציה שלנו לסביבת ההרצה המוכנה כשאנחנו מפיחים לגזרה dev ולהפיץ את האפליקציה שלנו לסביבת ההפקה כשאנחנו מפיחים לגזרה main.

התחלה

לפני שנתחיל, נצטרך שני דברים: חשבון ב-Heroku וחשבון ב-GitLab.

Heroku היא מקום נהדר לאירוח והפצה של האפליקציות שלך. כפלטפורמה כשירות (PaaS), Heroku מאפשרת לך להתרכז בבניית דברים מגניבים תוך הפשטת חלק ניכר ממורכבות התשתית. אתה יכול ליצור חשבון ב-Heroku כאן.

GitLab היא מקום נהדר לאיחסון הקוד שלך. מעבר להיותה כלי לניהול קוד מקור, GitLab גם מציעה יכולות CI/CD מובנות כך שתוכל להגדיר תעלות כדי לבדוק ולהפיץ את הקוד שלך בלי להצטרך להשתמש בכלי שלישי. אתה יכול ליצור חשבון ב-GitLab כאן.

האפליקציה הדמו שמוצגת במאמר זה משתמשת ב-both GitLab ו-Heroku. אתה יכול למצוא את כל הקוד במאגר GitLab כאן.

הרצת האפליקציה באופן מקומי

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

$ git clone https://gitlab.com/tylerhawkins1/heroku-gitflow-staging-production-gitlab-cicd-demo.git
$ cd heroku-gitflow-staging-production-gitlab-cicd-demo
$ npm install
$ npm start

לאחר התחלת האפליקציה, בקר את המארח המקומי בדפדפן שלך, ותראה שהאפליקציה רצה באופן מקומי:

אפליקציית הדגמה בהרוקו

הפצת האפליקציה שלנו להרוקו

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

זכור שאנחנו הולכים להפיץ את האפליקציה שלך לשתי סביבות: סביבת ניסוי וסביבת ייצור. זה אומר שיהיו לנו שתי אפליקציות הרוקו המבוססות על אותה מאגיזה GitLab.

אם אין לך את CLI של הרוקו מותקן על המכשיר שלך, תצטרך להתקין אותו לפני שתמשיך.

לאחר התקנת CLI של הרוקו, רץ את הפקודות הבאות מהמסוף שלך כדי לבדוק את הענף main, ליצור אפליקציה חדשה של הרוקו בסביבת ייצור, להפיץ אותה לסביבת הייצור ולפתוח אותה בדפדפן שלך:

$ git checkout main
$ heroku create heroku-gitlab-ci-cd-production --remote heroku-production
$ git push heroku-production main
$ heroku open --remote heroku-production

עם זה, אתה שווה לראות את אותה האפליקציה, אבל הפעם רצה בכתובת URL של הרוקו במקום ב-localhost. עבודה טובה — הפצת את אפליקציית ההרוקו שלך לייצור!

אבל, אנחנו עדיין לא סיימנו. אנחנו גם צריכים להגדיר ולה

$ git checkout dev
$ heroku create heroku-gitlab-ci-cd-staging --remote heroku-staging
$ git push heroku-staging main
$ heroku open --remote heroku-staging

עכשיו יהיה לך את אותה האפליקציה מוצבת שוב, אבל הפעם לכתובת URL שונה שתשמש כסביבת הריצה שלך (staging environment). עכשיו יש לנו שתי הסביבות שלך מוכנות!

שים לב להבדלים ולדמיונים בין הפקודות לאפליקציה בייצור (production) ולאפליקציה בסביבת הריצה:

1. האפליקציה בייצור משתמשת בענף main, והאפליקציה בסביבת הריצה משתמשת בענף dev.
2. שם האפליקציה בייצור הוא heroku-gitlab-ci-cd-production, ושם האפליקציה בסביבת הריצה הוא heroku-gitlab-ci-cd-staging.
3. שם המרחק הגיט באפליקציה בייצור קרוי heroku-production, ושם המרחק הגיט באפליקציה בסביבת הריצה קרוי heroku-staging.
4. גם המרחק הגיט של האפליקציה בייצור וגם של האפליקציה בסביבת הריצה משתמשים בענף main, מכיוון שHeroku מוצבת את האפליקציה רק כאשר קוד נלחץ לענף המרכזי שלה.

תזכור שזה ענף main שונה משלך מערכת ענפים main וdev. הענף main אליו אתה מלחץ כאן הוא הענף main במרחק הגיט שלך — במקרה הזה, Heroku.

אז כשאתה נמצא בגזע המקומי main ומריץ git push heroku-production main, אתה מעלה את גזע הmain שלך לגזע main של אפליקציית ה-HEROKU בייצור. וכשאתה נמצא בגזע המקומי dev ומריץ git push heroku-staging main, אתה מעלה את גזע הdev שלך לגזע main של אפליקציית ה-HEROKU בתצוגה.

עשיית שינויים באפליקציה שלנו

עכשיו כשיש לנו את אפליקציית ה-HEROKU שלנו פעילה, מה אם נרצה לעשות כמה שינויים? בהתבסס על חיקוי גס של אסטרטגיית Gitflow, יכולנו לעשות את הבאים:

1. לבדוק את הגזע dev
2. לעשות שינויים בקוד
3. להוסיף, להקיש ולהעלות את השינויים אל הגזע dev
4. להפיץ את השינויים אל אפליקציית ה-HEROKU בתצוגה על ידי הרצת git push heroku-staging main
5. לבדוק את הגזע main
6. למזג את הגזע dev לתוך הגזע main
7. להפיץ את השינויים אל אפליקציית ה-HEROKU בייצור על ידי הרצת git push heroku-production main

(אם היינו באמת מבצעים את Gitflow, היינו יוצרים גזע מאפיינים למיזוג לתוך dev, וגזע שחרור למיזוג לתוך main, אבל הוסיפנו את השלבים האלה כדי לשמור על פשטות.)

עכשיו, האם זה לא יהיה נחמד אם יכולנו לאוטומט את ההפצה לאחת מהסביבות שלנו במקום להפיץ אותם ידנית כל הזמן?

זה המקום שבו GitLab CI/CD

אינטגרציה מתמשכת/הפצה מתמשכת

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

הפצה מתמשכת (CD) היא על הפצה בתדירות גבוהה. אם הבדיקות בפיפלין CI עוברות, אז הבנייה מופצת. אם הבדיקות בפיפלין CI נכשלות, אז הבנייה לא מופצת.

עם GitLab CI/CD, אנחנו יכולים להגדיר את פיפלין CI שלנו לעשות בדיוק זאת — לרוץ את הבדיקות שלנו ואז להפיץ את האפליקציה שלנו להרוקו אם כל הבדיקות עוברות. הדבר החשוב ביותר להגדרה שלנו, אנחנו יכולים להגדיר חוקים בתוך פיפלין CI שלנו לציין לאן האפליקציה צריכה להיות מופצת.

הגדרת GitLab CI/CD

אנחנו יכולים ליצור פיפלין CI ב-GitLab באופן תוכנה על ידי שימוש בקובץ .gitlab-ci.yml. הקובץ שלנו נראה כך:

image: node:20.10.0

cache:
  paths:
    - node_modules/

before_script:
  - node -v
  - npm install

stages:
  - test
  - deploy

unit-test-job:
  stage: test
  script:
    - npm test

deploy-job:
  stage: deploy
  variables:
    HEROKU_APP_NAME: $HEROKU_APP_NAME_PRODUCTION
  rules:
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      variables:
        HEROKU_APP_NAME: $HEROKU_APP_NAME_PRODUCTION
    - if: $CI_COMMIT_REF_NAME =~ /dev/
      variables:
        HEROKU_APP_NAME: $HEROKU_APP_NAME_STAGING
  script:
    - apt-get update -yq
    - apt-get install -y ruby-dev
    - gem install dpl
    - dpl --provider=heroku --app=$HEROKU_APP_NAME --api-key=$HEROKU_API_KEY

פיפלינים CI ב-GitLab מורכבים משלבים ומשימות. כל שלב יכול להכיל יותר ממשימה אחת. בפיפלין שלנו, יש לנו שני שלבים: test ו-deploy. בשלב test, אנחנו מריצים את בדיקות היחידה שלנו ב-unit-test-job. בשלב deploy, אנחנו מפיצים את האפליקציה שלנו להרוקו ב-deploy-job.

אנחנו יכול

תשימו לב ששלב הdeploy כולל חלק rules עם לוגיקה תנאית. זה המקום שבו אנחנו מציינים לאיזה סביבה יש להפיץ את האפליקציה שלנו. אם אנחנו נמצאים בענף main, אז אנחנו מפיצים את האפליקציה המוכנה לייצור. אם אנחנו נמצאים בענף dev, אז אנחנו מפיצים את האפליקציה המוכנה לבדיקה.

תשימו לב גם ששלב הdeploy מתייחס למספר משתנים הנקראים $HEROKU_APP_NAME_PRODUCTION, $HEROKU_APP_NAME_STAGING ו$HEROKU_API_KEY. אלה נאחסנים כמשתני CI/CD בתוך GitLab.

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

Heroku API key

לאחר מכן, בפרויקט GitLab שלכם, תלחצו על הגדרות > CI/CD > משתנים. פתחו את החלק הזה והוסיפו שלושה משתנים חדשים:

1. הערך ל$HEROKU_API_KEY יהיה מפתח הAPI מחשבון Heroku שלכם.
2. הערך ל$HEROKU_APP_NAME_PRODUCTION יהיה שם האפליקציה המוכנה לייצור שלכם. שם האפליקציה המוכנה לייצור שלי הוא heroku-gitlab-ci-cd-production, אך מאחר ושמות אפליקציות Heroku הם ייחודיים גלובלית, שלכם יהיה שונה.
3. הערך עבור $HEROKU_APP_NAME_STAGING יהיה שם אפליקציית הרוקו שלך לאינטגרציה. שם אפליקציית האינטגרציה שלי הוא heroku-gitlab-ci-cd-staging. שוב, מכיוון ששמות אפליקציות הרוקו הם ייחודיים באופן אוניברסלי, שלך יהיה משהו אחר.

GitLab CI/CD variables

עם זה, תהליך CI של GitLab מוכן לצאת! בוא נבדוק אותו.

הפעלת אפליקציית הרוקו לסביבת האינטגרציה

בוא נבדוק את הענף dev ונעשה שינוי לקוד באפליקציה שלנו. שיניתי שינוי פשוט לטקסט בכותרת והוספתי כמה שורות חדשות לטקסט בממשק המשתמש. אתה יכול לעשות שינוי דומה בקוד שלך.

עכשיו, הוסף, הכנס ודחף את השינוי הזה לענף dev. זה יתחיל את תהליך CI של GitLab. אתה יכול לראות את התהליך בתוך GitLab ולראות את ההתקדמות בזמן אמת.

GitLab CI pipeline build for the dev branch

אם הכל יעבוד נכון, אתה צריך לראות ששני השלבים test ו-deploy עברו. עכשיו, בדוק את אפליקציית הרוקו שלך בכתובת הסביבה של האינטגרציה. תהליך CI של GitLab טיפל בהפעלת האפליקציה עבורך, אז עכשיו תראה את השינויים בסביבת האינטגרציה בחיים!

Demo Heroku app with updated copy

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

עכשיו, בדוק

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

הפעלת האפליקציה שלנו ב-Heroku לסביבת הייצור

בואו נבדוק את הענף main ואז נמיזג את הענף dev לענף main שלך. אתה יכול לעשות זאת דרך בקשת החילופין (pull request) או על ידי ריצת git merge dev ואז git push.

זה יתחיל את תהליך CI של GitLab שוב, אבל הפעם הוא יהיה מוכן להרצת האפליקציה של הייצור.

GitLab CI pipeline build for the main branch

אתה יכול גם לראות את כל תהליכי הרצה בדף הצינורות (Pipelines) ב-GitLab כדי לראות את הבנייה השונה לענפים dev ו-main:

All GitLab CI pipeline builds

ברגע שהצינור (pipeline) מסתיים, בקר בכתובת ה-URL של האפליקציה שלך ב-Heroku. עכשיו אתה צריך לראות את השינויים שלך גם בהרצה בייצור. עבודה נפלאה!

סיכום

A good CI pipeline allows you to ship new features quickly and confidently without manually managing the deployment process. Having multiple environments configured for local development, staging, and production gives you more control over where and when code is released.

Heroku ו-GitLab CI/CD מאפשרים לך לאוטומט את כל זה כדי להקל על תהליכי DevOps שלך!