5 סיבות שיסבירו למה גם אתם צריכים לפרוס קוד בלי שאף אחד מסתכל

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

 Paul Pirosca / EyeEm/ Getty Images Israel

צלם/תמונה: Paul Pirosca / EyeEm/ Getty Images Israel

מאת יוסי שמואלי, ארכיטקט תוכנה בסירס

Continuous Deployment הוא מונח נפוץ בשנים האחרונות. משהו שכל חברה וסטארטאפ רוצים להגיע אליו. אבל מה זה בדיוק אומר ומה ההבדל בין Contionus Delivery? האם הכוונה היא לפרוס 10 פעמים ביום, או שניתן לפרוס גם פעם בשבוע? האם זה אומר שאין גרסאות כי פורסים בכל commit, או שדווקא יש מקום לגרסאות אך הן יכולות להיות קטנות יותר ותכופות יותר?

בואו ננסה להגדיר מחדש את אלה מנקודת מבט אחרת – נקודת המבט המוצרית:

  1. Continuous Delivery היא היכולת לספק פיצ׳ר חדש לפרודקשן בכל עת שנרצה.
  2. Continuous Deployment היא היכולת לפרוס את הקוד הנוכחי שלנו ללא כל התערבות ידנית.

לכאורה, נראה ששתי ההגדרות הללו לא בהכרח קשורות זו לזו, אך כשחושבים על זה בשנית מגלים ש-Continuous Delivery מגדירה את הדרישה, בעוד Continuous Deployment מגדירה את המימוש.

Delivery הוא מושג יותר אבסטרקטי וניתן לממשו גם בדרכים אחרות, כמו Releasable master. בשיטה זו ה-master branch תמיד מוכן לפריסה בסביבת הייצור, אך תהליך הפריסה עצמו מבוצע ידנית, עם מישהו ש”משגיח” על התהליך מתחילתו ועד סופו. לכאורה ניתן להגיע לדרישה של פריסה בכל זמן נתון גם מבלי להבטיח שהתהליך יהיה אוטומטי לחלוטין. ובכל זאת, מה נרוויח אם נחליט לממש Continuous Deployment?

1. שיפור תהליך הפריסה

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

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

2. שיפור איכות הקוד

בדיוק כפי ש-build אוטומטי מוביל לפחות שגיאות לחלחל לסביבות העבודה של מפתחים אחרים (כי מי שישבור את הbuild- יחטוף revert), ובדיוק כמו ש-Continuous Integration מוביל אותנו לתקן בעיות אינטגרציה מוקדם יותר בתהליך הפיתוח, כך Continuous Deployment מכריח אותנו להתמודד עם בעיות של Backwards Compatibility ברזולוציה של פיצ׳ר ולא ברזולוציה של גרסה.

תהליך זה מאלץ אותנו לייצר קוד יותר עמיד, למשל באמצעות שימוש ב-Feature Switches ,פריסות שקטות, ו-Gradual Rollout – וכך אנחנו מייצרים כלים ותהליכים שהופכים את המערכת שלנו לעמידה יותר בפני כישלונות ול-Design יותר חסין.

3. שיפור איכות הבדיקות

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

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

אירוע גיקטיים 2018

4. תחושת אחריות

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

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

5. מהירות

בואו נניח שיש ברשותכם 200 בודקים ו-1,000 תסריטי בדיקה. כמה זמן ייקח לכם לבדוק גרסה? מה אם היו לכם 10 שרתים שבכל פריסה צריך להסיר מה-Load Balancer, לעצור, להתקין, להפעיל מחדש ולהחזיר ל-Load Balancer? כמה זמן זה ייקח? ומה בנוגע ל-20 שרתים? או 200?

מפתחים רוצים לעשות אוטומציה כי… ובכן, כי אנחנו חבורה של בטלנים. “פעם אחת עשה זאת ידנית, פעם שנייה כתוב סקריפט, פעם שלישית תשתית”. אנו רוצים לבצע את העבודה שלנו, שהיא לפתח פיצ׳רים חדשים – וכל דבר אחר הוא בזבוז זמן. זו בדיוק הסיבה שבגינה אנחנו כל כך אוהבים Continuous Integration – זה חוסך לנו את הבזבוז שבאינטגרציה.

בעוד ש-Continuous Delivery נותן למוצר שלנו כוח, Continuous Deployment עוזר לנו להסיר Waste מתהליכי הפריסה שלנו, ומאפשר לנו להגיע מ-commit לפרודקשן באופן אוטומטי, מה שמשאיר לנו הרבה יותר זמן לקודד.

אחרי שהבנו מה אנחנו מרוויחים נותרו שתי שאלות: כיצד מגיעים למצב של Continuous Deployment ומה בדיוק צריך לעשות כדי שנוכל לפרוס את המערכת שלנו כל commit? על זה תוכלו לשמוע בהרצאה שלנו  – Breaking B arriers: How to Deploy 20 Times a Day, שתתקיים מחר בכנס Geektime Code בגני התערוכה.

כתב אורח

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

הגב

5 תגובות על "5 סיבות שיסבירו למה גם אתם צריכים לפרוס קוד בלי שאף אחד מסתכל"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
אביב
Guest

התכוונתם ל”לפרוש” כמו לפרוש מפה, ולא “לפרוס” כמו לפרוס לחם…

מרדכי
Guest

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

Mohamed
Guest

It’s a great article

לירן
Guest

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

dev
Guest

use octane

wpDiscuz

תגיות לכתבה: