אינטגרציה רציפה – הבדלי גרסאות

תוכן שנמחק תוכן שנוסף
תיקון שם תבנית
אין תקציר עריכה
שורה 1:
{{הנדסת תוכנה}}
ב[[הנדסת תוכנה]], '''Continuous integration''' ([[ראשי תיבות]]: '''CI'''; ב[[עברית]]: '''שילוב/מיזוג רציף''' או '''שילוב/מיזוג מתמשך''') היא שיטת עבודה בה כל [[סביבת פיתוח משולבת|סביבות הפיתוח]] עוברות מיזוג עם מוקד מרכזי משותף (ב[[אנגלית]]: repository או mainline) כמה פעמים ביום (ראו: [[ניהול גרסאות]]). שיטת עבודה זו התגבשה לראשונה כחלק ממתודולגית [[Extreme Programming]]. המטרה הראשית של CI היא למנוע תקלות [[שילוב מערכות|אינטגרציה]], המכונות לעתים "integration hell" ("גיהנום האינטגרציה"; על משקל [[תקלת תוכנה]] ידועה אחרת בשם [[DLL hell]]).
 
בשיטה המסורתית מפתחים שונים עובדים על תכונות שונות של המוצר ולקראת הוצאת גרסה חדשה ממזגים את כל השינויים. רק אז אפשר לבדוק איך כל השינויים השונים משפיעים האחד על השני. בשיטת המיזוג הרציף, ענף הפיתוח הראשי מייצג תמיד מוצר עובד (לדוגמה: שעובר את כל הבדיקות).
 
במקור CI יועדה לשימוש בשילוב עם [[בדיקות יחידה]] [[אוטומציה|אוטומטיות]] אשר נכתבות כחלק מ[[פיתוח מונחה-בדיקות]]. תחילה הרעיון היה להריץ בדיקות יחידה כדי לוודא שכולן עברו בהצלחה לפני הגשת הקוד החדש למוקד המרכזי (ביצוע commit ל-repository). פיתוחים מאוחרים יותר של השיטה הכניסו שימוש ב[[שרת]]י [[בניית תוכנה|בנייה]] (build servers) אשר מריצים אוטומטית בדיקות יחידה מעת לעת או אפילו לאחר כל commit, ומדווחים על תוצאות הבדיקות ל[[מתכנת|מפתחים]]. השימוש בשרתי בנייה (אשר לא בהכרח מריצים בדיקות יחידה) היה בשימוש גם על ידי צוותי פיתוח שאינם עובדים בשיטת ה-extreme programming. כעת הרבה ארגונים אימצו את שיטת ה-CI מבלי לאמץ את כל יתר השיטות של XP.