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

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

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

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

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

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

שיפור הבקרה ותהליכי העבודה
קיימות שתי גישות עיקריות לשיפור הבקרה ותהליכי העבודה :
1. הקמת סביבת Staging או "במה"- סביבה נוספת לשלוש הסביבות הקלאסיות, אשר מדמה ככל האפשר את סביבת הייצור של הארגון ....
לכתבה המלאה -
http://www.extreme-sw.co.il/press.aspx?pid=37