"זליגת" בגים לאתר האינטרגציה היא תופעה מוכרת וכואבת. לפעמים זה בלתי נמנע (ולכן אין טעם אוטומטית לכעוס על המפתח שהכניס את הבג או על האחראי על ה-Gating שאיפשר זאת. יש בגים מערכתיים שיתגלו רק באינטרגציה. עד כאן הנחמות.
יש לא מעט שיטות שמתייחסות לנושא של ריבוי פיצ'רים ומיקבול העבודה עליהם. אני מניח שאתה מכיר או לפחות שמעת על רובן. הצרה היא שהן מדגישות השקעה מוקדמת בשלב התכן, ולא מספקות פתרונות אד-הוק לזמן האינטגרציה הלחוץ. Aspect-Oriented Programming היא דוגמא טובה, אך היא מתייחסת ליכולות-על כגון אבטחה, ביזור או ניהול משתמשים, ולא ליכולות-משנה שנוספות בתגובה לשינויי דרישות מזדמנים. לאילו מהמקרים הללו אתה מתייחס?
בכל מקרה, באתר אינטגרציה מצד אחד אין זמן לפתרונות מתוחכמים, ומצד שני אסור לזעזע את המערך. לכן יש לטעמי שתי שיטות שימושיות:
1. חזרה אחורה: אני מניח (ומקווה) שאתם עובדים עם סוג של מערכת בקרת תצורה. המפתח שהכניס את הבג ימשיך לעבוד על גרסא מקומית עד לפתרון הבג, ולאתר האינטגרציה יכנס Build עם גרסא אחת לפני הבג. צריך לתת תשומת-לב לקשרים בין check-ins, שבמקרים פטאליים חזרה אחורה במקום אחד מחייבת חזרה אחורה בשרשרת ארוכה של תיקונים ושינויים (כמו שאמר ברי סחרוף: "במקום החדק קיבלת את כל הפיל").
2. השיטה השניה ישימה במקרה והשיטה הראשונה מושכת אחריה פיל, או שקיימת סיבה אחרת להימנעות מלחזור אחורה. "עוטפים" את קטע הקוד בהתניה על דגל שנקרא ממנגנון הקונפיגורציה הנהוג במערכת שלכם. שינוי כזה יעשה את המוטל עליו ("יקצר" את הפיצ'ר), ויכול להישאר גם ב-Productuion. לדוגמא, אם בתת-מערכת ניהול משתמשים פיצ'ר ההרשמה התקלקל, ניתן לעטוף את הקוד בהתניה שמונעת אותו מלבצע את הפעולה, וניתן להשתמש בזה גם בעתיד כדי לחסום הוספת משתמשים במידה ורוצים לעצור התקפות על האתר.
מקווה שעזרתי.
הוספת תגובה על "ניהול פיצ'רים"
נא להתחבר כדי להגיב.
התחברות או הרשמה