בקצרהלפני שדרוג Priority: תכננו את מסלול הגרסאות, קחו גיבוי מאומת, שדרגו קודם עותק בדיקות, מצאו בדיוק מה מותאם, השוו אותו לגרסת היעד ותקנו את הפריטים הקריטיים. ביום השדרוג: הקפיאו שינויים והחזיקו תוכנית חזרה מוכנה. אחריו: הריצו שוב את תרחישי הבדיקה ועקבו מקרוב אחרי הימים הראשונים.
תכנון
- בחרו את גרסת היעד ואת המסלול אליה. שדרוג עובר דרך כל גרסה שבדרך, לא רק האחרונה.
- הגדירו מי אחראי על מה: IT, השותף לפריוריטי, המפתחים ומשתמשי המפתח.
- קבעו תקציב וחלון השבתה, עם מקום לתיקון מה שתמצאו.
- רשמו את הממשקים והמערכות החיצוניות שמדברים עם Priority.
הכנה
- קחו גיבוי מלא, וודאו שהוא באמת משתחזר.
- הקימו סביבת בדיקות מעותק של סביבת הייצור.
- מפו את ההתאמות שלכם מול עותק ייחוס נקי של הגרסה הנוכחית.
- השוו לגרסת היעד ודרגו את הממצאים לפי סיכון.
- תקנו או החילו מחדש את הפריטים הקריטיים — קודם בסביבת הבדיקות.
- כתבו עם משתמשי המפתח תרחישי בדיקה לתהליכים החשובים ביותר: הזמנות, חשבוניות, מלאי, סגירת חודש.
ביום השדרוג
- הקפיאו שינויים בקוד ובהגדרות של סביבת הייצור.
- הריצו את השדרוג קודם בסביבת הבדיקות, ורק אחר כך בייצור.
- החזיקו מוכנים את תוכנית החזרה ואת הגיבוי.
- הריצו בדיקת שפיות קצרה לפני שהמשתמשים חוזרים.
אחרי השדרוג
- הריצו שוב את כל תרחישי הבדיקה בסביבת הייצור.
- בדקו ממשקים ומשימות מתוזמנות.
- עקבו מקרוב אחרי שגיאות ודיווחי משתמשים בימים הראשונים.
- תעדו מה השתנה — לקראת השדרוג הבא.
איפה UpgradeGuard נכנס
הסעיפים "מפו את ההתאמות שלכם" ו"השוו לגרסת היעד" הם בדיוק מה ש-UpgradeGuard עושה אוטומטית: השוואה דטרמיניסטית מול גרסאות ייחוס נקיות, עם ממצאים מדורגים והסיבה לכל אחד.
שאלות נפוצות
מה גורם לרוב הבעיות אחרי שדרוג Priority?
התאמות באובייקטים הסטנדרטיים של Priority שהגרסה החדשה החליפה או שינתה, וקוד שתלוי בטבלאות ובעמודות שהשתנו.
אפשר לדלג על גרסאות?
לא במובן של להימנע מהשינויים שלהן: שדרוג מתקין כל גרסה בדרך, ולכן צריך לבדוק מול כל אחת מהן.
מי צריך להיות מעורב?
IT, השותף לפריוריטי או המפתחים, ומשתמשי מפתח מכל מחלקה — שיודעים אילו תהליכים חייבים לעבוד ביום הראשון.
עודכן לאחרונה ב-19 באוקטובר 2026.