אוטומציה של פריסה ב-DigitalOcean App Platform: CI/CD וקונפיגורציה

פריסות ידניות ב-DigitalOcean App Platform: היכן התהליך נשבר

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

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

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

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

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

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

מה נותנת האוטומציה של בנייה, בדיקות ופריסה

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

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

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

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

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

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

גישות לפריסה רציפה: השוואת מצבים

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

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

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

כיצד אנחנו מטמיעים אוטומציה: שלבי העבודה

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

1. ביקורת תשתית ותהליך המהדורה: היכן נבנית האפליקציה, מהיכן מגיעים המשתנים, מה עדיין נעשה בידניים. מסמנים צעדים שממתינים לאדם מסוים.
2. תרשים הסביבות: מפרידים בין סביבת הפיתוח, סביבת הבדיקות וסביבת העבודה, ומצמידים לכל אחת סודות ודומיין משלה. תצורה זהה עם ערכי משתנים שונים מסלקת סוג שלם של שגיאות «בבדיקות זה עובד».
3. הכנת הבנייה: מתארים את האפליקציה באופן הצהרתי, כדי שהאימג' ייבנה באופן זהה בכל מכונה, ומפעילים מטמון תלויות — בנייה חוזרת ללא שינויים מתבצעת מהר יותר באופן ניכר.
4. הגדרת קו הייצור: מחברים את המאגר ל-DigitalOcean App Platform, מגדירים טריגרים לענפים ובדיקות חובה לפני הפריסה. הפריסה מתחילה רק לאחר מעבר הבדיקות.
5. סודות והרשאות גישה: מפתחות ומשתנים מועברים למאגר מאובטח של הפלטפורמה, ההרשאות לסביבת העבודה מוגבלות, והפעולות נרשמות ביומן.
6. בדיקת החזרה לאחור: משחררים במכוון משתנה שגוי ומיגרציה שנכשלת — ומוודאים שהגרסה הקודמת חוזרת בפעולה אחת, והנתונים נשארים שלמים.
7. מסירה לתפעול: מוסרים תצורות, את תרשים הסביבות ואת נוהל השחרור, ומריצים יחד עם צוות הלקוח שינוי אמיתי מהקומיט ועד לפרוד.

מה נשאר אצלכם לאחר ההטמעה: ארטיפקטים ונהלים

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

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

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

מקרה בוחן: מפריסות ידניות לקו ייצור אוטומטי

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

המטריקות ברבעון שלפני האוטומציה: שחרור — בין ארבע לשש שעות, מתוך 40 פריסות תשע הסתיימו בחזרה לאחור, כלומר כמעט רבע. שחזור המצב הקודם — 40–60 דקות בידניים, וסדר הצעדים נשען על מהנדס אחד שזכר את הרצף שלהם.

מה שינינו

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

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

מה קרה בסופו של דבר

השחרור אורך 20–25 דקות, זמן המהדורה התקצר פי כ-12, ומתוכן נותרו כשלוש פעולות ידניות: לאשר הפעלה ולעיין בדוח. שיעור הפריסות הכושלות ברבעון ירד ל-3–4%, החזרה לאחור היא מעבר לאימג' הבנוי הקודם תוך דקות ספורות, וחלון לילה כבר אינו נדרש. המהנדס שהוביל את הפריסות חזר למשימות המוצר.

במה נבדלת App Platform מפריסה על שרתים

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

DigitalOcean App Platform פועלת בדיוק כך: המהנדס מתאר את האפליקציה, את משתני הסביבה ואת כללי ה-scaling, ולא את מערכת ההפעלה שמתחתיה.

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

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

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

ספקות טכניים נפוצים לפני ההתחלה

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

מה הפלטפורמה לא יודעת לעשות?

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

האם אנחנו לא נועלים את עצמנו אצל ספק אחד?

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

היכן מאוחסנים הסודות ומי רואה אותם?

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

כיצד מפרידים בין סביבות?

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

המהדורה שברה את סביבת העבודה — מה הלאה?

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

מה נדרש מכם כדי לדון במשימה

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

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

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