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

"אצלנו לא עובדים על גרסאות במקביל..."

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

שאלות הכוונה:

האם אני צריך לתמוך בפיתוח מקבילי?

• פיתוח מס' גרסאות של המוצר
• טיפול בתקלות בגרסאות ששוחררו (Service Packs & Hot Fixes)

האם אני צריך סביבות פיתוח מבודדות?

• הוספת שינויים מהותיים – breaking changes
• Refactoring
• ייצוב

אם ענית בחיוב לחלק מן השאלות, אתה צריך לשקול מעבר למודל של branching.
ישנם מס' מודלים עליהם תוכל לבסס את מבנה עץ ניהול התצורה בהתאם לצרכים הייחודיים שלך.
כאשר אתה בוחן את המודל יש להביא בחשבון את הנושאים הבאים:

• גודל קבוצת הפיתוח, מבנה הצוותים ואופי העבודה
• הצורה בה משחררים גרסאות לייצור והאם יש צורך לתמוך ב- service packs ואולי אף hot fixes

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

בפוסט הבא נדבר על המודלים הבאים:

1. Basic Plan

2. Standard Plan

3. Advanced Plan

שירותי MCS רלוונטיים