הפעם אתמקד ב”ניהול תצורה” במובן מצומצם יחסית הנוגע בעיקר לאנשי הפיתוח בארגון: סביבות העבודה שלהם, אחסון הקבצים ושיתוף הקבצים בין אנשי הפיתוח.
להלן 10 התכונות שהן לדעתי חובה במערכת ניהול תצורה. אלה תכונות שהן בעיקרן קונספטואליות – ולא טכניות (אינני מתכוון לכתוב על checkin, checkout, labels וכו’ – אלו הדברים הבסיסיים ביותר, וכאלה ישנם בכל מערכת כיום).
התכונות שאמנה כאן הן תכונות “כבדות משקל” – כל אחת מהן מכילה בתוכה תתי-תכונות המרכיבות אותה.
סדר הכתיבה הוא לא בהכרח בהתאם לחשיבות. אני משאיר את התעדוף לכם הקוראים.
יאללה, מתחילים.
*** 1 *** אמינות ושלמות המערכת
בהרצאת מבוא לבסיסי נתונים למדתי פעם שהדבר הכי חשוב במערכת בסיס-נתונים הוא ה- “Data integrity" , ובלי זה המערכת לא שווה כלום. אותו הדבר נכון כמובן גם במערכת ניהול תצורה. בסופו של דבר , גם מערכת כזו מבוססת תשתיתית על בסיס-נתונים. לא הייתם רוצים שאחד המשתמשים יכניס קבצים מסויימים או גירסאות ספציפיות שלהם למאגר הנתונים המרכזי, ואז לגלות אחרי חודש שהקבצים חסרים…
דרישה זו היא הבסיס למערכת יציבה, שתורמת לסביבות פיתוח יציבות, לפיתוח גירסאות מוצר יציבות וללקוחות מרוצים.
כיום, עם התבגרות המערכות, רובן עומדות בדרישה זו בקרוב למאת האחוזים.
אנקדוטה קטנה: זכור לי מקרה שבו הייתי משתמש-קצה (מתכנת) מול מערכת שלא אזכיר את שמה (אך שמה כמעט זהה לכלי החינמי שיעדכן אתכם בפוסטים חדשים בבלוג זה J ) . יש מי שהסיפור יזכיר לו נשכחות, ומי שלא – לא נורא:
קיץ 1999
PC משתמשים
יום לפני סיום מדרגה 6
2 בלילה
או אז מגלים שחלק ניכר מהקבצים הלכו לאיבוד, ועבודה של שבוע (מסביב לשעון!) ירדה לטמיון … אה!!!!!!!@@@@!!!
לא המשכנו להשתמש במערכת הנ”ל לאחר מכן.
*** 2 *** תהליך ומערכת מונחית תהליך – ולא תהליך מונחה מערכת
התהליך עצמו חשוב מאוד: תהליך מוגדר יאפשר להגדיר שיטות עבודה למפתחים, מדיניות (Policies) לעבודת-צוות, תהליכי-משנה ש”ידברו” ביניהם ויאפשרו אינטגרציה קלה ו”חלקה” יותר, ועוד ועוד..
התהליכים, השיטות או המתודולוגיות צריכות להיות מוגדרים היטב כקונספט, ואז המערכת צריכה לממש טכנולוגית את אותם התהליכים הנ”ל – ולא להפך. לא תרצו להגדיר תהליך , ואז לגלות שמסיבות טכנולוגיות אתם מנועים מלממש פונקציות משמעותיות שהגדרתם בתהליך… לכן צריך מערכת שתהיה מספיק גמישה כדי להיות מותווה ע”י התהליך.
*** 3 *** פיתוח מקבילי ויכולת מיזוג חזרה
זוהי תכונה שימושית ביותר, שהצורך בה עלה מאוד בשנים האחרונות בכל החברות בהן יצא לי להקים מערכות כאלה. מערכת שתומכת בתכונה זו, מאפשרת ליצור קוי-פיתוח מקבילים בנוסף לקו הפיתוח המרכזי ותורמת לעבודה השיתופית. הנה כמה דוגמאות לצורך בקוי-פיתוח מקבילים:
-
קו פיתוח פרטי לכל מפתח: כל תכנת מקבל סביבה פרטית בה הוא יכול לשנות קבצים כמה שהוא רוצה ואיך שהוא רוצה, בלי להשפיע על קוי הפיתוח האחרים (מעין “ארגז חול”)
-
קו פיתוח לכל משימה/פיצ’ר, שעליו יעבדו כמה מפתחים
-
קו פיתוח לכל גירסת מוצר
-
קו פיתוח לכל גירסת שחרור / גירסת לקוח
-
קו פיתוח לכל פלטפורמה / מערכת הפעלה
ועוד ועוד.
כחלק מתכונה זו, חשוב שהמערכת תאפשר העברה נוחה של קבצים בין ענפי הפיתוח השונים (מ- ואל), יכולת מיזוג בין הענפים ויכולת מעקב של המיזוגים ושל השינויים בענפים.
*** 4 *** פיתוח מונחה משימות/שינויים
בשחר ההסטוריה של המערכות האלה, שינוי היה גירסא ספציפית של קובץ בודד, והוא לא נרשם או קוטלג במשמעות של תיקון או תוספת למוצר המפותח.
כיום התפיסה הרווחת ברוב המערכות היא ששינוי הוא סט לוגי של גירסאות ספציפיות של הקבצים התורמים לאותו השינוי. חשוב להבין שזהו למעשה הבסיס להכל – זיהוי תכולות של שינויים, אטומיות וטרנזקציות של פעולות (למשל: atomic check-in) , מעקב אחר שינויים, קווי בסיס (labels, baselines) המכילים את סט השינויים בתוכם, אינטגרציה למערכות ניהול-שינויים, פיתוח מבוסס רכיבים (components) ועוד.
אגב, כל מערכת קוראת לילד בשם אחר – change list, change set, activity, job, task ועוד – אך בכולן הכוונה זהה פחות או יותר.
*** 5 *** תמיכה בסביבות מבוזרות
זוהי תכונה שחשיבותה עלתה מאוד בשנים האחרונות.
את תכונה זו אחלק ל-2 :
א. תמיכה בריבוי של מערכות הפעלה (Cross-platform) ואפשרות חיבור ביניהן השקופה למשתמשי הקצה. לדוגמא: סביבות משתמשים שחלקן תחת MS-Windows וחלקן תחת Linux , אך "מדברות" ביניהן בצורה שקופה.
ב. תמיכה באתרים מרוחקים (Geographically distributed sites) ובמשתמשים מרוחקים בצורה שקופה למשתמשי הקצה. לדוגמא: בחברת AbraCadabra , מרכז הפיתוח העיקרי נמצא בהרצליה פיתוח, אך ישנם גם מפתחים היושבים ב- Bangalore , הודו. המפתחים האחרונים צריכים גם הם גישה אמינה ונוחה למערכת ניהול התצורה שמרכזה בישראל.
*** 6 *** מערכת פתוחה
נא לא להתבלבל עם מערכות קוד-פתוח – לא זו כוונתי.
מערכת פתוחה היא כזו המאפשרת להוסיף תכונות למערכת או לשנות בה תכונות מסויימות. בד"כ הצורך בכך הוא כדי לשפר את תאימות המערכת לצרכי המשתמשים (Customization) .
מערכת פתוחה תתמוך בתוכנות צד ג', Command Line Interpreter, APIs ו- SDK , שבעזרתם ניתן יהיה לבצע אוטומציות של תהליכים, אינטגרציות בין חלקי המערכת, קסטומיזציות בהתאם לצרכים הספציפיים של המשתמשים, ריפורטיזציות (יש דבר כזה?) ועוד.
*** 7 *** יכולת מעקב נוחה אחר שינויים
המערכת אוספת את כל הנתונים הנוגעים לשינויים. מערכת טובה תדע לספק יכולת מעקב נוחה בצורה של דו”חות ותרשימים – מי נגע, במה נגע, מתי ולמה, התפצלויות של קבצים, התפצלויות של ענפי פיתוח, תיעוד המשימות וכו’.
אנקדוטה קטנה: באחת החברות בהן עבדתי, יצא לי להציג יכולת זו עבור בודק של מכון התקנים שבה לתת הסמכת ISO לארגון, שרצה לראות את "יכולת הבקרה והמעקב של הארגון". הראיתי לו את יכולת המעקב והדיווח האוטומטית של המערכת – וזה השאיר אותו ללא מלים (ואת החברה עם הסמכת ISO, לראשונה בתולדותיה).
*** 8 *** התממשקות נוחה למערכת ההפעלה
לא משנה תחת איזו מערכת-הפעלה אתם עובדים (ובד"כ זו תהיה Unix לסוגיה השונים , MS-Windows או שילוב ביניהן), בסופו של דבר, מערכת ניהול התצורה תהווה תשתית שתאפשר גישה "שטוחה" למערכת הקבצים של מערכת ההפעלה (כלומר – אפשרות לבודד את בסיס הנתונים של המערכת כך שתלקח גירסא אחת מכל קובץ שבמערכת). תשתית זו צריכה להיות אמינה ונוחה, משום שהיא הבסיס לסביבות עבודה למשתמשים, לאינטגרציות לכלים אחרים, לבניות (builds) וכו'
*** 9 *** סביבת עבודה נוחה למשתמש הקצה
בין אם מדובר בסביבה שהיא בעיקרה שורת-פקודה, ובין אם מדובר בסביבה שהיא גרפית – חשוב ביותר שלמשתמשי הקצה יהיה נוח. שירגישו בבית!
איך עושים זאת?
על המערכת לספק להם ממשק נוח שבו רוב המשימות היומיומיות שלהם מרוכזות תחת IDE או Dashboard אחד
על המערכת לספק תפריט-הקשר (Context Menu) לפעולות נפוצות
במידה ומספקים גם ממשק שורת-פקודה וגם ממשק גרפי – כדאי מאוד ש-2 הממשקים יציעו את אותן האפשרויות בדיוק.
בכל אופן – ולא משנה באיזה ממשק מדובר – כדאי שיהיה תיעוד מפורט ונוח.
*** 10 *** יכולת חזרה לאחור (Rollback)
בין הנקודות שכתבתי לעיל, הזכרתי תהליך עבודה מסודר, ותיעוד של כל השינויים במערכת.
כפועל יוצא מכך, חשוב שהמערכת תוכל להציע אפשרות לחזור לאחור ולבטל שינוי של קובץ, משימה או אפילו גירסא רוחבית.
מדוע?
בסופו של דבר – למרות התהליך – ולמרות כל הבדיקות – טעויות תמיד עלולות להתחש – הרי כולנו בני-אדם: פונקציה בקובץ מסויים עובדת בסביבה פרטית אך לא עובדת בסביבה המרכזית; לסביבה המרכזית הוכנס שינוי שלא אמור היה להכנס עדיין וכיו"ב.
ישנן עוד נקודות שלא נכנסו ל- Top 10 , ועליהן אפרט בהזדמנות: אבטחת מידע של המערכת (כל עוד המערכת היא פנים-ארגונית זה בד"כ לא רלבנטי), תמיכה באינטגרציה מתמשכת ועוד.
תמיר גפן על ניהול תצורה ומחזור חיי תוכנה 