מה זה Deployment (פריסה)

הגדרה

Deploy, או פריסה, הוא התקנה של גרסה בנויה של התוכנה בסביבה מסוימת: הקוד עובר ממאגר הקוד לשרת, בדרך כלל דרך צינור אוטומטי (pipeline). היעד יכול להיות Staging, שבו הצוות בודק את השינוי, או סביבת הייצור, שבה הלקוחות משתמשים בו. אינטגרציה רציפה (CI) בונה ובודקת כל שינוי אוטומטית, ומסירה רציפה (CD) שומרת כל גרסה מוכנה לעלות בכל רגע. דיפלוי הוא לא שחרור (release): הדיפלוי מעלה את הקוד לשרת, והשחרור פותח את הפיצ'ר למשתמשים, ולפעמים זה קורה אחר כך, למשל כשמדליקים לכולם פיצ'ר פלאג (feature flag). כל דיפלוי צריך חזרה לגרסה קודמת (rollback), דרך לשחזר את הגרסה הקודמת תוך דקות. יש כמה שיטות מקובלות: הדרגתית (rolling), שבה השרתים מתעדכנים כמה בכל פעם, blue-green, שבה עותק שני עולה לאוויר בהחלפה אחת, ו-canary, שבה הגרסה החדשה מגיעה קודם לחלק קטן מהמשתמשים.

למה זה חשוב

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

קשור ישירות: Staging (סביבת טרום ייצור), פרודקשן (Production), Git (בקרת גרסאות).

טיפים לשיפור

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

טעויות נפוצות

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