ארכיטקטורת אפליקציה ו-Devops הולכים ביחד כמו אפונים בתרמיל

רבים בתעשייה רגילים לחשוב על דילוור אפליקציה כעל צינור קידום (Promotion pipeline) מפיתוח ליצור. כל שלב בצינור הקידום הוא בדרך כלל סביבה נפרדת – לדוגמה, טופולוגיה שונה, תצורה שונה, כלים שונים ושיטות לקידום לשלב הבא.

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

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

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

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

תכנון לדילוור הוא חלק הכרחי של DevOps shift left paradigm. אלא ש-״Shift left" לבדו לא מספיק – כל ארגון צריך לקחת בחשבון את האפשרות לייצר בקלות את המוצר כחלק מהפקתו.

הדגמה מצוינת של מטאפורת ״ארגון כמכונה״ נמצאת בפוסט של ג׳ס המבל, Elisabeth Hendrickson Discusses Agile Testing, בו היא דנה בעבודתה בחברה שסבלה מאיכות מוצר ירודה. כתוצאה מכך, החברה שכרה סגן נשיא בקרת איכות. התוצאה של זה, המנוגדת לשכל הישר, הייתה דווקא הגדלת מספר הבאגים במוצר.

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

עקרונות בהשגת תכנון לדילוור

השגת תכנון לדילוור מותנית בהצמדה למספר עקרונות פשוטים:

העקרון הראשון הוא זיהוי בעיות דילוור, ארגון ופיתוח משוב מחזורי לצוותי תפעול ופיתוח. מומחי דילוור ותפעול צריכים להיות בעלי עניין מחויבים (Pigs) בכל ספרינט 0 (תכנון ספרינט) ובעלי עניין מעורבים (Chickens) בפגישות Scrum. לקבוצות פיתוח תוכנה זמיש יש מפתחים, לקוחות וצוות מנהלי מוצר, אבל חסר להם רכיב מרכזי – צוות דילוור, מה שמבטיח שמה שהקבוצה מפתחת לא יהיה אופטימלי לדילוור או, גרוע מכך, לא ניתן לדילוור.

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

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

העקרון השני הוא עיצוב לפי עשייה. פונקציונליות חדשה מוגדרת על ידי עסק בשילוב עם דרישות הדילוור שהוגדרו על ידי צוות התפעול – זה ה-״נושא״. לאחר מכן, הנושא מפורק לרכיבים מעשיים קטנים יותר (Epics and stories in agile). לדוגמה, זמן פריסה מהיר יותר, פריסה אוטומטית של רכיבים, הפעלה מחדש והתאוששות פשוטה יותר, קונסולת אירועים מובנית לשגיאות וללוגים, ושדרוג מובנה ואוטומטי של בסיס נתונים.

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

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

שלישי ואחרון בעקרונות הללו הוא Shift left – Think right: להבחין ולזהות אתגרי פריסה מוקדם יותר, כלומר – במהלך שלב הפיתוח, ולתקן מהר ככל האפשר, תוך לקיחה בחשבון של פריסה ותהליכים תפעוליים. זה כולל מעבדות פריסה ומקרי שימוש אמיתיים בפריסה. אלה עובדות עם כלי אוטומציית שחרור, שכוללים אוטומציה של תוכנה, בסיס נתונים ותצורה, כלי ניטור וכשירות מובנים, מבוססים על KPI בעל ערך לפריסה ולתפעול, קונסולת אירועים מובנית, בנייה יומית, פריסה וייצוב מובל על ידי פיתוח, סקירה וניהול, אימוץ ופישוט רשימות פריסה, ורשימות פריסה כתהליך.

הכותבים הם אנטולי שיין, ד"ר ג'ייקוב יוקלסון וד"ר אלכס קומן מ-Accera