מתודולוגיית פריסת פרויקטים בשימוש ב-Slack

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

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

כיצד פועלים תהליכי פריסת פרויקטים כיום

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

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

ממשק של מערכת Checkpoint, המשמשת ב-Slack לפריסת פרויקטים

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

▍1. יצירת סניף שחרור

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

▍2. פריסה בסביבת סטייינג

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

▍3. פריסה בסביבות דוג פוד וסביבות קנריות

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

▍4. שחרור הדרגתי להפקה

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

▍מה אם משהו משתבש במהלך הפריסה?

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

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

אבני בניין של מערכת פריסה

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

▍ פריסות מהירות

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

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

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

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

1. שרתי ייצור עוקבים אחר מפתח הקונסול. 2. המפתח משתנה, זה אומר לשרתים שהם צריכים להתחיל להוריד קוד חדש. 3. שרתים מורידים קבצי Tarball עם קוד אפליקציה

▍ פריסות אטומיות

פתרון נוסף שעזר לנו להגיע למערכת פריסה מרובת שכבות היה פריסה אטומית.

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

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

1. הוצאת קוד היישום לספרייה "קרה". 2. העברת המערכת לספרייה "קרה", שהופכת ל"חמה" (פעולה אטומית)

תוצאות: שינוי בדגש לאמינות

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

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

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

קוראים יקרים! איך עובד תהליך הפריסה של מהדורות חדשות של פרויקטים במקום שבו אתה עובד?

מקור: www.habr.com