אסטרטגיית סביבות
מפת Sandbox, Scratch Orgs ו-UAT מול קצב העבודה בפועל.
CI/CD ו-DevOps ל-Salesforce
שחרור גרסאות מפסיק להיות אירוע מלחיץ כשיש לו תהליך.
אנחנו בונים צינור שחרור מבוקר ל-Salesforce: מקור אמת אחד בגיט, סביבות מוגדרות, בדיקות אוטומטיות, שערי איכות ותהליך חזרה לאחור — כך שכל שינוי מגיע לפרודקשן בצורה צפויה ומתועדת.
צינור השחרור
איך שינוי עובר מפיתוח לפרודקשן
התרשים מציג את הצינור המלא, מהסביבה שבה נכתב השינוי ועד הבקרה שאחרי העלייה לאוויר.
Governed Release Pipeline
מקור
מאיפה מגיע השינוי
- Scratch Org / Sandboxפיתוח מבודד
- מטא-דאטה בגיטמקור אמת יחיד
- Branch לפי משימהמעקב לדרישה
אינטגרציה
מה נבדק אוטומטית
- Pull RequestReview חובה
- ניתוח סטטיPMD ותקני קוד
- Apex Testsכיסוי ואיכות
שערי איכות
מה חוסם מעבר
- Coverage מינימליסף מוגדר מראש
- בדיקות רגרסיהתרחישים קריטיים
- אישור עסקיUAT מתועד
שחרור
איך מגיעים לפרודקשן
- Deploy אוטומטיאותו ארטיפקט
- Data Seedingסביבות עקביות
- חלון שחרורמתוזמן ומוכרז
בקרה
מה קורה אחרי
- Rollback מתוכנןנתיב חזרה ידוע
- ניטור וחריגותהתראות מוגדרות
- Release Notesתיעוד לכל גרסה
הרקע
מה באמת מכריע כאן
ברוב הארגונים תקלות שחרור אינן נובעות מקוד גרוע אלא מהעדר תהליך. שינויים נעשים ישירות בסביבה, אף אחד לא יודע מה בדיוק נדחף, ואין דרך מסודרת לחזור אחורה.
CI/CD ל-Salesforce אינו רק כלי. הוא הסכמה על מה נחשב שינוי מאושר, מי מאשר אותו, אילו בדיקות חייבות לעבור ומה קורה כשמשהו נכשל.
התוצאה הנכונה היא לא יותר אוטומציה לשם עצמה, אלא קצב שחרור גבוה יותר עם פחות הפתעות — וכל גרסה שניתן להסביר, לשחזר ולבטל.
תחומי עבודה
מה אנחנו עושים בפועל
מטא-דאטה בגיט
מבנה מאגר, Branching ומדיניות מיזוג שמתאימה לצוות.
צינור אוטומטי
בנייה, בדיקות ו-Deploy דרך GitHub Actions, Azure DevOps או Gearset.
שערי איכות
כיסוי בדיקות, ניתוח סטטי ואישור עסקי כתנאי מעבר.
ניהול נתונים בסביבות
סטים של נתוני בדיקה עקביים ללא העתקת מידע רגיש.
שחרור ו-Rollback
חלונות שחרור, Release Notes ונתיב חזרה מוגדר מראש.
מודל בשלות
איפה הארגון נמצא היום
רוב הארגונים נמצאים בין רמה 1 לרמה 3. הקפיצה המשמעותית ביותר היא המעבר לגיט כמקור אמת.
| רמה | איך זה נראה | הסיכון המרכזי | הצעד הבא |
|---|---|---|---|
| 1 — ידני | Change Sets ושינויים ישירות בפרודקשן | אין תיעוד ואין דרך לחזור אחורה | העברת המטא-דאטה לגיט |
| 2 — מבוקר חלקית | גיט קיים אך ה-Deploy ידני | פערים בין סביבות | אוטומציה של ה-Deploy |
| 3 — אוטומטי | צינור שרץ על כל PR | בדיקות חלשות שמאשרות הכול | הגדרת שערי איכות |
| 4 — מבוקר | שערי איכות חוסמים מעבר | עיכוב בשחרור בגלל תהליך כבד | בדיקות רגרסיה ממוקדות |
| 5 — רציף | שחרור תכוף עם Rollback ידוע | שאננות תפעולית | ניטור וסקירות תקופתיות |
1 — ידני
- איך זה נראה
- Change Sets ושינויים ישירות בפרודקשן
- הסיכון המרכזי
- אין תיעוד ואין דרך לחזור אחורה
- הצעד הבא
- העברת המטא-דאטה לגיט
2 — מבוקר חלקית
- איך זה נראה
- גיט קיים אך ה-Deploy ידני
- הסיכון המרכזי
- פערים בין סביבות
- הצעד הבא
- אוטומציה של ה-Deploy
3 — אוטומטי
- איך זה נראה
- צינור שרץ על כל PR
- הסיכון המרכזי
- בדיקות חלשות שמאשרות הכול
- הצעד הבא
- הגדרת שערי איכות
4 — מבוקר
- איך זה נראה
- שערי איכות חוסמים מעבר
- הסיכון המרכזי
- עיכוב בשחרור בגלל תהליך כבד
- הצעד הבא
- בדיקות רגרסיה ממוקדות
5 — רציף
- איך זה נראה
- שחרור תכוף עם Rollback ידוע
- הסיכון המרכזי
- שאננות תפעולית
- הצעד הבא
- ניטור וסקירות תקופתיות
אופן העבודה
שלבי הביצוע
- 01
מיפוי מצב קיים
סביבות, כלים, קצב שחרור ונקודות הכשל בפועל.
- 02
תכנון הצינור
Branching, סביבות ושערי איכות מותאמים לצוות.
- 03
הקמת תשתית
מאגר, אוטומציה ובדיקות ראשונות בסביבת בדיקה.
- 04
הרצה מקבילה
הצינור החדש רץ לצד התהליך הקיים עד לייצוב.
- 05
הסבת הצוות
נהלים, הרשאות והדרכה לפי תפקיד.
- 06
בקרה שוטפת
מדידת קצב, כשלים וזמן התאוששות.
להמשיך מכאן
שירותים ומדריכים קשורים
שאלות נפוצות
שאלות שחוזרות
האם צריך צוות פיתוח גדול כדי להצדיק CI/CD?
לא. גם צוות של שניים או שלושה נהנה מהתהליך, כי הערך העיקרי הוא ודאות ותיעוד ולא היקף. בצוות קטן פשוט בונים צינור פשוט יותר.
אנחנו עובדים בעיקר עם Flow ו-Configuration. זה רלוונטי?
בהחלט. שינויי הגדרה ואוטומציה הם מטא-דאטה לכל דבר, והם דווקא הגורם השכיח לתקלות שחרור. ניהול שלהם בגיט מספק שקיפות מלאה.
באיזה כלי אתם משתמשים?
הבחירה נגזרת מהארגון. GitHub Actions או Azure DevOps מתאימים לצוותים טכניים, וכלים כמו Gearset או Copado מתאימים כשרוב העבודה היא Configuration.
כמה זמן לוקח להקים תהליך כזה?
צינור בסיסי עולה לאוויר תוך מספר שבועות. הרחבה לשערי איכות מלאים ולבדיקות רגרסיה נעשית בהדרגה, כדי לא לעצור את הפיתוח השוטף.
השלב הבא
בניית תהליך שחרור
נמפה את מצב הסביבות והשחרור היום ונגדיר את הצינור שמתאים לקצב העבודה שלכם.
השלב הבא
בניית תהליך שחרור
נמפה את מצב הסביבות והשחרור היום ונגדיר את הצינור שמתאים לקצב העבודה שלכם.