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

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

הבעיה אף גדולה יותר בחלק גדול מהארגונים – ארגונים אשר אינם מקפידים על סביבות עבודה מוגדרות ומופרדות. מוכרת לכולם החלוקה לשלוש סביבות עבודה – פיתוח ((Development, בדיקות( Testing / QA ) וייצור ((Production. אולם ההקפדה על עבודה נכונה בסביבות אלו אינה מיושמת תמיד.

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

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

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

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

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

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

· יש לבנות "חבילות הגירה" אוטומטיות. חבילת הגירה תכיל את מכלול השינויים אשר יש לבצע בהגירה מסביבת הפיתוח לסביבת הבדיקות במקרה של שימוש בסביבת בדיקות סטרילית, וכן במעבר מסביבת הבדיקות לסביבת ה- Staging במקרה של שימוש בארבע סביבות. החבילה יכולה להיות מורכבת מחבילות משנה, בדרך כלל לפי נושאים (בניית ספריות העבודה והעתקת קבצים, רישום מרוכז של רכיבים, עריכת שינויים במבנה בסיס הנתונים וכו'). החבילה יכולה להיות אוסף מסודר של סקריפטים, batch files או חבילות התקנה מסודרות – CAB, התקנה בעזרת Install Shield או Wise וכו'.

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

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

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

o אין לשכוח שבדרך כלל, בנוסף לשינויים הנדרשים בסכימה של מסד הנתונים, יש לכלול גם את שינויי הנתונים הרלוונטיים עצמם – נתוני טבלאות LOOKUP או Dictionary אשר התעדכנו.

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

א. בניית סקריפטים או שימוש בכלים לביצוע בדיקות אוטומטיות (Regression/Cover tests) אשר יבצעו באופן אוטומטי מגוון גדול של בדיקות לפעילות תקינה של המערכת. (שימושי, כמובן, גם בסביבת הבדיקות המסורתית עצמה).

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

לסיכום, שימוש מושכל יותר בסביבת ה-testing / QA או שימוש בסביבה נוספת לצורך Staging והקפדה על מעבר בין הסביבות אך ורק באמצעים אוטומטיים (סקריפטים / התקנות) יכול לשפר באופן מהותי את כמות הבאגים אשר נגלה בשלבים מוקדמים יותר, ולהוריד באופן דרסטי את כמות התקלות אשר עלולות להתרחש בעת ההגירה לסביבת הייצור עצמה.

למעלה מ-100 מומחים פועלים באקסטרים טכנולוגיות בתחומי פיתוח מוצרים ופרויקטי IT בסביבות הטרוגניות, ייעוץ ואינטגרציה. משפחת מוצרי dbMaestro מבית אקסטרים מספקת פתרונות לפיתוח, ניהול גרסאות וניהול שינויים בעולם בסיסי הנתונים ללקוחות מובילים בארץ ובעולם ממגזר הבנקאות, טלקום, תעשיה ובטחון.