מסקריפטים לפלטפורמה שלנו: איך ביצענו פיתוח אוטומטי ב-CIAN

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

רמת אפס

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

אוטומציה ב-CIAN החלה 14 שנים לאחר הקמת החברה. באותה תקופה היו 35 אנשים בצוות הפיתוח. קשה להאמין, נכון? כמובן, אוטומציה אכן הייתה קיימת בצורה כלשהי, אבל כיוון נפרד לאינטגרציה מתמשכת ומסירת קוד החל להתגבש ב-2015. 

באותה תקופה, היה לנו מונוליט ענק של Python, C# ו-PHP, שנפרסו על שרתי Linux/Windows. כדי לפרוס את המפלצת הזו, היה לנו סט של סקריפטים שהרצנו ידנית. הייתה גם הרכבה של המונוליט, שהביאה כאב וסבל עקב קונפליקטים בעת מיזוג ענפים, תיקון פגמים ובנייה מחדש "עם מערך אחר של משימות במבנה". תהליך פשוט נראה כך:

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

אנחנו מגיעים לרעיון של מערכת משלנו

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

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

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

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

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

אנחנו עושים בדיקות אוטומטיות

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

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

צוות אוטומציה

יש לנו כיום צוות של 130 מפתחים, ואנחנו ממשיכים לצמוח. הצוות לאינטגרציה מתמשכת ואספקת קוד (להלן צוות Deploy and Integration או DI) מורכב מ-7 אנשים ופועל ב-2 כיוונים: פיתוח פלטפורמת האוטומציה Integro ו-DevOps. 

DevOps אחראית על סביבת Dev/Beta של אתר CIAN, סביבת Integro, עוזרת למפתחים לפתור בעיות ומפתחת גישות חדשות לשינוי קנה מידה של סביבות. כיוון הפיתוח של Integro עוסק הן ב-Integro עצמה והן בשירותים נלווים, למשל, תוספים עבור Jenkins, Jira, Confluence, וכן מפתחת כלי עזר ואפליקציות עזר עבור צוותי פיתוח. 

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

עוגת שכבות של אוטומציה ב-CIAN

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

1. מערכות חיצוניות (Jira, Bitbucket וכו'). צוותי פיתוח עובדים איתם.
2. פלטפורמת אינגרו. לרוב, מפתחים לא עובדים עם זה ישירות, אבל זה מה שגורם לכל אוטומציה לפעול.
3. שירותי משלוח, תזמור וגילוי (לדוגמה, Jeknins, Consul, Nomad). בעזרתם, אנו פורסים קוד בשרתים ומבטיחים שהשירותים עובדים זה עם זה.
4. שכבה פיזית (שרתים, מערכת הפעלה, תוכנה קשורה). הקוד שלנו פועל ברמה זו. זה יכול להיות שרת פיזי או וירטואלי (LXC, KVM, Docker).

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

מלא

בואו נתמקד באינטגרו ונתחיל עם ערימת הטכנולוגיה:

• CentOS 7
• דוקר + נווד + קונסול + כספת
• Java 11 (המונוליט הישן של Integro יישאר ב-Java 8)
• Spring Boot 2.X + Spring Cloud Config
• PostgreSql 11
• RabbitMQ 
• Apache Ignite
• קמונדה (מוטבע)
• גרפאנה + גרפיט + פרומתאוס + יגר + ELK
• ממשק משתמש אינטרנט: React (CSR) + MobX
• SSO: גלימת מפתח

אנו מקפידים על העיקרון של פיתוח מיקרו שירותים, למרות שיש לנו מורשת בצורה של מונוליט של גרסה מוקדמת של Integro. כל שירות מיקרו פועל בקונטיינר Docker משלו, והשירותים מתקשרים זה עם זה באמצעות בקשות HTTP והודעות RabbitMQ. שירותי מיקרו מוצאים זה את זה דרך Consul ומגישים אליו בקשה, ומעבירים הרשאה דרך SSO (Keycloak, OAuth 2/OpenID Connect).

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

1. המיקרו-שירות לניהול זרימת עבודה (להלן המיקרו-שירות Flow) רוצה להריץ מבנה בג'נקינס. לשם כך, הוא משתמש ב-Consul כדי למצוא את ה-IP:PORT של המיקרו-שירות לאינטגרציה עם Jenkins (להלן Jenkins microservice) ושולח אליו בקשה אסינכרונית להתחיל את הבנייה בג'נקינס.
2. לאחר קבלת בקשה, שירות המיקרו של Jenkins יוצר ומגיב עם מזהה עבודה, אשר לאחר מכן ניתן להשתמש בו כדי לזהות את תוצאת העבודה. במקביל, הוא מפעיל את הבנייה בג'נקינס באמצעות קריאת REST API.
3. ג'נקינס מבצע את הבנייה ולאחר השלמתו, שולח webhook עם תוצאות הביצוע לשירות המיקרו של Jenkins.
4. המיקרו-שירות של Jenkins, לאחר שקיבל את ה-webhook, מייצר הודעה על השלמת עיבוד הבקשות ומצרף אליו את תוצאות הביצוע. ההודעה שנוצרת נשלחת לתור RabbitMQ.
5. באמצעות RabbitMQ, ההודעה שפורסמה מגיעה למיקרו-שירות Flow, אשר לומד על התוצאה של עיבוד המשימה שלו על ידי התאמת מזהה העבודה מהבקשה וההודעה שהתקבלה.

כעת יש לנו כ-30 מיקרו-שירותים, אותם ניתן לחלק למספר קבוצות:

1. ניהול תצורה.
2. מידע ואינטראקציה עם משתמשים (שליחים, דואר).
3. עבודה עם קוד מקור.
4. אינטגרציה עם כלי פריסה (ג'נקינס, נווד, קונסול וכו').
5. ניטור (שחרורים, שגיאות וכו').
6. כלי עזר באינטרנט (UI לניהול סביבות בדיקה, איסוף סטטיסטיקות וכו').
7. אינטגרציה עם מעקבי משימות ומערכות דומות.
8. ניהול זרימת עבודה למשימות שונות.

משימות זרימת עבודה

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

בואו נסתכל על זרימת העבודה שבה אנו משתמשים לרוב:

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

בדיקה ידנית לחלוטין ב-DEV+BETA ללא בדיקות קנריות (בדרך כלל כך אנו משחררים מונוליט):

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

תנועת משימה

בואו נסתכל על השלבים העיקריים שמתבצעים כאשר משימה עוברת דרך זרימת העבודה "בדיקות DEV + בדיקות קנריות":

1. המפתח או ראש הממשלה יוצר את המשימה.

2. היזם לוקח את המשימה לעבודה. לאחר השלמתו, הוא עובר למצב IN REVIEW.

3. Jira שולחת Webhook לשירות המיקרו של Jira (אחראי על האינטגרציה עם Jira).

4. המיקרו-שירות של Jira שולח בקשה לשירות Flow (האחראי על זרימות עבודה פנימיות בהן מתבצעת עבודה) להפעיל את זרימת העבודה.

5. בתוך שירות הזרימה:

• סוקרים מוקצים למשימה (Users microservice שיודע הכל על משתמשים + Jira microservice).
• דרך המיקרו-שירות Source (הוא יודע על מאגרים וסניפים, אבל לא עובד עם הקוד עצמו), מבצעים חיפוש מאגרים שמכילים סניף מהנושא שלנו (כדי לפשט את החיפוש, שם הסניף עולה בקנה אחד עם הנושא מספר בג'ירה). לרוב, למשימה יש רק ענף אחד במאגר אחד; זה מפשט את הניהול של תור הפריסה ומפחית את הקישוריות בין מאגרים.
• עבור כל ענף שנמצא, מתבצע רצף הפעולות הבא:

  i) עדכון ענף המאסטר (Git microservice לעבודה עם קוד).
  ii) הסניף חסום משינויים על ידי המפתח (Bitbucket microservice).
  iii) נוצרת בקשת Pull Request עבור סניף זה (Bitbucket microservice).
  iv) הודעה על בקשת משיכה חדשה נשלחת לצ'אטים למפתחים (הודע למיקרו-שירות עבור עבודה עם התראות).
  v) משימות בנייה, בדיקה ופריסה מתחילות ב-DEV (שירות מיקרו של Jenkins לעבודה עם Jenkins).
  vi) אם כל השלבים הקודמים הושלמו בהצלחה, אזי אינגרו מכניסה את האישור שלה ל-Pull Request (Microservice Bitbucket).

• Integro ממתין לאישור ב-Pull Request מסוקרים ייעודיים.
• ברגע שהתקבלו כל האישורים הדרושים (כולל בדיקות אוטומטיות עברו בצורה חיובית), Integro מעבירה את המשימה למצב Test on Dev (Jira microservice).

6. בודקים בודקים את המשימה. אם אין בעיות, המשימה מועברת למצב Ready For Build.

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

8. המשימה מועברת למצב קנרי (Jira microservice).

9. Jenkins משיק משימת פריסה דרך Nomad במצב קנרי (בדרך כלל 1-3 מקרים) ומודיע לשירות ניטור השחרור (DeployWatch microservice) על הפריסה.

10. המיקרו-service DeployWatch אוסף את רקע השגיאה ומגיב אליו, במידת הצורך. אם חריגה מרקע השגיאה (נורמת הרקע מחושבת באופן אוטומטי), מפתחים מקבלים הודעה באמצעות המיקרו-שירות Notify. אם לאחר 5 דקות המפתח לא הגיב (לחץ על Revert או Stay), אזי מופעלת החזרה אוטומטית של המופעים הקנריים. אם אין חריגה מהרקע, על המפתח להפעיל ידנית את פריסת המשימות ל-Production (על ידי לחיצה על כפתור בממשק המשתמש). אם תוך 60 דקות המפתח לא השיק את הפריסה ל-Production, אז גם המופעים הקנריים יוחזרו לאחור מסיבות אבטחה.

11. לאחר השקת הפריסה להפקה:

• המשימה מועברת למצב ייצור (Jira microservice).
• המיקרו-שירות של Jenkins מתחיל את תהליך הפריסה ומודיע למיקרו-שירות DeployWatch על הפריסה.
• המיקרו-service DeployWatch בודק שכל הקונטיינרים ב-Production עודכנו (היו מקרים שבהם לא כולם עודכנו).
• באמצעות המיקרו-שירות Notify, נשלחת הודעה על תוצאות הפריסה ל-Production.

12. למפתחים יהיו 30 דקות להתחיל להחזיר משימה מהפקה לאחור אם תתגלה התנהגות שגויה של מיקרו-שירות. לאחר זמן זה, המשימה תתמזג אוטומטית למאסטר (Git microservice).

13. לאחר מיזוג מוצלח למאסטר, סטטוס המשימה ישתנה לסגורה (Jira microservice).

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

מה הלאה

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

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

מקור: www.habr.com