RESOURCES

המדריך שעושה סדר בכל הבאזז ומסביר אחת ולתמיד איך כל החלקים באמת מתחברים (בלי לגרום לכם להירדם על המקלדת).

אנחנו כמובן מדברים על CI/CD ולא על AC/DC למרות שזה נשמע דומה (ונכון שאנחנו מעדיפים את השני יותר) אבל CI/CD במקום לעשות רעש לפחות עושה סדר. אז במקום סולואים על גיטרה (Thunderstruck מישהו?) – תקבלו תהליכים אוטומטיים, שקט נפשי, וקוד שלא מתפוצץ ביום ראשון בבוקר.
אם אתם בעולם הפיתוח או DevOps, כנראה כבר נתקלתם בראשי התיבות האלה בכל שיחה שלישית (או פשוט כל שיחה). וכמו כל דבר שנשמע טכני מדי – זה לא כזה מסובך כשמבינים. אז בואו נפרק את זה לחלקים, כי CI ≠ CD (ול-CD יש בכלל שני צדדים – אין יותר פשוט מזה, נכון? 😂)

Continuous Integration – הקוד נכנס מוקדם, הבעיות יוצאות מוקדם.

כאן הרעיון פשוט:
במקום שכל מפתח יחכה עם השינויים שלו בצד, ואז יעלה הכול יחד ביום חמישי ב-16:45 (ולחץ דם בהתאם) – כל שינוי קטן עולה ישר לבראנץ’ מרכזי (אנחנו לא מתכוונים לארוחת בוקר מאוחרת).

למה? כי כל פעם שאתם עושים push, תהליכי Build ובדיקות (כולל תהליכי בדיקות איכות קוד וסקיוריטי) רצים באופן אוטומטי. ככה אתם יודעים מיד אם משהו נשבר — ולא רק אחרי שצוות ה-QA כבר סגר את השבוע. זה כאילו יש לכם רובוט קטן שאומר: “היי, הוספת עוד כפתור לעמוד? רגע, נבדוק אם זה שבר את כל האתר. 😉”

אז מה יוצא לכם מזה?

▪️ אתם לא מחכים למיזוג ענקי של כל הקוד מהחודש האחרון
▪️ אין באגים שמסתתרים ומופיעים רק בשלבים המאוחרים יותר (שמן הסתם הם גם אלו שהרבה יותר יקר לתקן)
▪️ והכי חשוב – אתם יודעים שהמערכת נשארת יציבה, גם כשכל הצוות עובד במקביל

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

 Continuous Delivery – כשהמערכת מוכנה לעלות, גם אם אתם עוד לא

אז אחרי שבישלנו את התוצרים בצורה מוצלחת בלי טעויות (ויותר מדי מלח), מגיע שלב ההגשה.

Continuous Delivery (או בקיצור CD) אומר שכל שינוי שעבר את ה־CI מוכן לעלות לפרודקשן – אבל לא עולה אוטומטית. במילים אחרות: הקוד עבר את כל הבדיקות, התלבש יפה, עומד ליד הדלת עם תיק – ואתם מחליטים מתי לשלוח אותו ללקוחות. בין אם זה כי מחכים לאישור מהמוצר, רוצים להשיק גרסה באירוע, או פשוט מעדיפים לא לשחרר שינוי ביום ראשון בבוקר – הכול טוב.

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

ולמה זה חשוב?

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

בקיצור:
Continuous Delivery זה כמו להזמין מונית מראש – היא כבר מחכה למטה. אתם רק צריכים להחליט מתי לצאת מהבית.

Continuous Deployment – בלי כפתורים, בלי אישורים, פשוט רץ

אם Continuous Delivery נתן לכם את האפשרות ללחוץ על כפתור ולשחרר גרסה מתי שנוח – Continuous Deployment (כן גם זה CD) לוקח את זה צעד אחד קדימה, או בעצם… מסיר את הכפתור לגמרי.

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

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

למה זה חשוב?

▪️ כל שינוי שהצלחתי – נפרס מיד, בלי עיכובים
▪️ פחות “גרסאות”, יותר זרימה טבעית של עדכונים
▪️ משחררים מהר → מקבלים פידבק מהר → מתקנים מהר

בניגוד ל-Continuous delivery שהוא: 2,3 – ש-גר, כאן אתה לא מספיק למלא את הדלק והטיל כבר ממריא לבד.

אז איך הכול מתחבר?

Continuous Integration הוא שלב חובה – עליו כולם מסכימים.
אבל אחרי ה־CI, מגיעה ההתפצלות: יש מי שבוחר ללכת ל־Continuous Delivery, ויש מי שמתקדם ל־Continuous Deployment.
שתי הדרכים משתמשות באותן תשתיות: בדיקות אוטומטיות, תהליך בנייה סגור, קוד מוכן לעלייה.
ההבדל הוא בשלב השחרור – האם מחכים לאישור ידני (Delivery) או שמעלים אוטומטית לפרודקשן (Deployment).

אז איך מחליטים?

זה לא רק עניין של “כמה אוטומציה אתם רוצים”, אלא גם של מה שמתאים למוצר, לארגון, ללקוחות ולרגולציה. במערכות קריטיות או רגישות, הרבה פעמים יעדיפו לעצור רגע לפני העלייה. אבל השאיפה ברוב המקומות, כשזה אפשרי, היא כן להגיע ל־Continuous Deployment – כדי לשחרר מהר, להגיב מהר, ולשפר מהר.
בשורה התחתונה, CI/CD זה לא תהליך שרק יוצר רעש – הוא עושה סדר, מספק קוד אמין ונשאר רגוע, גם כשכולם עובדים במקביל.

אם המערכת שלכם מרגישה כמו ג’ונגל של קוד, באגים ולחץ רגע לפני עלייה — הגיע הזמן לעשות בזה סדר.
💬 כתבו לנו ל־devops@matrix.co.il
אנחנו נגיע, נפרק את הבלאגן, ונרכיב לכם תהליך שעובד חלק – כמו CI שיודע לזהות באג עוד לפני שהוא חושב להופיע. 😉