אינטגרציה רציפה – הבדלי גרסאות
תוכן שנמחק תוכן שנוסף
מאין תקציר עריכה |
הרחבה |
||
שורה 1:
{{בעבודה}}
{{ניווט בהנדסת תוכנה}}
ב[[הנדסת תוכנה]], '''Continuous Integration''', בקיצור: '''CI''' ('''קונטיניוס אינטגריישן'''; בעברית: '''אינטגרציה רציפה''' או '''אינטגרציה מתמשכת''') היא שיטת עבודה בה כל סביבות הפיתוח עוברות מיזוג עם מוקד מרכזי משותף (repository או mainline באנגלית), כמה פעמים ביום (ראו: [[ניהול גרסאות]]). שיטת עבודה זו התגבשה לראשונה כחלק מ-[[Extreme Programming]]. המטרה הראשית של CI היא למנוע תקלות [[שילוב מערכות|אינטגרציה]], המכונות לעיתים "integration hell" (גיהנום האינטגרציה - על משקל תקלת תוכנה ידועה אחרת בשם [[DLL hell]]).
במקור CI יועדה לשימוש בשילוב עם [[בדיקות יחידה]] [[אוטומציה|אוטומטיות]] אשר נכתבות כחלק מ[[פיתוח מונחה-בדיקות]]. תחילה הרעיון היה להריץ בדיקות יחידה כדי לוודא שכולן עברו בהצלחה לפני הגשת הקוד החדש למוקד המרכזי (ביצוע commit ל-repository
בנוסף לבדיקות יחידה אוטומטיות, ארגונים אשר עובדים בשיטת ה-CI בדרך כלל משתמשים בשרת הבנייה על מנת ליישם תהליכים ''רציפים'' של [[בקרת איכות]] כללית – יחידות עבודה קטנות המיושמות לעתים קרובות. בנוסף להרצת בדיקות יחידה ובדיקות אינטגרציה, תהליכים כאלה מריצים בדיקות סטטיות ודינמיות נוספות, מודדים את ה[[ביצועי מחשב|ביצועים]], מפיקים דוקומנטציה מ[[קוד מקור|קוד המקור]] ומסייעים בביצוע [[בדיקות תוכנה]] ידניות. המטרה ביישום בקרת איכות רציפה כזאת היא שיפור איכות התוכנה וקיצור זמני האספקה שלה ללקוח (delivery), וזאת באמצעות החלפת השיטה המסורתית של יישום בקרת האיכות ''לאחר'' סיום הפיתוח. זה דומה מאוד לרעיון המקורי של ביצוע אינטגרציות תכופות על מנת להקל על תהליך האינטגרציה, אבל הפעם בהקשר של [[הבטחת איכות]].
במסגרת אותה [[מתודולוגיית פיתוח תוכנה]] נכללת גם שיטת ה-[[continuous delivery]] (אספקה רציפה), אשר מרחיבה את שיטת ה-CI בכך שהיא מוודאת שהתוכנה כפי שהיא נמצאת ב-repository, תמיד נמצאת במצב שניתן לפרוס אותה אצל [[משתמש (מחשבים)|משתמשים]], ובכך הופכת את תהליך [[פריסת תוכנה|פריסת התוכנה]] למהיר ביותר.
== תיאוריה ==
כאשר מתכנת X ניגש להכניס שינויים בקוד, הוא מושך עותק של [[קוד מקור|קוד המקור]] העדכני מה-repository אל תחנת העבודה שלו. ככל שעובר הזמן ומפתחים אחרים מגישים את השינויים שהם ביצעו בקוד אל ה-repository, הקוד שנמצא אצל מתכנת X מפסיק בהדרגה לשקף את הקוד שנמצא ב-repository. לא רק שהקוד שנמצא ב-repository עשוי להשתנות, אלא גם יכולים להתווסף קוד, [[ספרייה (תכנות)|ספריות]] ומשאבים אחרים חדשים אשר יוצרים תלויות (dependencies) וקונפליקטים אפשריים.
ככל שעותק של הקוד (branch) נשאר checked out זמן רב יותר (נמצא בתחנת עבודה מסוימת מבלי שהוא הוגש חזרה ל-repository ביחד עם השינויים שבוצעו בו, או מבלי שנערכה בדיקה ועדכון במידה והוכנסו שינויים בקוד המקור מאז המשיכה האחרונה של הקוד מה-repository), כך עולה הסיכוי להווצרות קונפליקטים ובעיות אינטגרציה מרובות כאשר ינסו לשלב את הקוד הזה חזרה אל תוך ה-repository. כאשר מתכנת בא להגיש את הקוד שלו ל-repository הוא חייב קודם לעדכן את הקוד שנמצא אצלו כך שישקף את השינויים שבוצעו ב-repository מאז שהוא משך לעצמו עותק של הקוד לאחרונה. ככל שה-repository מכיל שינויים רבים יותר, כך תגדל כמות העבודה שהמתכנת יצטרך לעשות לפני שיוכל להגיש את השינויים שהוא עצמו ביצע.
== ראו גם ==
* [[ניהול גרסאות]]
* [[בדיקות יחידה]]
* [[בדיקות אינטגרציה]]
| |||