ניהול פעולות פיתוח (DevOps) בארגון: קפיצת מדרגה לתהליך שחרור יישומים ממוחשב

מאת: אביב וייס, מהנדס מערכות ומומחה SDDC בחברת VMware

19.5.15, 17:30

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

קיימים כמה הגורמים למצב זה:

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

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

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

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

קבצים וחלקי קוד שונים בסביבות פיתוח, היערכות (Staging) וייצור: האם אי פעם שמעתם מפתח מתלונן ש"זה עבד מצוין בסביבה שלי אך אני לא מבין למה זה לא עובד בסביבת הייצור"? כאשר מעבירים קוד ברחבי הארגון קשה לעקוב אחר מבנה הקבצים וחלקי הקוד הדרושים להרצת היישום. דבר זה יכול לפגוע בשלמות וביציבות היישום ועלול להוביל לשעות של חיפושים אחרי קובץ או חלק קוד אבוד.

כדי להשיג יותר יעילות ושליטה על תהליך שחרור גרסאות תכנה נדרש שינוי מהותי בגישה:

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

למערכת זו צריכה להיות היכולת להתחבר ישירות, או דרך ממשקי תכנה (API) למערכות בקרת קוד המקור (Source Control), מערכות ניהול חלקי הקוד והקבצים המרכיבים את האפליקציה (Artifact Management), או בפלטפורמת פיתוח התכנה והתשתית המשמשת את כל חלקי התהליך (פיתוח, QA, ייצור).

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

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

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

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

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

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

מאת: אביב וייס, מהנדס מערכות ומומחה SDDC בחברת VMware, מאי 2015.