ראשית, הקדימון (הקבוע של סדרת מאמרים זו) – המטרה של פוסט זה אינה להחליף את ויקיפדיה, או לחלופין להוציא אתכם
מומחים בתהליכיOperations
בסיום קריאת הפוסט. המטרה הינה לתאר את הקווים המנחים, להסביר את
העקרונות, ולאפשר להבין על מה כל המהומה.
מהו פרק הזמן הלוקח לכם להעלות שינוי בשורת קוד אחת לסביבת הייצור?
מהי כמות ההשקעה הנדרשת?
עבור ארגונים רבים התשובה לשאלות אלו רחוקה מלהיות משביעת רצון. גם אם
הארגון התקדם בתהליך הפיתוח, אימץ שיטות אג'יליות, ומסוגל להגיב
ב"גמישות" רבה יותר לדרישות השוק, עדיין במרבית המקרים – הזמן וההשקעה
אשר יידרשו לו להעלות את התוצר לייצור (production), הינם גבוהות מאד ויכולות
להגיע
עד ל 30% מסך ההשקעה בתהליך הפיתוח כולו.
כיצד ניתן להפוך תהליך זה לאפקטיבי?
בתעשיית פיתוח התוכנה הוגדרו 4 שלבים עיקריים ליישום תהליך מסוג זה –
Continuous Improvement
השלב הראשון בתהליך (והחשוב ביותר לדעתי) מתייחס לשאיפה של ארגון לשפור
מתמיד באיכות התוצר שלו. זה יכול להתחיל בתהליך פיתוח "מונחה
איכות", במימוש eXtreme Programming, בהגדרת Definition Of Done, או במימוש Unit Testing. בשורה תחתונה שאיפה לאיכות תוצר גבוהה ולשיפור מתמיד חייבים
להיות ב ד.נ.א של הארגון. שאיפה זו מהווה את ההבדל התמקדות הארגון בגרסת המוצר הבאה (עתיד), לעומת התמודדות עם בעיות העבר (כגון - "ייצוב
הגרסה", תיקון תקלות, תמיכה בלקוחות, וכיו"ב )
Continuous Integration
השלב השני בתהליך מתייחס לשלב האינטגרציה (שילוב הקוד בגרסת המוצר).
בארגונים רבים תהליך זה הינו ארוך ומייגע בעיקר בשל ההנחה השגויה שעל המפתח לעבוד
בסביבה "סגורה" שאינה מושפעת ממפתחים אחרים עד אשר יסיים את משימתו.
שיטה זו גורמת לשינויים רבים להיות משולבים לגרסה בשלב מאוחר מאד ולרוב "בבת
אחת". התוצאה הינה אי יציבות של הגרסה בשלב מאוחר שלה, שילובים (merges) כבדים, מסובכים ויקרים מאד מבחינת זמן השקעה. הדרך הגיע להישגים בסוגיה
זו עוברת דרך שילובים "תכופים" ככל שניתן (אפילו ברמה יומית) של הקוד
לגרסה המרכזית, קבלת "פידבק מהיר" על כל שילוב דרך כלי בנייה אוטומטיים,
ויכולת אספקת תוצר בנייה יציב ועדכני ביותר של הגרסה בכל רגע נתון.
Continuous Delivery
השלב השלישי בתהליך מתייחס ליכולת "לספק" Delivery של מוצר (להבדיל מתוצר בנייה בשלב ה CI) בכל רגע נתון.
שלב זה כולל בתוכו שתי מטרות עיקריות –
1. היכולת "לדמות" (simulate) את התהליך של התקנת מוצר
מלאה מתוצר הבנייה (build) האחרון
2. היכולת לבצע בדיקות אוטומטיות על המוצר על מנת לוודא את תקינותו
ויציבותו לפני עלייה לאוויר.
תכולות אלו מסופקות ברובן ע"י שימוש בכלים אוטומטיים אשר רצים על
סביבות הדומות לסביבת הייצור (production like). שלב זה יכלול במרבית
המקרים גם בדיקות ידניות על מנת לוודא בצורה רחבה יותר את איכות התוצר.
חשוב לציין שאין הכוונה לכך שכל שינוי בשורת קוד חייב לעלות לסביבת production בזמן המהיר ביותר. אלא שבכל רגע נתון – ניתן
לעלות לייצור.
Continuous Deployment
השלב הרביעי בתהליך שייך למוצרים אשר יכולים להתעדכן בצורה אוטומטית
(כגון מוצרים מבוססי "ענן"). בשלב זה תוצר אשר עבר את הבדיקות
האוטומטיות, מועלה בצורה אוטומטית לסביבת הייצור. זוהי למעשה התחנה האחרונה
בתהליך אשר החל בהכנסת קוד של פיתוח, עבר בהצלחה דרך אינטגרציה אוטומטית, נבדק
ברמת הסביבה, ועתה יכול להיות "שמיש" עבור לקוחות החברה.
חשוב להדגיש -
1. הקשר בין החוליות הינו קשר 'חזק'. דהיינו – לא ניתן להתקדם לחוליה
הבאה כאשר החוליה הקודמת אינה יציבה מספיק.
2. התהליך לעיל מוצג כמתודולוגיה, ויש לבצע את ההתאמה הנדרשת (כגון כלים, UT, XP וכו' )ברמת הארגון במידה ורוצים
לאמצה.
3. הזמן ה"נכון" ביותר להתחיל עם הטמעת מתודולוגיה מסוג זה
הוא למעשה – אתמול! ככל שעובר הזמן, נכנסות יותר שורות קוד, ישנם יותר מקורות לקוד,
לחץ השוק להגדלת ההספק עולה, וכיו"ב
שורת סיכום
באופן כללי,
התפיסה האומרת שיש להסתכל על אפקטיביות מכלול תהליך הייצור ולא להתמקד בשלב הפיתוח
בלבד אינה חדשה. זיהה אותה Taiichi Ohno מחברת טויוטה כבר בשנות ה 40
ועל בסיסה פותחה מתודולוגיית ה Kanban. (ראו ערך "Kanban – על מה כל
המהומה" בבלוג
זה)
אז מה חדש כאן
? החידוש הוא בהבנה שהצרכים שזוהו בתעשיית הרכב והמפעלים, מתאימים בעצם גם לעולם פיתוח
התוכנה. בשימוש נכון בכלים אשר קיימים כבר בשוק ניתן לבצע את ההתאמות הנדרשות בכדי
להנות מפרות אלו.
בהצלחה !
יוגב טל, PMP
בחזרה לעמוד הבית - מרעננים
את הפיתוח
אין תגובות:
הוסף רשומת תגובה