זאת רשימת המשך לרשימה קודמת שפרסמתי. בהמשך נקיים גם מפגש שולחן עגול בנושא זה.
סוגי הסביבות
סביבות הבדיקה המלאות, באופן תאורטי, צריכות לכלול 4 סוגים:
1. סביבות פיתוח – בבעלות אנשי הפיתוח
2. סביבות פיתוח לטובת unit test – בבעלות אנשי הפיתוח. ישנו צורך לסביבה כזו מכיוון שסביבת הפיתוח משמשת מספר רב של מפתחים הנמצאים בגרסאות שונות של קוד וב"תהליך" כלומר קוד לא סגור ולא פונקציונלי ולכן ביצוע unit test לא ייתן תוצאה אמיתית. "סביבת הפיתוח לטובת unit test" אמורה להכיל רק קוד עובד.
3. סביבות בדיקה – בבעלות ה- QA
4. סביבות Pre-Production – בבעלות התפעול\הייצור
5. סביבות ייצור
אחריות על בניית הסביבות – "צוות סביבות"
צוות "סביבות" הוא הצוות האחראי לבניית הסביבות כאשר אחריות הצוות היא גם תפעולית (כלומר מבצע חלק מהמשימות בעצמו) אבל יותר ניהולית (מזמין שירותים מגופים אחרים בארגון לטובת ייצור הסביבה – משאבי DBA , אנשי סיסטם, מפתחים ו- QA שמוודאים שהסביבה זהה לייצור).
דגשים לגבי הסביבות השונות:
1. סביבת הפיתוח – בגלל שהיא משרתת מפתחים רבים שעובדים על פרוייקטים רבים בו זמנית, מדובר על הסביבה הכי פחות מסודרת.
2. סביבת הפיתוח לטובת unit test – בארגונים שאין סביבה כזו ניתן לבצע unit test על סביבת הבדיקות הכללית.
3. סביבת הבדיקות הכללית – עיקר המשימה היא לוודא שמבחינה פונקציונלית המערכת מבצעת את משימותיה.
4. סביבת ה- Pre-Prod אמורה להיות זהה לגמרי לסביבת הייצור. בה מבצעים קימפול סופי ומוודאים שתהליך ההתקנה עובר חלק כאשר בתום ההתקנה מבצעים בדיקת שפיות כללית. לא מריצים את כל תסריטי הבדיקות אלא מוודאים שהמסכים נפתחים ושפעולות בסיסיות מתקיימות. העיקר בסביבה זו הוא לוודא שאכן תהליך ההתקנה עובד בצורה חלקה. לדוגמה, כאשר העבירו גרסה לסביבת ה- TEST הייתה חסרה הרשאה מסויימת שהעיפה את התוכנית והוסיפו אותה בצורה ידנית – לא כחלק מ- SCRIPT. נקודה זו תתגלה ב- Pre-Prod. כמו כן יש לבדוק שהמערכות מדברות בין עצמן בגרסה החדשה.
במצב אידאלי ארגון אמור להחזיק כמה סביבות פיתוח ואולי כמה סביבות "פיתוח ל- unit test " אבל סביבת בדיקות אחת וסביבת Pre-Prod אחת. אולם בפועל, בגלל שלא רוצים לפגוע בגרסאות שנמצאות בשימוש ולא מצליחים לתאם בין כל הפרוייקטים (שעובדים על מערכות שונות המקושרות ביניהן) ישנם מקרים שבהם יש כמה סביבות בדיקות ואפילו כמה סביבות Pre-Prod !
עדכון הסביבות מתבצע בד"כ פעם בשבוע מבחינת מסדי הנתונים אבל לא מבחינות אחרות (לא מבחינת "אינטגרציה"). יש עדיפות לעדכון הנתונים בסביבת הבדיקות כי סביבת הבדיקות חייבת להכיל את כל הנתונים (ובעיקר סוגי הנתונים) העדכניים – לדוגמה מסוג חדש בשם "סופר פלטינום". סביבת ה- Pre-Prod פחות חייבת להתעדכן מבחינת הנתונים כי מדובר שם על בדיקות "שפיות בלבד". אבל מצד שני סביבת ה- Pre-Prod חייבת להיות מעודכנת ברמה התשתית ("אינטגרציה") – דברים כמו עדכוני patch של windows שהתבצעו בייצור צריכים לעבור גם ל- pre-prod , גרסאות ESB , וכד'. אבל במקרים רבים ארגונים לא מבצעים את העדכונים מייד ולכן ה- pre-prod אינו מעודכן בצורה מלאה.
בגלל הזמן הרב שנדרש ליצירת סביבה ניתן להשתמש במתודולוגיה של fip-flop לבניית סביבת הבדיקות. הבודקים עובדים על סביבה יציבה ובמקביל בונים סביבה חדשה. תהליך זה לוקח כחודש ולאחר ייצוב הסביבה מעבירים את הבודקים לסביבה החדשה ומוחקים את הסביבה הישנה. ואז מתחילים לבנות סביבת בדיקות מעודכנת יותר.
כלים תומכים
מבחינת כלים תומכים:
1. עבור הקוד משתמשים בכלים בשלים של SCM – software configuration management. החל מכלים ממשפחת rational, team system של מיקרוסופט, subversion שהנו open source וישנם רבים אחרים.
2. עבור ריפרוש ה- DBMS – ארגונים רבים פתחו כלים (scripts מתוחכמים) משל עצמם.
3. לשאר המשימות אין שימוש נפוץ בכלים.
מבחינת כלים המאתרים שינוי בין סביבות, אחד הלקוחות סיפר על כלי שפותח בארגון. על ידי פונקציית DIF מוצאים מה השתנה בין קבצים או טבלאות קונפיגורציה. כאשר הבדיקה אינה מתבצעת על כל הסביבה אלא רק על דברים בעייתיים (קבצי קונפיגורציה, מבנה DBMS, סיסמאות, טבלאות קונפיגורציה) אשר בעבר התגלו איתם בעיות.
סוגי הסביבות
סביבות הבדיקה המלאות, באופן תאורטי, צריכות לכלול 4 סוגים:
1. סביבות פיתוח – בבעלות אנשי הפיתוח
2. סביבות פיתוח לטובת unit test – בבעלות אנשי הפיתוח. ישנו צורך לסביבה כזו מכיוון שסביבת הפיתוח משמשת מספר רב של מפתחים הנמצאים בגרסאות שונות של קוד וב"תהליך" כלומר קוד לא סגור ולא פונקציונלי ולכן ביצוע unit test לא ייתן תוצאה אמיתית. "סביבת הפיתוח לטובת unit test" אמורה להכיל רק קוד עובד.
3. סביבות בדיקה – בבעלות ה- QA
4. סביבות Pre-Production – בבעלות התפעול\הייצור
5. סביבות ייצור
אחריות על בניית הסביבות – "צוות סביבות"
צוות "סביבות" הוא הצוות האחראי לבניית הסביבות כאשר אחריות הצוות היא גם תפעולית (כלומר מבצע חלק מהמשימות בעצמו) אבל יותר ניהולית (מזמין שירותים מגופים אחרים בארגון לטובת ייצור הסביבה – משאבי DBA , אנשי סיסטם, מפתחים ו- QA שמוודאים שהסביבה זהה לייצור).
דגשים לגבי הסביבות השונות:
1. סביבת הפיתוח – בגלל שהיא משרתת מפתחים רבים שעובדים על פרוייקטים רבים בו זמנית, מדובר על הסביבה הכי פחות מסודרת.
2. סביבת הפיתוח לטובת unit test – בארגונים שאין סביבה כזו ניתן לבצע unit test על סביבת הבדיקות הכללית.
3. סביבת הבדיקות הכללית – עיקר המשימה היא לוודא שמבחינה פונקציונלית המערכת מבצעת את משימותיה.
4. סביבת ה- Pre-Prod אמורה להיות זהה לגמרי לסביבת הייצור. בה מבצעים קימפול סופי ומוודאים שתהליך ההתקנה עובר חלק כאשר בתום ההתקנה מבצעים בדיקת שפיות כללית. לא מריצים את כל תסריטי הבדיקות אלא מוודאים שהמסכים נפתחים ושפעולות בסיסיות מתקיימות. העיקר בסביבה זו הוא לוודא שאכן תהליך ההתקנה עובד בצורה חלקה. לדוגמה, כאשר העבירו גרסה לסביבת ה- TEST הייתה חסרה הרשאה מסויימת שהעיפה את התוכנית והוסיפו אותה בצורה ידנית – לא כחלק מ- SCRIPT. נקודה זו תתגלה ב- Pre-Prod. כמו כן יש לבדוק שהמערכות מדברות בין עצמן בגרסה החדשה.
במצב אידאלי ארגון אמור להחזיק כמה סביבות פיתוח ואולי כמה סביבות "פיתוח ל- unit test " אבל סביבת בדיקות אחת וסביבת Pre-Prod אחת. אולם בפועל, בגלל שלא רוצים לפגוע בגרסאות שנמצאות בשימוש ולא מצליחים לתאם בין כל הפרוייקטים (שעובדים על מערכות שונות המקושרות ביניהן) ישנם מקרים שבהם יש כמה סביבות בדיקות ואפילו כמה סביבות Pre-Prod !
עדכון הסביבות מתבצע בד"כ פעם בשבוע מבחינת מסדי הנתונים אבל לא מבחינות אחרות (לא מבחינת "אינטגרציה"). יש עדיפות לעדכון הנתונים בסביבת הבדיקות כי סביבת הבדיקות חייבת להכיל את כל הנתונים (ובעיקר סוגי הנתונים) העדכניים – לדוגמה מסוג חדש בשם "סופר פלטינום". סביבת ה- Pre-Prod פחות חייבת להתעדכן מבחינת הנתונים כי מדובר שם על בדיקות "שפיות בלבד". אבל מצד שני סביבת ה- Pre-Prod חייבת להיות מעודכנת ברמה התשתית ("אינטגרציה") – דברים כמו עדכוני patch של windows שהתבצעו בייצור צריכים לעבור גם ל- pre-prod , גרסאות ESB , וכד'. אבל במקרים רבים ארגונים לא מבצעים את העדכונים מייד ולכן ה- pre-prod אינו מעודכן בצורה מלאה.
בגלל הזמן הרב שנדרש ליצירת סביבה ניתן להשתמש במתודולוגיה של fip-flop לבניית סביבת הבדיקות. הבודקים עובדים על סביבה יציבה ובמקביל בונים סביבה חדשה. תהליך זה לוקח כחודש ולאחר ייצוב הסביבה מעבירים את הבודקים לסביבה החדשה ומוחקים את הסביבה הישנה. ואז מתחילים לבנות סביבת בדיקות מעודכנת יותר.
כלים תומכים
מבחינת כלים תומכים:
1. עבור הקוד משתמשים בכלים בשלים של SCM – software configuration management. החל מכלים ממשפחת rational, team system של מיקרוסופט, subversion שהנו open source וישנם רבים אחרים.
2. עבור ריפרוש ה- DBMS – ארגונים רבים פתחו כלים (scripts מתוחכמים) משל עצמם.
3. לשאר המשימות אין שימוש נפוץ בכלים.
מבחינת כלים המאתרים שינוי בין סביבות, אחד הלקוחות סיפר על כלי שפותח בארגון. על ידי פונקציית DIF מוצאים מה השתנה בין קבצים או טבלאות קונפיגורציה. כאשר הבדיקה אינה מתבצעת על כל הסביבה אלא רק על דברים בעייתיים (קבצי קונפיגורציה, מבנה DBMS, סיסמאות, טבלאות קונפיגורציה) אשר בעבר התגלו איתם בעיות.
תגובה 1:
כל הנושא של בדיקות לפני השחרור לייצור מתועד ומפורט בפרק ITIL Release Management , ואימוץ השיטה המתוארת שם מבטיחה איתור של מרבית הבאגים, עד כדי חיסכון של 40% בעלות תפעול ה-IT כולו.
מניסיוני האישי זה עובד נהדר, אבל יש לקחת בחשבון שעלות הקמת Integration test environment היא משמעותית.
בני קמין.
benny@i-til.co.il
הוסף רשומת תגובה