גירסאות קטנות או גדולות
- פותח הנושא אוגיטוס
- פורסם בתאריך
דעתי
בגדול, יש שלושה פרמטרים שצריך לקחת בחשבון -
1) מצב הלקוחות - האם הלקוחות מוכנים לקבל עדכון כל חמש דקות, או שהם מפחדים משינויים ומעדיפים לקבל עדכון אחת לתקופה ארוכה יותר.
2) מצב התשתיות - כמה זמן לוקח להתקין גרסה על הסביבות השונות, מצב האוטומציה (כולל ניטור של מה קורה במערכת החיה)' מרחק חברתי בין חלקי הצוות ועוד.
3) סבילות לתקלות.
--------------
אם הלקוחות לא מוכנים לקבל עדכון גרסה כל חצי דקה, זה לא באמת משנה, אז נניח שהם מסכימים.
מכאן השאלה היא ברמת התשתיות שיש לך - אם צוות הבדיקות צריך לבצע רגרסיה מלאה לפני שחרור כל גרסה, לעבור לגרסאות קטנות יהיה סיוט. אם לא צריך, אז אפשר ליצור את הגרסאות קטנות עד כמה שבא לנו. בדרך כלל, כדי לצמצם את הצורך ברגרסיה מלאה משתמשים בסט בדיקות אוטומטיות שמכסה איזשהו בסיס ואת השאר משלימים עם בדיקות ספציפיות לשינויים שיש בגרסה.
כאן המחיר המרכזי שמשלמים על החלפת גרסאות מהירה הוא בתמיכה בגרסאות ישנות, ובזמן שלוקח להקים סביבת בדיקות לגרסה חדשה - אם לוקח יומיים רק לעדכן את סביבת הבדיקות, לשחרר גרסה כל שבוע זה כואב (וכל שלושה חודשים זה רק מעצבן).
 
היתרון בגרסאות קטנות, הוא שפחות דברים מתפספסים - קל יותר להתמקד במעט השינויים ולבדוק אותם לעומק. בנוסף, אם התגלה באג, הזמן שיש עד שהוא מתוקן יהיה קצר יותר משמעותית.
 
לסיום, נקודה אחרונה שאני חושב שצריך לקחת בחשבון היא סבילות לתקלות. כשרצים מהר יש פחות זמן לוודא מראש שהחלקים הקריטיים עדיין פועלים. אם המוצר לא יכול להיות למטה אפילו לחמש דקות (כי זו מערכת אלגו-טריידינג שתפסיד הון על כל שנייה שהיא כושלת), כנראה שלא תרצו לעבוד עם continuous delivery. אם המערכת יכולה לספוג זעזוע ויש לה את המנגנונים להתמודד עם נפילות (כי אפשר לשחרר גרסה רק לחלק קטן מהמשתמשים ולהמשיך אחרי שהכל עובד היטב), זה יכול להצליח טוב יותר.
בגדול, יש שלושה פרמטרים שצריך לקחת בחשבון -
1) מצב הלקוחות - האם הלקוחות מוכנים לקבל עדכון כל חמש דקות, או שהם מפחדים משינויים ומעדיפים לקבל עדכון אחת לתקופה ארוכה יותר.
2) מצב התשתיות - כמה זמן לוקח להתקין גרסה על הסביבות השונות, מצב האוטומציה (כולל ניטור של מה קורה במערכת החיה)' מרחק חברתי בין חלקי הצוות ועוד.
3) סבילות לתקלות.
--------------
אם הלקוחות לא מוכנים לקבל עדכון גרסה כל חצי דקה, זה לא באמת משנה, אז נניח שהם מסכימים.
מכאן השאלה היא ברמת התשתיות שיש לך - אם צוות הבדיקות צריך לבצע רגרסיה מלאה לפני שחרור כל גרסה, לעבור לגרסאות קטנות יהיה סיוט. אם לא צריך, אז אפשר ליצור את הגרסאות קטנות עד כמה שבא לנו. בדרך כלל, כדי לצמצם את הצורך ברגרסיה מלאה משתמשים בסט בדיקות אוטומטיות שמכסה איזשהו בסיס ואת השאר משלימים עם בדיקות ספציפיות לשינויים שיש בגרסה.
כאן המחיר המרכזי שמשלמים על החלפת גרסאות מהירה הוא בתמיכה בגרסאות ישנות, ובזמן שלוקח להקים סביבת בדיקות לגרסה חדשה - אם לוקח יומיים רק לעדכן את סביבת הבדיקות, לשחרר גרסה כל שבוע זה כואב (וכל שלושה חודשים זה רק מעצבן).
 
היתרון בגרסאות קטנות, הוא שפחות דברים מתפספסים - קל יותר להתמקד במעט השינויים ולבדוק אותם לעומק. בנוסף, אם התגלה באג, הזמן שיש עד שהוא מתוקן יהיה קצר יותר משמעותית.
 
לסיום, נקודה אחרונה שאני חושב שצריך לקחת בחשבון היא סבילות לתקלות. כשרצים מהר יש פחות זמן לוודא מראש שהחלקים הקריטיים עדיין פועלים. אם המוצר לא יכול להיות למטה אפילו לחמש דקות (כי זו מערכת אלגו-טריידינג שתפסיד הון על כל שנייה שהיא כושלת), כנראה שלא תרצו לעבוד עם continuous delivery. אם המערכת יכולה לספוג זעזוע ויש לה את המנגנונים להתמודד עם נפילות (כי אפשר לשחרר גרסה רק לחלק קטן מהמשתמשים ולהמשיך אחרי שהכל עובד היטב), זה יכול להצליח טוב יותר.
Copyright©1996-2021,Tapuz Media Ltd. Forum software by XenForo® © 2010-2020 XenForo Ltd.