בשעה טובה הסתיים הפרוייקט, הלקוח "עלה לאויר" עם מערכת ב-Production ובקבוקי השמפניה נפתחו... לאחר כמה שבועות (או חודשים ולפעמים אפילו שנים...) מגלה אחד המשתמשים את אשר לא גילו כל צוותי הפיתוח, ה-QA והיישום לפניו: באג. בסופו של תהליך התמיכה, מתקבל ה-Patch בו הבאג המתוקן. מה עושים עכשיו?
מודל השכבות של Dynamics AX מאפשר את גמישותה של המערכת ביכולת להתאים אותה לצרכים ממוקדים יותר ויותר. כך, ניתן להלביש על שכבת הליבה המשותפת לכל העולם, את שכבת הלוקאליזציה המותאמת רק לאזור או או ארץ מסויימת. כך, ניתן גם להוסיף על גבי הלוקאליזציה ורטיקל המתאים לתעשיה מסויימת ולבסוף להוסיף התאמות (קסטומיזציות) היחודיות לצרכי הלקוח המסויים.
החוכמה בשיטת השכבות היא ששינויים הנעשים בשכבה מסויימת אינם פוגעים בשכבה הבסיסית יותר שתחתיה וכך מתאפשר המשך עדכון ותחזוקה של כל שכבה על-ידי האחראים לה. באופן כזה, אם יש באג שיש לתקן או שיפור שיש להכניס בליבת המוצר, ניתן לעדכנה על אף שעל שקיימים לוקאליזציות ו/או ורטיקאלים שנגזרים ממנה.
עם זאת, את שכבת הלוקאליזציה ו/או הורטיקל יש צורך "לסנכרן" עם השינויים שבוצעו בשכבת הליבה. הצוותים האחראים על הלוקאליזציות והצוותים (או החברות) המפתחים ורטיקאלים עושים זאת על בסיס קבוע, כך שעדכוני התכנה "יחלחלו" לכל השכבות.
באופן דומה, שינוי בשכבת הליבה, בשכבת הלוקאליזציה או בשכבת הורטיקאל מצריכים לעיתים (אם יש אובייקטים משותפים) סנכרון ועדכון של קסטומיזציות שפותחו ע"י שותף (או הלקוח) בסביבת הלקוח.
נשמע מסובך?
לא בהכרח. Dynamics AX מכילה כלים מובנים על-מנת לבצע פעולות אלו ומרגע שמובנת "תאורית השכבות", וקשרי הגומלין בין השכבות, התהליך עצמו הוא טכני לחלוטין ואינו אמור לארוך זמן רב מדי.
השלבים המקובלים בתהליך התקנה וסנכרון של Hotfix יהיו אלו (כמודגם גם בתרשים):
- התקנת ה-hotfix בסביבת בדיקות או פיתוח.
- בדיקה האם פותר את הבעיה שלשמה הותקן. חשוב לצורך הבדיקה הנ"ל לבודד השפעות של שכבות מעל. למשל תיקון בלוקאליזציה יש לבדוק בסביבה בה אין ורטיקל או קסטומיזציות. אחרת- יש קודם להשלים את סנכרון הסביבות כפי שיוסבר להלן ורק אז לבצע את הדיקה.
- בהנחה שהתיקון נבחן והתקבל, יש להתקינו בסביבת פיתוח בה יבוצעו סינכרון של כל השכבות.
- בשכבת הקסוטומיזציות (למשל שכבת USR) יש להקים פרוייקט פיתוח חדש ובו לבצע השוואה וסינכרון (באמצעות כלי המערכת המובנה) בין שכבת הקסטומיזציות לשכבות שהשתנו (למשל שכבת הקסטומיזציות). בסוף התהליך עושים ייצוא של הפרוייקט.
- חשוב לזכור, שייתכן ש-hot fix מסויים מכיל אובייקטים ביותר משכבה אחת (למשל גם בשכבת הלוקאליזציה וגם בשכבת הליבה). במקרה כזה יש לחזור על פעולת ההשוואה והסנכרון עבור כל שכבה (כלי המערכת יודע להשוות רק בין שתי שכבות בכל פעם) ורק אז לבצע ייצוא של הפרוייקט.
- בדיקת תקינות האינטגרציה על סביבה המדמה את סביבת ה-Production ככל האפשר. מתקינים ה את ה-hot fix ומייבאים את הפרוייקט שיצרנו. מהדרים ("מקמפלים") את כל האפליקציה ומסנכרנים את בסיס הנתונים לשינויים האחרונים.
- לאחר שבדקנו את הסביבה - הבאג תוקן ודברים אחרים לא התקלקלו, נחזור על הפעולה והפעם בסביבת ה-Production.
זהו. סיימנו את ההתקנה ואפשר להמשיך לעבוד כרגיל.
חשוב לדעת:
- כל הפעולות המתוארות לעיל תבוצענה כאשר אין אף משתמש מחובר לשרת.
- יש לדעת שהפורטל ה-BI או ה-workflow נחשבים לצורך העניין גם כמשתמש במערכת (ולכן יש לנתקם גם כן).
- לכל שכבה סטנדרטית יש שכבה של patching. לדוגמא מעל שכבת SYS (ליבה) ישנה שכבת SYP לטובת Patching ובאופן דומה GLP היא שכבת ה-Patching של GLS (לוקאליזציה).
- התהליך זהה הן ל-hotfix והן להתקנת Rollup (אסופה תקופתית של hotfix ועדכוני מערכת). Hotfix יכיל בד"כ מספר מוגבל מאד של אובייקטים ולכן התהליך המתואר לעיל יהיה יחסית קצר (שעות בודדות) בד"כ. Rollup עשוי להכיל שמות אובייקטים גדולה ולכן התהליך עלול להיות מעט ארוך יותר. עיקר הארכת הזמן קשור בהיקף הבדיקות הדרש ופחות בגלל החלק הטכני (פרוייקט ההשוואה), שגם כאן אמור לארוך שעות בודדות.
- מורכבות התהליך ומשך הזמן הנדרש לבצעו, קשורים באופן ישיר לכמות הקסטומיזציות ומורכבותן אשר מותקנות אצל לקוח מסויים.
התהליך הפרטני מתואר ב-White paper בלינק הזה. הרצאה מפורטת על מודל השכבות, התקנות עדכונים ומה שביניהם תינתן בקרוב במסגרת ה-mAXimum Academy במהלך השבועות הקרובים.
