התשובה הקצרה
אסטרטגיית סביבות טובה עונה על שלוש שאלות: איפה כל סוג עבודה מתבצע, איך שינוי עובר קדימה, ואיך חוזרים אחורה כשמשהו נשבר. המבנה שעובד ברוב הארגונים הוא Developer לכל מפתח, סביבת אינטגרציה משותפת, סביבת UAT עם נתונים מייצגים ו-Production — עם Git כמקור אמת יחיד ופריסה אוטומטית לפחות עד ה-UAT.
מפת הסביבות
| סביבה | סוג | מה קורה בה | נתונים |
|---|---|---|---|
| פיתוח אישי | Developer | בנייה, ניסויים, בדיקות יחידה | Metadata בלבד |
| אינטגרציה | Developer Pro | מיזוג עבודת כל הצוות, CI | דגימה קטנה מסונתזת |
| UAT | Partial או Full | קבלה עסקית, הדרכה, תרחישי קצה | נתוני אמת ממוסכים |
| Staging / Full | Full | חזרה גנרלית ל-Release, בדיקות נפח | עותק מלא ממוסך |
| Production | — | עבודה שוטפת | אמת |
Sandbox ל-Hotfix מומלץ לארגונים ששחרור שלהם נמשך יותר משבועיים: בלעדיו כל תיקון דחוף מאלץ פריסה של עבודה שעדיין לא הבשילה.
מ-Change Sets ל-Source-Driven
המעבר נעשה בשלושה שלבים. תחילה מייצאים את המטא-דאטה הקיימת ל-Repo ומקבעים מבנה ואסטרטגיית ענפים פשוטה — ענף ראשי, ענף Release וענפי Feature קצרים. אחר כך מחברים CI שמריץ על כל Pull Request Validation Deploy מול סביבת האינטגרציה, בדיקות Apex ובדיקות סטטיות. בשלב השלישי מחברים פריסה אוטומטית ל-UAT, ומשאירים את הפריסה ל-Production כפעולה מאושרת ידנית עם חלון שחרור מוגדר.
מה שמכשיל את המעבר אינו הכלי אלא היקף: ניסיון להכניס את כל ה-Org ל-Repo בבת אחת מייצר אלפי קבצים שאיש אינו מסוגל לסקור. עדיף להתחיל בקבוצת מטא-דאטה של תחום עסקי אחד ולהרחיב הדרגתית.
מה שלא נכנס ל-Repo
חלק מהמצב אינו מטא-דאטה שניתן לפרוס: רשומות הגדרה ב-Custom Settings ו-Custom Metadata תלויות סביבה, ערכי Named Credentials, Assignment Rules שמשתנות תדיר ותוכן Knowledge. לכל אחת מהקטגוריות האלה צריך להיות מסמך קצר שמגדיר מי מעדכן, איפה, וכיצד מסנכרנים בין סביבות. היעדר ההגדרה הזו הוא הסיבה הנפוצה ביותר לתקלה שמופיעה רק ב-Production.
הקשר בין קצב השחרור לשיטת העבודה מפורט בAgile מול Waterfall היברידי ובמדריך הטמעת Salesforce.
רענון סביבות ותחזוקה
Sandbox שלא רועננה תשעה חודשים כבר אינה מייצגת את Production, וכל בדיקה בה נותנת ביטחון שווא. הכלל הפשוט: סביבת UAT מרועננת לפני כל Release משמעותי, סביבות פיתוח מרועננות בסיום כל גל. חשוב לתכנן מראש את מה שאובד ברענון — נתוני בדיקה, משתמשים, הגדרות — ולהחזיק סקריפט Post-Refresh שמשחזר אותם תוך שעה ולא תוך שלושה ימים.
סיכונים נפוצים ופעולות מניעה
הסיכון הראשון הוא Drift: פערים שמצטברים בשקט בין Production לבין ה-Repo. השוואת מטא-דאטה שבועית אוטומטית עם התראה היא ההגנה היחידה שעובדת.
הסיכון השני הוא בדיקות Apex שנכתבו רק כדי לעבור את סף הכיסוי. כיסוי של 75% ללא Assertions אמיתיות אינו רשת ביטחון, והוא נותן ביטחון מזויף בדיוק ברגע שבו נדרש ביטחון אמיתי. הסיכון השלישי הוא צוואר בקבוק אנושי: אדם יחיד שמורשה לפרוס. חייבים לפחות שניים, עם הרשאות מתועדות.
כיצד מודדים הצלחה
ארבעה מדדים: תדירות שחרור, זמן ממיזוג ועד Production, שיעור פריסות שנכשלו, ומספר Hotfixes בחודש שאחרי כל Release. שיפור אמיתי נראה כך — תדירות עולה, זמן יורד, ושיעור הכשלים וה-Hotfixes יורד במקביל. עלייה בתדירות לצד עלייה ב-Hotfixes משמעה שהמסלול מהיר יותר אך הבדיקות אינן מספיקות.