אינטגרציה רציפה – הבדלי גרסאות
תוכן שנמחק תוכן שנוסף
מ ←פתיח: , קישורים פנימיים |
שיפור וויקיזציה של שורת הפתיחה, ועוד. |
||
שורה 1:
{{ניווט בהנדסת תוכנה}}
ב[[הנדסת תוכנה]], '''Continuous integration'''
במקור CI יועדה לשימוש בשילוב עם [[בדיקות יחידה]] [[אוטומציה|אוטומטיות]] אשר נכתבות כחלק מ[[פיתוח מונחה-בדיקות]]. תחילה הרעיון היה להריץ בדיקות יחידה כדי לוודא שכולן עברו בהצלחה לפני הגשת הקוד החדש למוקד המרכזי (ביצוע commit ל-repository). פיתוחים מאוחרים יותר של השיטה הכניסו שימוש ב[[שרת]]י [[בניית תוכנה|בנייה]] (build servers) אשר מריצים אוטומטית בדיקות יחידה מעת לעת או אפילו לאחר כל commit, ומדווחים על תוצאות הבדיקות ל[[מתכנת|מפתחים]]. השימוש בשרתי בנייה (אשר לא בהכרח מריצים בדיקות יחידה) היה בשימוש גם על ידי צוותי פיתוח שאינם עובדים בשיטת ה-extreme programming. כעת הרבה ארגונים אימצו את שיטת ה-CI מבלי לאמץ את כל יתר השיטות של XP.
בנוסף לבדיקות יחידה אוטומטיות, ארגונים אשר עובדים בשיטת ה-CI בדרך כלל משתמשים בשרת הבנייה על מנת ליישם תהליכים ''רציפים'' של [[בקרת איכות]] כללית – יחידות עבודה קטנות המיושמות לעתים קרובות. בנוסף להרצת בדיקות יחידה ובדיקות אינטגרציה, תהליכים כאלה מריצים בדיקות סטטיות ודינמיות נוספות, מודדים את ה[[ביצועי מחשב|ביצועים]], מפיקים [[הנדסת תוכנה#תיעוד|דוקומנטציה]] מ[[קוד מקור|קוד המקור]] ומסייעים בביצוע [[בדיקות תוכנה]] ידניות. המטרה ביישום בקרת איכות רציפה כזאת היא שיפור איכות התוכנה וקיצור זמני האספקה שלה ללקוח (delivery), וזאת באמצעות החלפת השיטה המסורתית של יישום בקרת האיכות ''לאחר'' סיום הפיתוח. זה דומה מאוד לרעיון המקורי של ביצוע אינטגרציות תכופות על מנת להקל על תהליך האינטגרציה, אבל הפעם בהקשר של [[הבטחת איכות]].
במסגרת אותה [[מתודולוגיית פיתוח תוכנה]] נכללת גם שיטת ה-[[continuous delivery]] (אספקה רציפה), אשר מרחיבה את שיטת ה-CI בכך שהיא מוודאת שהתוכנה כפי שהיא נמצאת ב-repository, תמיד נמצאת במצב שניתן לפרוס אותה אצל [[משתמש (
== תאוריה ==
כאשר [[מתכנת]] X ניגש להכניס שינויים בקוד, הוא מושך עותק של [[קוד מקור|קוד המקור]] העדכני מה-repository אל תחנת העבודה שלו. ככל שעובר הזמן ומפתחים אחרים מגישים את השינויים שהם ביצעו בקוד אל ה-repository, הקוד שנמצא אצל מתכנת X מפסיק בהדרגה לשקף את הקוד שנמצא ב-repository. לא רק שהקוד שנמצא ב-repository עשוי להשתנות, אלא גם יכולים להתווסף קוד, [[ספרייה (תכנות)|ספריות]] ומשאבים אחרים חדשים אשר יוצרים תלויות (dependencies) וקונפליקטים אפשריים.
ככל
בסופו של דבר ה-repository יכול להפוך לכל כך שונה מהעותק שנמצא אצל המפתח, עד שיווצר המצב שלעתים מכונה "merge hell" או "integration hell" ("גיהנום המיזוג" או "גיהנום האינטגרציה"), בו הזמן הנדרש לצורך ביצוע אינטגרציה עולה על הזמן שלקח לעשות את השינויים המקוריים. במקרה הגרוע ביותר, יכול להיות שהמפתח יאלץ לזרוק את השינויים שהוא ביצע ולעשות את כל העבודה מחדש.
עבודה בשיטת ה-continuous integration דואגת לבצע אינטגרציות מוקדמות ותכופות על מנת להימנע ממלכודות ה-integration hell. מטרת השיטה להפחית את כמות העבודה שיש לבצע מחדש (שכתוב הקוד על מנת להתאים אותו לשינויים שמפתחים אחרים עשו), ובכך להקטין את העלויות והזמן שנדרש לפיתוח.
|