סדר הפעולות בקבלת מערכת Magic / Unipass / XPA ללא חפיפה
שלב 1: להימנע מאי הבנות בתהליך
לפני שנוגעים במקלדת, יש לקבוע עובדות בשטח:
- עבודה בשקיפות מלאה: התחברות מרחוק תתבצע אך ורק כשהלקוח צופה במסך.
- תיעוד מצב קיים: בקשו מהלקוח להדגים תהליך ליבה אחד שעובד ותהליך אחד שאינו עובד.
שלב 2: מיפוי סביבת העבודה (Environment Audit)
זיהוי המרכיבים הטכנולוגיים של המערכת:
| פרמטר | מה לבדוק? | דגש מג'יק |
| גרסת מנוע | xpa, uniPaaS, V9, V10? | משפיע על ניהול הזיכרון וקבצי ה-INI. |
| בסיס נתונים | MSSQL, Oracle, Pervasive? | בדקו את ה-Gateway בהגדרות המערכת. |
| מצב ריצה | Single User / Multi User | האם יש שימוש ב-Enterprise Server / Broker? |
| מערכת הפעלה | Win Server 2012/2019/2022? | תאימות גרסאות (Compatibility). |
| שפה | עברית (Visual/Logical) | מה שפת המערכת? |
שלב 3: וידוא גיבויים ואמינות נתונים
אל תסמכו על המילה "יש גיבוי".
- שיחה עם איש הסיסטם: ודאו אם הגיבוי הוא ברמת הקבצים או ברמת ה-Snapshot של השרת.
- סוג הגיבוי: האם ה-DB מגובה בנפרד (SQL Backup)?
- בדיקת תקינות: בקשו מהלקוח להריץ שאילתה או דוח פשוט כדי לוודא שהמערכת כרגע "חיה" ולא נעולה.
שלב 4: תחילת העבודה: יצירת "קפסולת זמן" (Self-Backup)
לפני שתבצעו איזשהו שינוי, צרו לעצמכם עותק מקומי, זה חשוב במיוחד:
- רישום תאריכים: תעדו את תאריכי שינוי הקבצים (Modified Date) של ה-Runtime (.ecf / .cab) ושל ה-Source (.edp / XMLs). – לפני שאתם מעתיקים אותם אליכם
- ייצוא קבצים: משכו אליכם עותק של קובץ ה-Magic.ini, קבצי המקור וקבצי הריצה.
שלב 5: בדיקת "חיוניות" סורס (The Sanity Build)
זהו השלב הקריטי ביותר – האם מה שיש לנו ביד הוא באמת מה שרץ אצל הלקוח?
- יצירת אובייקט בדיקה: בתוך סביבת הפיתוח, צרו תוכנית חדשה (בתחתית הרשימה) עם פקודה ריקה או Verify.
- שימוש בתפריטים: אל תשתמשו בקיצורי מקלדת (F6, F7) מחשש למיפויים שונים. השתמשו בתפריט ה-Options.
- בדיקת כתיבה: סגרו ופתחו את ה-Studio. אם התוכנית נעלמה – המערכת מוגדרת כ-Read Only או שאין הרשאות כתיבה אליה או תקלה אחרת לפני שתפתר אין באפשרותכם/ן לשנות אותה.
שלב 6: חקירה ארכיאולוגית (Information Gathering)
אם יש קצה חוט לאדם שעבד על המערכת, אלו שאלות החובה:
- תקינות קומפילציה: האם הסורס הנוכחי מתקמפל ללא שגיאות?
- פיתוחים פתוחים: האם יש בסורס תוכניות במצב "Check-out" או קוד חצי אפוי?
- אוטומציות: האם יש Batch tasks שרצים ברקע (Task Scheduler) ועלולים להיפגע מעדכון גרסה? או אולי בתוכנית הראשית דברים שרצים בתנאים מסויימים שהפעלתם בטעות תגרום בעיות או תקלות או עדכונים לא רצויים?
- תהליך Deployment: איך נהוג להעביר כאן גרסה (החלפת ECF, הרצת סקריפט ?
שלב 7: ניהול סיכונים וסביבת עבודה (Sandboxing)
הכלל המוזהב: לעולם אל תפתחו על ה-Production.
- העתקה למקומי: העתיקו את כל הסביבה (כולל ה-DB, אם ניתן) למחשב שלכם.
- בדיקת דלתא: השוו את גודל קובץ הריצה החדש שיצרתם(Build), מהגירסה המקורית של קובץ הפיתוח (לא זה שהוספתם לו שורה לראות שאפשר לשנותו), מול קובץ הריצה המקורי. פער כלשהו בגודל מעיד על חוסר התאמה בין הסורס לריצה.
שלב 8: צלילה לקוד (Deep Dive)
לפני ביצוע שינוי לבקשת הלקוח:
- בדיקת ה-Main Program: במג'יק, תוכנית זו יכולה להכיל לוגיקה שמשפיעה על כל המערכת (Events, תנאי פתיחה: חובה להבין אותה.
- תאריכי תוכניות: עברו על רשימת התוכניות (Task list). תוכניות עם תאריכים חריגים (חדשים יותר מה-Runtime הן "חשודות" כפיתוח שלא הסתיים.
שלב 9: הרצה מבוקרת (The Canary Run)
לאחר ביצוע שינוי קטן:
- החליפו את גרסת הריצה.
- תנו למערכת לרוץ שבוע תחת עומס רגיל.
- רק לאחר שבוע של "שקט תעשייתי", ניתן להתחיל בפיתוח משמעותי.
הערה חשובה למתכנת!:
הדברים לעיל הינם בגדר המלצה בלבד. האחריות להחליט מה לעשות ואיך והתוצאות של החלטות אלו הן של המתכנת בכל מקרה ומקרה. ייתכנו טעויות במדריך זה או אי התאמה למקרה כזה או אחר.
הערה חשובה נוספת למתכנת:
למרות שהטקסט לעיל מכיל תשעה שלבים והרבה מלל – קבלת מערכת ללא חפיפה לא אמורה לקחת יותר ממספר שעות בודדות לרוב.
הערה אחרונה:
מדריך זה נכתב בלשון זכר אך מכוון לכל המינים.
- שיהיה בהצלחה! –