מהי זרימת עבודה מבוססת מהדורה?

הושלמה

כאן נדון באופן שבו ניתן ליצור זרימת עבודה מבוססת מהדורה באמצעות GitHub.

מהי זרימת עבודה מבוססת מהדורה?

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

תכנון עבודה עם לוחות פרוייקטים של GitHub

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

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

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

קבל מידע נוסף ניהול לוחות פרוייקטים.

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

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

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

מעקב אחר אבני דרך ספציפיות

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

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

קבל מידע נוסף מעקב אחר התקדמות העבודה שלך בעזרת אבני.

בחירת אסטרטגיית יצירת הסתעפות

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

זרימת GitHub

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

עבודה עם ענפים בעלי חיים ארוכים

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

עם זאת, קיימים תרחישים מסוימים שבהם ענף שחי זמן רב משרת את האינטרסים הטובים ביותר של צוות. המקרה הנפוץ ביותר עבור ענף בעל חיים ארוכים הוא כאשר למוצר יש גירסאות מרובות שיש לתמיכה לאורך פרק זמן מותך. כאשר צוות צריך לתכנן את המחויבות הזו, על המאגר לפעול לפי מוסכמה רגילה, כגון release-v1.0, release-v2.0וכן הלאה. הסתעפויות אלה אמורות להיות מסומנות גם כמוגנות ב- GitHub כך שהגישה לכתיבה נשלטת ולא ניתן למחוק אותן בטעות.

Teams עדיין צריך לשמור main כאשר ענף הבסיס ולמזג את ענף ההפצה שלהם משתנה במעלה הזרם כל עוד הם משתלבים בעתיד הפרוייקט. כאשר יגיע הזמן, release-v3.0 לבסס את המידע main כך שפעולות השירות עבור release-v2.0 לא יתסבך את המאגר.

מתן שירות לענפים שחיים לאורך זמן

נניח שתיקון באגים מוזג לתוך release-v2.0 ולאחר מכן מוזג שוב במעלה הזרם main. לאחר מכן, התגלה שבאג זה קיים גם בענף release-v1.0 והתיקון הדרוש לצורך תמיכה עבור לקוחות שעדיין משתמשים בגירסה זו. מהי הדרך הטובה ביותר לייווט לאחור של תיקון זה?

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

אפשרות חלופית היא לתרגל מחדש באופן ידני את התיקון בענף release-v1.0, אך גישה זו תדרוש עבודה מחדש רבה ולא להתאים את קנה המידה בין גירסאות מרובות. עם זאת, Git מציע פתרון אוטומטי לבעיה זו באופן של הפקודה cherry-pick שלו.

מהי פקודת בחירת הדובדבן של גיט?

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

קבל מידע נוסף בחירת הדובדבן של Git.

שחרור לצרכנים

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

יצירת גירסה היא פשוטה כמו מילוי הטופס:

• הזן תג Git להחלה, שאמור להיות גירסאות סמנטיות, כגון v1.0.2. GitHub מנהל את תהליך יצירת התגית Git שציינת.
• הזן שם עבור ההפצה שלך. חלק מהשיטות הנפוצות הן:
  • השתמש בשם תיאורי
  • השתמש בגירסת Git
  • השתמש בסיכום תמציתי של האופן בו המהדורה השתנתה מאז המהדורה הקודמת
  • שימוש בשם קוד או בצירוף מילים אקראי
• ספק הערות מוצר. באפשרותך להפוך משימה זו לאוטומטית באמצעות האפליקציה 'טיוטת מהדורה, המנתחת את השינויים מאז הגירסה הקודמת וכוללת את כותרות בקשות המשיכה המשויכות.
• אם ברצונך לספק קבצים כחלק מההפצה, כגון מתקינים שנבנו מראש, באפשרותך לגרור ולשחרר אותם בטופס. אינך צריך לארוז את המקור כפי ש- GitHub מטפל בזה עבורך באופן אוטומטי.
• ציין אם הגירסה היא קדם-ההתקנה על-ידי סימון תיבה זו. אינדיקציה זו מסייעת ללקוחות להימנע מגרסאות קדם-ההחלה אם הם רוצים בכך.

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

קבל מידע נוסף של GitHub.