בקצרה

בשיטת Expand Contract Migration מוסיפים מבנה חדש למסד הנתונים לצד הישן, מעבירים אליו נתונים והתנהגות יישומית, ורק אז מסירים את המבנה הישן לאחר הפסקת השימוש בו. בשינויים שנוצרו בעזרת AI בודקים תאימות בכל שלב. קוד שנכתב מהר אינו מוכיח שעובדי רקע, דוחות וגרסאות לנסיגה עדיין יפעלו.

הרעיון של המאמר, משורטט ב־18 שניות. לחצו על הרמקול לסאונד.

השינוי שהסוכן יצר הוא רק חלק מהתמונה

סוכן קוד יכול להציע מודל נתונים מסודר יותר ולעדכן את היישום בשינוי אחד. בפרודקשן עדיין עשויים לפעול מופע ישן של האתר, משימה שהתעכבה או חיבור לדוחות שמצפה למבנה הקודם. מיפוי הקוראים והכותבים צריך להקדים את ההחלטה שהמודל החדש מוכן.

דוגמה להמחשה: מערכת תמיכה מחליפה את הדגל is_closed בשדה lifecycle_state מפורט יותר. הסרה ישירה של הדגל עלולה לשבור עובד רקע שעדיין משתמש בו. גם המיפוי העסקי חייב להיות מפורש: הערך false אינו מספר אם פנייה קיימת חדשה, משויכת או ממתינה. הסוכן אינו אמור להמציא את ההיסטוריה החסרה.

מרחיבים, מעבירים שימוש ורק אז מצמצמים

Prisma מתעדת את העיקרון של הוספת שדה חלופי והעברת נתונים לפני הסרת השדה הישן, לאחר שכבר לא קוראים ממנו. יישמו את העיקרון בשלבים שאפשר לבדוק בנפרד, עם בדיקות תאימות של היישום ביניהם.

בדוגמת הפניות, הוסיפו תחילה את הייצוג החדש בלי לשבור קוד קיים. הגדירו כיצד הקריאה והכתיבה נשארות עקביות כששני הייצוגים קיימים. אם כותבים ישנים עדיין משנים את is_closed, העתקה חד־פעמית אינה מספיקה: בחרו ובדקו מנגנון סנכרון, או הפסיקו את הכותבים האלה לפני העברת הסמכות לייצוג החדש.

השלימו נתונים היסטוריים לפי מיפוי מוסכם, ושמרו אי־ודאות כשאי אפשר לשחזר את ההיסטוריה. אמתו את המיפוי מול דוגמאות עסקיות והתאימו את הכתיבות החדשות בזמן המעבר. הסירו את הייצוג הישן רק לאחר זיהוי והפסקת כל צרכניו, לרבות משימות רקע ודוחות.

בדיקות מיגרציה כוללות גרסאות שפועלות יחד

בדקו בסביבה מבודדת עם נתונים מלאכותיים מייצגים או נתונים שהוסרו מהם פרטים רגישים כנדרש. כללו קוד ישן מול הסכמה המורחבת, קוד חדש לפני ואחרי השלמת הנתונים, ועובד רקע ישן שמטפל במשימה שהתעכבה. בדקו תוצאות עסקיות ועקביות, ולא רק אם פקודת המיגרציה הסתיימה בהצלחה.

תאימות מבנה והשפעה תפעולית הן שאלות נפרדות. התיעוד של PostgreSQL 18 מציין שדרישות הנעילה של ALTER TABLE משתנות לפי הפעולה, ושברירת המחדל היא ACCESS EXCLUSIVE אלא אם צוין אחרת. בדקו את הפקודה המדויקת מול גרסת מסד הנתונים שבשימוש ובחנו את התנהגותה בעומס מייצג. שינוי שמוסיף שדה אינו בהכרח נטול חסימות.

  • מפו גרסאות יישום, משימות, דוחות ואינטגרציות שניגשים לשדות המשתנים.
  • הגדירו שאילתות קבלה לנתונים שמופו, לנתונים שלא מופו ולרשומות שעודכנו לאחרונה.
  • בדקו השלמת נתונים שנקטעה והמשך שלה בלי לדרוס ערכים חדשים יותר.
  • תעדו נעילות, זמן ביצוע ותנאים שמחייבים להשהות את המיגרציה.

מגדירים נסיגה לפני שמסירים תאימות

החזרת קוד לגרסה קודמת אינה משחזרת שדה שנמחק או ערכים שאבדו. תעדו אילו גרסאות יישום מתאימות לכל שלב של הסכמה. כל עוד המסלול הישן נשמר, בדקו שהוא עדיין עובד עם הנתונים העדכניים; לאחר צמצום הסכמה, ייתכן שכבר אי אפשר לחזור לגרסה הישנה.

החזיקו תוכנית התאוששות שנבדקה ואחראי להחלטות במקרה כשל. גיבוי מועיל רק כשמבינים כיצד לשחזר אותו ומה עושים בשינויים שהתרחשו מאז יצירתו. אין להסיק מהשיטה לבדה שלא תהיה השבתה: גודל הטבלה, עומס הכתיבה, פרטי המיגרציה ודרישות ההתאוששות קובעים את התוכנית בפועל.

בקשו מסוכן הקוד הצעה מדורגת, מיפוי תלות ומקרי בדיקה. מפתח אחראי צריך לאמת אותם מול המערכת הפעילה והמשמעות העסקית של הנתונים. התייחסו לשלב הסרת המבנה הישן כהחלטת שחרור מפורשת, ולא כניקוי אוטומטי.

מחברים פיתוח מהיר לרציפות תפעולית

מפתח מנוסה יכול להיעזר ב-AI להכנה מהירה של קוד המיגרציה והבדיקות, ולמקד את הבדיקה בתאימות ובמשמעות הנתונים. שלבו מומחה מסדי נתונים או מומחה בתחום העסקי כשהשינוי חורג מניסיון הצוות. מדדו את המיגרציה בתרגול לפני בחירת חלון ביצוע בפרודקשן.

UVISION מספקת מפתחים ייעודיים ופרויקטים מנוהלים עם לפחות מפתח אחד במשרה מלאה בכל פרויקט. במערכות לגאסי (Legacy) קריטיות, האחריות המתמשכת כוללת הבנת הצרכנים הקיימים, שימור כללים עסקיים ותחזוקת המעבר עד להשלמתו. התוצר הראשון הוא תוכנית מיגרציה שאפשר להסביר ולבדוק את מצבי הביניים שלה.

שאלות נפוצות

מהי מיגרציה של מסד נתונים?

מיגרציה משנה את המבנה של מסד נתונים או מעבירה נתונים לייצוג חדש. במערכת עסקית פעילה, השינוי צריך להתחשב ביישומים, במשימות רקע ובאינטגרציות שעדיין משתמשים במבנה הישן. גישת Expand Contract מחלקת את המעבר לשלבים, אך התאימות, משמעות הנתונים וההשפעה התפעולית עדיין מחייבות בדיקה מפורשת ותכנון לפני ביצוע השינוי.

איך מנהלים מיגרציות של מסד נתונים?

מזהים את כל הקוראים והכותבים, מגדירים את המיפוי העסקי הרצוי ומתכננים מצבי ביניים תואמים. מוסיפים ייצוג חדש, מנהלים עקביות בזמן המעבר, מאמתים את הנתונים ומפסיקים צרכנים ישנים לפני הסרת השדות שלהם. מתעדים אילו גרסאות יישום נשארות שמישות בכל שלב, ומכינים תוכנית התאוששות שנבדקה לפני ביצוע השינוי בפרודקשן.

איך בודקים מיגרציה של מסד נתונים?

משתמשים בסביבה מבודדת עם נתונים מייצגים ובודקים התנהגות של יישום ישן וחדש לאורך שלבי הסכמה. כוללים משימות שהתעכבו, עדכונים במקביל, השלמת נתונים שנקטעה ודיוק של הרשומות שהומרו. בוחנים נעילות וזמן ריצה בעומס מייצג. פקודה שהצליחה אינה מוכיחה לבדה שההתנהגות העסקית או האפשרות לחזור לגרסת יישום קודמת נשמרו.

לקריאה נוספת

רוצים לבחון איך זה מתאים למערכות שלכם?

לשירות הרלוונטי