Continuous Delivery and Progressive Delivery with GitLab
אני שמח לשתף במפגש מוקלט שבו אירחתי את אורית גולובינסקי, מנהלת מוצר בכירה בחברת GitLab – שאחראית על היבטי ה- CI/CD ובפרט על ה- Release ו- Progressive Delivery .
בוידאו אורית הציגה הסברים על שיטות ומתודולוגיה, והדגימה איך ניתן לממש זאת באמצעות GitLab CI/CD .
לנוחיותכם הוספנו גם את התמליל כאן בהמשך.
תקציר:
- 0 – פתיחה והיכרות
- 1:40 – Continuous Delivery
- 4:13 – Progressive Delivery
- 05:15 – Review Apps
- 8:30 – על בדיקות ב- production
- 11:25 – Blue/Green Deployment
- 12:54 – Canary Release
- 16:20 – Feature Flags
- 21:24 – Feature Flags VS Canary
- 27:23 – A/B Testing
- 30:00 – Progressive Delivery – יתרונות וחסרונות
- 33:13 – סיכום
שאלות ותשובות הקשורות לנושא
- שאלה: האם בכדי להשתמש ב- GitLab CD צריך בהכרח להשתמש ב- GitLab כ – Version Control?
- שאלה: היכן ניתן לראות את רשימת היכולות המלאה של GitLab CI/CD ?
- תשובה: – ניתן להורידה כאן
- שאלה: מה העלויות של היכולות שהוצגו?
- תשובה: חלקן בגירסא החינמית וחלקן בגירסאות בתשלום. לקבלת עלות מדוייקת לסביבה שלכם ומחירים אפשר לפנות אלינו: gitlab@almtoolbox.com
- שאלה: האם קיים תיעוד טכני ליכולות שהוצגו?
- תשובה: כן – ניתן לקרוא כאן https://docs.gitlab.com/ee/operations/feature_flags.html
סרטונים עם הדגמות טכנית:
Demo – Features Flag
Demo – Incremental Rollout
חברת ALM-Toolbox היא המייצגת הרשמית של GitLab בישראל (ובמדינות נוספות),
ומספקת תמיכה, שירותים מנוהלים, הדרכות, יעוץ ורשיונות ל- GitLab ובמגוון כלי פיתוח ו- DevOps משלימים.
לפרטים נוספים פנו אלינו gitlab@almtoolbox.com או טלפונית 072-240-5222
קישורים רלוונטיים:
תמליל חלקי (Transcription)
שלום לכולם,
אני שמח להזמין את אורית גולובינסקי, מנהלת מוצר בכירה ב- GitLab , עובדת ישראלית של GitLab שאחראית על היבטי ה-CI/CD ובפרט על ה-Release ועל ה-progressive delivery. במפגש כעת אורית תדבר על progressive delivery שזו התפתחות די חדשה של Continuous delivery.
אם אתם לא מכירים את הניואנסים אל דאגה, הכל יוסבר, ולאחר מכן בסוף נציג דמו טכני של שני פיצ'רים שאורית מזכירה, דמו שהכין איציק גן-ברוך, גם הוא עובד ישראלי של חברת GitLab .
אז שלום אורית, ואני מעביר לך את המסך:
תודה תמיר ושלום לכולם, אז היום אנחנו נדבר על progressive delivery. אפשר לחשוב על progressive delivery כמבצע ניסויים או אפילו בדיקות ב-production כאשר אנחנו מנסים למזער את הסיכון.
אז אנחנו נתחיל.
קצת על עצמי:
אני אורית גולובינסקי, ואני מנהלת מוצר ב- GitLab, אחראית על progressive delivery. יש לי תואר בהנדסת מחשבים, ואני עכשיו מסיימת את התואר השני במנהל עסקים בדגש על מערכות מידע. אני עם מעל 15 שנה ניסיון בהייטק בכל מיני תפקידים, ביניהם גם ניהלתי תשתיות של פיתוח כולל גם את הקבוצת DevOps וניהלתי קבוצות QA בנוסף לניהול מוצר כמובן.
יש לי שלוש בנות, וקצת באופן אישי אני למדתי קונדיטוריה, אבל מעולם לא עסקתי בזה.
לפני שאנחנו נתחיל לדבר על progressive delivery, אני רוצה קצת לחזור על מה זה Continuous delivery.
אז Continuous delivery זה מתודה שאנחנו עושים בזמן פיתוח, שהוא נותן לנו לבנות את התוכנה שלנו בצורה כזו שאפשר לשפר אותה ל-production בכל רגע נתון. הדרך שאנחנו מגיעים ל- Continuous Delivery היא אחרי שעשינו CI ובעצם בנינו artifacts ו- executables של התוכנה, כשבכל שלב שמנו נקודות שאפשר למצוא בהן בעיות, ובצורה אוטומטית
את ה- Executables ואת התוצרים של התוכנה אנחנו דוחפים לסביבות שהן כמו production, כדי שביום שנגיע ל- production אז הכל יעבוד כמו שצריך.
בשקף אפשר לראות שב- CD אנחנו מדברים על Review, Staging ו- Production .
שאלה: תוכלי לחדד את ההבדלים בין Continuous Delivery ל- Continuous Deployment ?
כן – ב- Continuous Deployment משחררים תמיד ל- production
לעומת זאת ב- Continuous Delivery מדברים על כך שפוטנציאלית אפשר לשחרר כל build ל- production – אבל לאו דווקא. יכול להיות שזה בצורה ידנית וזה יכול להיות בצורה אוטומטית – אבל לאו דווקא נרצה להעביר כל build ל- production. יתכן שנרצה להוסיף עוד בדיקות או עוד gates. יכול להיות שנרצה להעלות build פעם ביום או פעם בשבוע ולאו דווקא כל build .
לסיכום: ב- deployment תמיד מ- CI אני אגיע ל- production, וב- delivery יש לי נקודת החלטה האם אני רוצה להעביר ל- production או לא.
Progressive Delivery
זהו מושג יחסית חדש.
אנליסט בשם James Governor מ- RedMonk טבע את הביטוי, והגדיר זאת כך:
"Progressive delivery is continuous delivery with fine-grained control over the blast radios"
הרעיון הוא שאנחנו רוצים למזער את ה- impact של מה שאנחנו משחררים. אז במקום לדבר על רדיוס הפיצוץ, נדבר במושגים קצת פחות אלימים – אנחנו הולכים לשחרר את זה לקבוצה קטנה יותר של משתמשים. והדרך שעושים זאת היא ע"י כל מיני ניסויים שונים כיצד משחררים באיטיות אל ה- production.
Feature Flags
עכשיו נדבר על Feature Flags .
זהו קונספט מאוד מעניין. הוא משמש אותנו כחלק מתהליך הפיתוח. הוא מאפשר לנו בעצם לבדוק את הפיצ'ר אפילו לפני שהוא מוכן לשחרור.
ב- Feature Flags אנחנו משתמשים ב- switch – מעין מתג של ON/OFF שמאפשר או לא מאפשר את הפיצ'ר בזמן ריצה . היופי הוא שאפילו אם לא סיימתי לפתח את הפיצ'ר – הוא פשוט לא יופיע ב- user interface. אם נחשוב על פיתוח שאני רוצה לפתח משהו ואני רוצה לשחרר בתאריך X אבל עוד לא סיימתי לפתח את הפיצ'ר הזה, וה- QA כבר בדק את הפיצ'ר הזה אבל הוא עדיין לא מוכן לשחרור – אפשר לסמן אותו כ OFF והוא עדיין לא יופיע ב- interface .
זה מאוד מאוד חזק.
זה מאפשר המון המון גירסאות קטנות בלי צורך לייצר כל הזמן עוד branches ו- merges ולהוריד את הפיצ'ר מהקוד
אנחנו הרבה פעמים יודעים שבאגים מופיעים לא רק כשמוסיפים קוד אלא כשמסירים קוד – וזה מוריד את הסיכון שבזה.
(הערה: כל הפיצ'רים של feature flags למעט אחד — קיימים כיום בגירסא החינמית [ת.ג.])
