משתמש:AdirPisti/שילוב מתמשך
שילוב מתמשך בהנדסת תוכנה, מיישם תהליכים מתמשכים של בקרת איכות - חלקים קטנים של מאמץ המיושמים בתכיפות.
שילוב מתמשך שואף לשפר את איכות התוכנה ולצמצם את הזמן הדרוש לשחרורה על ידי החלפת הנוהג הרגיל של בקרת איכות רק לאחר שכל הפיתוח הושלם.
נהגים מומלצים[עריכת קוד מקור | עריכה]
- תחזוק מאגר קוד (Repository).
- למכן את תהליך בניית הקוד (Build).
- לגרום לתהליך בניית הקוד לבדוק את עצמו, כלומר להריץ בדיקות לאחר ה-Build.
- כל יום, כולם מגישים את הקוד אותו כתבו (Commit).
- כל שינוי בבסיס המערכת מחייב Build.
- לשמור על Build מהיר, לצורך אבחון תקלות מהיר.
- לבדוק את התוכנה בסביבה המדמה את סביבת הייצור.
- להקל על כל המעורבים בעניין להשיג את התוצר בכל שלב של תהליך הפיתוח.
- כולם יכולים לצפות בתוצאות ה-Build האחרון.
- פריסה אוטומטית לאחר ה-Build, כלומר העלאת היישום לשרת בדיקה חי כך שכולם יוכלו לבחון אותו. קידום נוסף בצורת חשיבה זו הוא פריסה מתמשכת (Countinuous Deployment), שבה התוכנה נפרסת ישירות לייצור לעיתים קרובות על ידי אוטומציה נוספת כדי להימנע מפגמים ונסיגות[1].
היסטוריה[עריכת קוד מקור | עריכה]
שילוב מתמשך עלה בקהילת ה-Extreme Programming וחסידי ה-XP מרטין פולר וקנט בק כתבו על שילוב מתמשך בשנת 1999. מאמרו של פולר וספרו של בק "Extreme Programming Explained" הינם מקורות מידע אהודים על הנושא ומתארים את המונח.
יתרונות[עריכת קוד מקור | עריכה]
- כאשר בדיקות יחידה נכשלות או שנמצא באג, המפתחים עשויים לחזור למצב קודם של מאגר הקוד שבו לא היו באגים מבלי לבזבז זמן על איתור באגים.
- המפתחים מגלים ומתקנים בעיות שילוב באופן מתמשך ועל ידי כך נמנעים מאי-סדר של הרגע האחרון בתאריכי שחרור גרסאות.
- התראה מוקדמת לגבי קוד שבור / לא מתאים.
- התראה מוקדמת לגבי שינויים סותרים.
- בדיקת יחידה מידית של כל השינויים.
- זמינות תמידית של המוצר למטרות בדיקה, גרסת הדגמה או שחרור.
- משוב מיידי למפתחים על איכות, שימושיות או השפעת הקוד שלהם על כלל המערכת.
- הגשת קוד תכופה מניעה מפתחים ליצור קוד מודולרי, שימושי, איכותי ופחות תלותי.
חסרונות[עריכת קוד מקור | עריכה]
- מצריך הקמת תשתיות בהתחלה.
- על מנת להשיג את יתרונות הבדיקה הממוכנת, נדרשת חבילת בדיקות הבנויה היטב.
- ארגון מחדש של הקוד הנדרש (Refactoring) בקנה מידה גדול, יכול להיות בעייתי בשל שינויים מתמשכים בבסיס הקוד.
- עלות חומרה עבור מכונות שמבצעות את בניית הקוד עלולה להיות משמעותית.
צוותים רבים המשתמשים בשילוב מתמשך מדווחים כי יתרונותיו עולים בהרבה על חסרונותיו[2]. התוצאה של מציאת ותיקון תקלות שילוב, בשלב מוקדם בתהליך הפיתוח חוסכת כסף וזמן לאורך מחזור החיים של פרויקט.
ראו גם[עריכת קוד מקור | עריכה]
התייחסות[עריכת קוד מקור | עריכה]
- ^ See http://radar.oreilly.com/2009/03/continuous-deployment-5-eas.html and http://timothyfitz.wordpress.com/2009/02/10/continuous-deployment-at-imvu-doing-the-impossible-fifty-times-a-day/
- ^ See http://www.nofluffjuststuff.com "Agile Testing Strategies at No Fluff Just Stuff Conference", Boston, Massachusetts September 2008
קישורים חיצוניים[עריכת קוד מקור | עריכה]
- Build Automation, מאתר Wikipedia באנגלית.