כיצד אנו משחררים תיקוני תוכנה ב-GitLab

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

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

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

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

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

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

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

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

מה עושה מנהל שחרור?

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

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

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

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

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

הכל עניין של התיקונים

מה זה תיקונים ולמה אנחנו צריכים אותם?

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

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

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

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

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

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

כיצד מנהל מהדורות יוצר תיקונים

אנו משתמשים ב- GitLab CI ובתכונות אחרות כמו ChatOps שלנו כדי ליצור תיקונים. מנהל השחרור מתחיל את שחרור התיקון על ידי הפעלת צוות ChatOps בערוץ הפנימי שלנו #releases ב-Slack.

/chatops run release prepare 12.10.1

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

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

הסרטון למטה מציג את התהליך הטכני של הכנת תיקון עבור GitLab.

כיצד פועלת הפריסה האוטומטית ב-gitlab.com

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

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

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

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

מרין מפרטת על תהליך עדכון gitlab.com בסרטון למטה.

מה עוד עושה צוות המשלוחים?

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

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

אחת המטרות לטווח הקצר של צוות המסירה היא להפחית את כמות העבודה הידנית מצד מנהל השחרור כדי לזרז את השחרור. הצוות עובד כדי לפשט, לייעל ולהפוך את תהליך השחרור לאוטומטי, מה שיעזור לקבל תיקונים לבעיות בדרגת חומרה נמוכה (S3 ו-S4, משוער. מְתוּרגְמָן). התמקדות במהירות היא אינדיקטור ביצועים מרכזי: יש צורך להפחית את ה-MTTP - הזמן מרגע קבלת בקשת המיזוג ועד לפריסת התוצאה ל-gitlab.com - מ-50 השעות הנוכחיות ל-8 שעות.

צוות המסירה עובד גם על העברת gitlab.com לתשתית מבוססת Kubernetes.

מס' העורך: אם כבר שמעתם על טכנולוגיית Kubernetes (ואין לי ספק שכן), אבל עדיין לא נגעתם ​​בה בידיים, אני ממליץ לקחת חלק בקורסים אינטנסיביים מקוונים בסיס Kubernetes, שיתקיים 28-30 בספטמבר, ו Kubernetes Mega, שיתקיים ב-14-16 באוקטובר. זה יאפשר לך לנווט בביטחון ולעבוד עם הטכנולוגיה.

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

יש רעיונות או המלצות עבורנו?

כולם מוזמנים לתרום ל-GitLab, ואנו מברכים על משוב מהקוראים שלנו. אם יש לך רעיונות לצוות המשלוחים שלנו, אל תהסס ליצור יישום עם התראה team: Delivery.

מקור: www.habr.com