כיצד לבנות פיתוח פנימי מלא באמצעות DevOps - חוויית VTB

שיטות העבודה של DevOps עובדות. השתכנענו בכך בעצמנו כאשר צמצמנו את זמן התקנת השחרור פי 10. במערכת FIS Profile, שבה אנו משתמשים ב-VTB, ההתקנה נמשכת כעת 90 דקות במקום 10. זמן הבנייה של השחרור ירד משבועיים ליומיים. מספר פגמי היישום המתמשכים ירד כמעט למינימום. כדי להתרחק מ"עבודת כפיים" ולבטל את התלות בספק, היינו צריכים לעבוד עם קביים ולמצוא פתרונות בלתי צפויים. מתחת לגזרה יש סיפור מפורט על איך בנינו פיתוח פנימי מלא.

 

פרולוג: DevOps היא פילוסופיה

במהלך השנה האחרונה, עשינו עבודה רבה כדי לארגן את הפיתוח והיישום הפנימי של שיטות DevOps ב-VTB:

• בנינו תהליכי פיתוח פנימיים ל-12 מערכות;
• השקנו 15 צינורות, ארבעה מהם הובאו לייצור;
• תרחישי בדיקה אוטומטיים של 1445;
• הטמענו בהצלחה מספר מהדורות שהוכנו על ידי צוותים פנימיים.

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

בהתחלה, אלגוריתם היישום נראה פשוט וברור:

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

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

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

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

היכן מתחיל הפיתוח הפנימי? 

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

• שפה אקזוטית (MUMPS);
• ממשק מסוף;
• חוסר אינטגרציה עם כלי אוטומציה פופולריים ומסגרות;
• נפח נתונים בעשרות טרה-בייט;
• עומס של למעלה מ-2 מיליון פעולות בשעה;
• משמעות - עסקית-קריטית.

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

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

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

העברת מאגר ובדיקות אוטומטיות

המשימה הראשונה של DevOps היא המאגר. הסכמנו במהירות על מתן גישה, אבל היה צורך לעבור מה-SVN הנוכחי עם סניף מטען אחד אל Git היעד שלנו עם המעבר למודל של מספר סניפים ופיתוח של Git Flow. יש לנו גם 2 צוותים עם תשתית משלהם, בתוספת חלק מצוות הספק בחו"ל. הייתי צריך לחיות עם שני Gits ולהבטיח סנכרון. במצב כזה, זה היה הפחות משתי רעות.

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

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

איך זה היה: המודל לפני האוטומציה

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

ההרכבה בוצעה ברמת משלוחים בודדים, שהיו חפצים עצמאיים. כל שינוי הוא משלוח חדש. בין היתר, נוספו 60–70 גרסאות טכניות ל-10-15 חבילות של הרכב המהדורה הראשי - גרסאות שהושגו בעת הוספה או אי הכללה של משהו מההוצאה ומשקפות שינויים במכירות מחוץ למהדורות.

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

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

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

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

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

עדכונים ראשונים: התחייבות להרכבה ואספקה

אוטומציה החלה בהעברת קוד דרך צינור לאורך המסלול הזה:

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

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

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

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

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

הפתרון הסופי: חבילות התקנה מצטברות 

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

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

כשנותר קצת יותר מחודש, האספקה ​​שנבחרה ביד רמזה בבירור שהזמן אוזל. הם החליטו לעשות את הבנייה מסניף השחרור, אבל למה צריך להפריד אותו? אין לנו Prod-like, וסניפים קיימים אינם טובים - יש הרבה קוד מיותר. אנחנו צריכים בדחיפות לקצץ בלייקים של פרוד, וזה יותר משלושת אלפים מחויבות. הרכבה ידנית היא לא אופציה בכלל. שרטטנו סקריפט שעובר ביומן התקנת המוצר ואוסף התחייבויות לסניף. בפעם השלישית זה עבד כמו שצריך, ואחרי "סיום עם קובץ" הסניף היה מוכן. 

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

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

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

פעם ראשונה, במהירות וללא שגיאות

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

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

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

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

סיכום ומסקנות

תוך פחות משנה הצלחנו:

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

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

מקור: www.habr.com