TFS – כלי לניהול קוד במערכות מבוזרות

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

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

פיתוח התוכנה, שבו קיים מצב של היפר תחרות (Hypercompetition), הופך להיות קריטי ויותר ויותר להצלחה העסקית. ה-Visual Studio, בשילוב ה-ALM (ר"ת Application Lifecycle Management), מביא יתרונות עצומים ומצעיד את הארגון צעד אחד קדימה. פיתוח תוכנה אמין ונכון בעולם רב מימדי שהולך ונהיה מורכב יותר ויותר הינו מחויב המציאות.

הפתרון מצוי בפיתוח דרך TFS (ר"ת Team Foundation Server). יצוין כי TFS לא כולל רק את פיתוח התוכנה, אלא מדובר בניהול כולל של מחזור הפיתוח: הגדרת דרישות מהתוכנה, תיאור תקלות או תקלות פוטנציאליות בפתרון המוצע, אירועים או מצבים שעלולים להתרחש, אשר יש להם השפעה שלילית על הפרויקט, משימות פיתוח ועוד.

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

במערכת הבדיקות המורחבת יש MTM (ר"ת Microsoft Test Manager). היא מהווה חלק אינטגרלי מה-Visual Studio, משמשת לכתיבת תסריטי בדיקה ומאפשרת לבחון לעומק את מחזור החיים המשותף של שלבי הפיתוח.

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

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

WorkItems ומה שביניהם

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

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

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

חשוב מאוד להבחין בין שינוי מבוקש בתוכנה ובין דרישת שינוי (Requirement), המציגה תיאור או דרישה מה התוכנה צריכה לעשות על מנת לפתור תקלה או בעיה אצל הלקוח. ההבדלים העיקריים בין שתי הדרישות הם שדרישת שינוי לא מציגה צידוק או חיזוק מדוע היא נחוצה אלא את דרך היישום, איך היא יושמה וקישור למשימת פיתוח הנדרשת. ככלל, בקשות לשינוי בתוכנה יכולות לגרום (Affected By) לדרישת שינוי. בדרישות שינוי חשוב ורצוי לצרף את ה-Test Cases המתאימים שהביאו אליה, תחת החוצץ המתאים.

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

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

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

בחלקו השני של המאמר ארחיב על נושא הבילדים.

הכותב הינו מומחה DevOps בעולמות מיקרוסופט בחטיבת הבדיקות של נס (V-ness).