עיבוד בקשות מיידיות למיזוג היה נושא של דיון בקהילת המפתחים מאז הופעת שיטות אג'יל ופרקטיקות דבוס.
במצבים כאלה, אנו זקוקים למערכת המעדיפה את הבקשות ה'חדירות' מעל בקשות רגילות למיזוג ומאפשרת לנו לדחות בדיקות CI מסוימות אם זה הכרחי.
אסטרגיה טובה אחת יכולה להיות ליישם תור מיזוג נפרד לגמרי, שמאפשר לנו להתחבר לתור הברירת מחדל אפילו לפני שהבדיקות CI עברו ולהאט את התיקונים החדירים שלנו לייצור.
במאמר זה, נוצר שני תורים למיזוג באמצעות Mergify המופעל על ידי תוויות בקשה. נכבה אחת לבקשות רגילות למיזוג והשנייה לבקשות מיידיות למיזוג.
אז בואו נתנסח ונתחיל!
לדוגמה זו, נתחיל אפליקציה פשוטה בReact
. ולבדיקות CI, נשתמש בCircleCI
.
ניצור שני תורים למיזוג:
ברירת מחדל
: כל הבקשות יעברו דרכו באופן רגיל. דורש בדיקותCircleCI
לפני עיבוד.חדיר
: תור זה מיועד רק לבקשות שיש להן את תווית החדיר
בבקשה. מאפשר לבקשות לקפוץ לחלק הקדמי של בקשות בתור הברירת מחדל ללא ריצת בדיקות CircleCI.
עם תצורה כזו, בקשה למיזוג עם התווית חדיר
תיכנס לתור לפני שCI ממש מריץ עליה.
היא תהיה בחלק הקדמי של התור הברירת מחדל. Mergify יעדכן את הבקשה למיזוג עם הענף הבסיסי אם זה הכרחי, יחכה עד שה-CI יעבור, ואז ימיזג את הבקשה.
מנקודת מבטם של קבוצת הפיתוח גם כן, זהו תהליך פשוט למדי. המפתח רק צריך להוסיף תווית חד-שמע
בעת יצירת ה-PR כדי להאיץ את התהליך.
הכנת פרויקטנו
בואו נתחיל בהכנת הפרויקט שלנו. נוציא אפליקציה רענן חדשה באמצעות create-react-app
.
mkdir emergency-pr-demo
cd emergency-pr-demo
git init
npx create-react-app .
לצורך התייחסות, זה יהיה מבנה הפרויקט הסופי שלנו לאחר שנוסיף את ה-CI ואת קונפיגורציית Mergify שלנו.
emergency-pr-demo/
├── .circleci
│ └── config.yml
├── README.md
├── package-lock.json
├── package.json
├── .gitignore
├── .mergify.yml
├── .vscode
├── public
│ ├── favicon.ico
│ ├── index.html
│ ├── logo192.png
│ ├── logo512.png
│ ├── manifest.json
│ └── robots.txt
└── src
├── App.css
├── App.js
├── App.test.js
├── index.css
├── index.js
├── logo.svg
├── reportWebVitals.js
└── setupTests.js
יצירת קונפיגורציה CI
לביצוע הבדיקות שלנו, נשתמש ב-CircleCI. קל להגדיר ולהתחיל איתו.
כאן, נוציא קובץ config.yml
במדרגה חדשה .circleci
בשורשי הפרויקט שלנו.
נוציא משימה פשוטה build_and_test
שתתחיל בסיוע לנו לבדוק אם הפרויקט שלנו נבנה כצפוי ואז נריץ את הבדיקות היחידות עם פקודת npm run test
.
version: 2.1
orbs:
node: circleci/[email protected]
jobs:
build_and_test:
executor: node/default
steps:
- checkout
- node/install-packages:
pkg-manager: npm
- run:
command: npm run test
name: Run tests
- run:
command: npm run build
name: Build app
- persist_to_workspace:
root: ~/project
paths:
- .
workflows:
test_my_app:
jobs:
- build_and_test
.circleci/config.yml
יצירת קונפיגורציה Mergify
עכשיו הגיע הזמן ליצור את קובץ הקונפיגורציה שלנו ב-Mergify.
Mergify הוא כלי שמאולץ את תהליך השילוב של בקשות המשוב במאגרי הקוד על פי כללים ותנאים קבועים מראש.
אנו צריכים להגדיר שני תורים בקובץ הקונפיגורציה שלנו כצפוי: חד-שמע
ו-ברירת מחדל
.
שניהם יש את אותו merge_conditions, check-success=ci/circleci: build_and_test
, מה שאומר שהקוד חייב לעבור בהצלחה את הבדיקה build_and_test
בCircleCI
לפני שהוא יכול להימרגר.
הקטע pull_request_rules
מפרט איך ממשקי משאבות צריכים להיות מנוהלים. אנו נשים את ה-PR שלנו בתור urgent
אם יש לו את התווית דחוף. אחרת, הוא ייכנס לתור הברירת מחדל.
.mergify.yml
queue_rules:
- name: urgent
merge_conditions:
- "check-success=ci/circleci: build_and_test"
- name: default
merge_conditions:
- "check-success=ci/circleci: build_and_test"
pull_request_rules:
- name: move to urgent queue when label urgent
conditions:
- base=main
- label=urgent
actions:
queue:
name: urgent
- name: merge using the default queue after running the CI checks
conditions:
- base=main
- "check-success=ci/circleci: build_and_test"
- label!=urgent
actions:
queue:
name: default
הכנת המאגר
לא, היינו ממשיכים ויוצרים מאגר חדש ב-GitHub.
לאחר מכן, אנו צריכים לבצע מאמץ ראשון ולדחוף את הקוד שלנו באמצעות הפקודות הבאות:
git add .
git commit -m "Initial commit"
git remote add origin <REPO_URL>
git push -u origin master
לאחר מכן, אנו צריכים להגדיר את CircleCI. לשם כך, נבקר בלוח המחוונים של CircleCI, ולאחר מכן נלך לסעיף הפרויקטים ונקבע את הפרויקט שלנו.
אנו גם צריכים לציין את הענף main
. CircleCI יזהה אוטומטית את קובץ הconfig
שלנו במקרה זה.
אנו יכולים להתקין את Mergify בחשבון שלנו ב-GitHub על ידי ביקור בdashboard.mergify.com או github.com/apps/mergify/installations/new וכניסה עם החשבון שלנו ב-GitHub.
לאחר מכן, נוכל לבחור את המאגרים להם אנו רוצים לתת גישה ל-Mergify.
לאחר ההגדרה, נוכל לראות את שתי התורים שלנו בלוח הבקרה של Mergify.
כאשר מעלים את ה-PR הראשון (PR רגיל)
עכשיו בואו נתחיל ביצירת ה-PR הראשון שלנו. ניצור תחילה סנן חדשה regular-pr
git checkout -b regular-pr
git add .
רק למטרות הדגמה, נוסיף עכשיו מחלקה בקובץ App.css
.
.Regular-change-class {
background-color: white;
}
לאחר מכן, נבצע יחידת קריאה ונעלה את השינויים שלנו ל-GitHub.
git commit -m 'regular CSS change'
git push --set-upstream origin regular-pr
לאחר מכן, נעלה בקשת שיחרור ללא תגיות.
כאשר מעלים את ה-PR השני (PR דחוף)
כעת ניצור סנף חדש urgent-pr
, לשינויים שלנו.
git checkout main
git branch -b urgent-pr
קודם כל, נבצע commit
, שם נוצר רכיב חדש Urgent.js
.
import React from "react";
export default function Urgent() {
return <div>This is an Urgent Change</div>;
}
עכשיו, נעלה את הסנף (urgent-pr
) למאגר ה-GitHub שלנו.
git add .
git commit -m 'Create a component for Urgent change'
git push --set-upstream origin urgent-pr
לאחר מכן, נלך למאגר שלנו ונעלה בקשת שיחרור חדשה מסנף urgent-pr
לסנף main
ונוסיף תווית חדשה urgent
.
Mergify מזיז את ה-PR השני לתור urgent
ואז מריץ בדיקות CI וממיר אותו לסנף main
.
לאחר מכן, הוא ממיר את ה-PR הראשון אוטומטית.
אפשר לבדוק את מאגר GitHub כאן לשם התייחסות: github.com/hugoescafit/emergency-pr-demo
סיכום
זה הכול לפעם זו!
במדריך זה, בחנו את התהליך של הגדרת שתי תורים מיזוג שונים, ברירת מחדל וחדירה, בעזרת Mergify והגדרת בדיקות CI בעזרת CircleCI. ראינו גם כיצד לקדם פרויקטים חדשים חירום על פני רגילים.
ישנם פתרונות נוספים רבים לניהול בקשות משובצת חירום, כגון יצירת ענף חיבורי חם מיוחד עבורם, בעלי בקרים מיוחדים, ואפילו השלכה על ידי שיקול דעת. אך תורי המיזוג הם אחת האסטרטגיות הטובות והקלות ליישום ביותר לטפל בבעיה זו.
בקרו בMergify כדי להתחיל להוסיף תורי מיזוג ליישום שלכם!
Source:
https://dzone.com/articles/handling-emergency-pull-requests-using-merge-queue