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