מהו CI / CD? מוסבר שילוב מתמשך ומסירה רציפה

שילוב רציף (CI) ומסירה רציפה (CD) מגלמים תרבות, מערך עקרונות הפעלה ואוסף שיטות המאפשרות לצוותי פיתוח אפליקציות להעביר שינויי קוד בתדירות ובאמינות רבה יותר. היישום מכונה גם צינור ה- CI / CD

CI / CD הוא אחד השיטות הטובות ביותר ליישום צוותי devops. זוהי גם שיטה מומלצת של מתודולוגיה זריזה, מכיוון שהיא מאפשרת לצוותי פיתוח תוכנה להתמקד בעמידה בדרישות העסקיות, באיכות הקוד ובאבטחה מכיוון ששלבי הפריסה הם אוטומטיים.

מוגדר CI / CD

שילוב רציף  הוא פילוסופית קידוד ומכלול שיטות המניעות את צוותי הפיתוח ליישם שינויים קטנים ולבדוק קוד במאגרים לבקרת גרסאות לעיתים קרובות. מכיוון שרוב היישומים המודרניים דורשים פיתוח קוד בפלטפורמות ובכלים שונים, הצוות זקוק למנגנון לשילוב ואימות השינויים שלו.

המטרה הטכנית של CI היא ליצור דרך עקבית ואוטומטית לבנות, לארוז ולבדוק יישומים. עם עקביות בתהליך האינטגרציה, צוותים נוטים יותר לבצע שינויי קוד בתדירות גבוהה יותר, מה שמוביל לשיתוף פעולה ואיכות תוכנה טובים יותר.

אספקה ​​רציפה  מרימה היכן שמסתיימת שילוב מתמשך. CD הופך אוטומטית את מסירת היישומים לסביבות תשתית נבחרות. רוב הצוותים עובדים עם מספר סביבות פרט לייצור, כמו סביבות פיתוח ובדיקה, ו- CD מבטיח שיש דרך אוטומטית לדחוף אליהם שינויי קוד.

כלי CI / CD עוזרים לאחסן את הפרמטרים הספציפיים שיש לארוז עם כל מסירה. לאחר מכן אוטומציה של CI / CD מבצעת את כל קריאות השירות הדרושות לשרתי אינטרנט, בסיסי נתונים ושירותים אחרים שייתכן שיהיה צורך להפעילם מחדש או לעקוב אחר נהלים אחרים בעת פריסת יישומים.

שילוב מתמשך ומסירה רציפה דורשים  בדיקות רציפות  מכיוון שהמטרה היא לספק יישומים וקוד איכותי למשתמשים. בדיקות רציפות מיושמות לרוב כמערכת של רגרסיה אוטומטית, ביצועים ובדיקות אחרות שמבוצעות בצינור ה- CI / CD.

פרקטיקה בוגרת של סי / תקליטור בוגרת יש אפשרות ליישם פריסה רציפה כאשר שינויים ביישומים עוברים דרך צינור ה- CI / CD והעברות של בנייה נפרסות ישירות לסביבות ייצור. צוותים העוסקים במסירה רציפה בוחרים לפרוס לייצור על פי לוח זמנים יומי או אפילו לפי שעה, אם כי אספקה ​​רציפה אינה תמיד מיטבית לכל יישום עסקי.  

סרטון קשור: כיצד לספק קוד מהר יותר עם CI / CD

כיצד שילוב מתמשך משפר את שיתוף הפעולה והאיכות

אינטגרציה רציפה היא פילוסופיית פיתוח המגובה על ידי מכניקת תהליכים ואוטומציה מסוימת. כאשר מתרגלים CI, מפתחים מחייבים את הקוד שלהם למאגר בקרת הגרסאות לעיתים קרובות ולרוב הצוותים יש סטנדרט מינימלי של ביצוע קוד לפחות מדי יום. הרציונל שעומד מאחורי זה הוא שקל יותר לזהות פגמים ובעיות איכות תוכנה אחרות בהפרשי קוד קטנים יותר מאשר גדולים יותר שפותחו לאורך תקופות נרחבות. בנוסף, כאשר מפתחים עובדים על מחזורי התחייבות קצרים יותר, יש פחות סיכוי שמפתחים מרובים עורכים את אותו קוד ודורשים מיזוג בעת ביצוע ההתחייבות.

צוותים המיישמים אינטגרציה רציפה מתחילים לעיתים קרובות עם תצורת בקרת גרסאות והגדרות תרגול. למרות שבדיקת הקוד מתבצעת בתדירות גבוהה, תכונות ותיקונים מיושמים בטווחי זמן קצרים וארוכים יותר. צוותי פיתוח המתאמנים באינטגרציה רציפה משתמשים בטכניקות שונות כדי לשלוט באילו תכונות וקוד מוכנים לייצור.

צוותים רבים משתמשים בדגלי תכונות , מנגנון תצורה להפעלת או כיבוי תכונות וקוד בזמן הריצה. תכונות שנמצאות עדיין בפיתוח עטופות בדגלי תכונה בקוד, נפרסות עם סניף המאסטר לייצור ונכבות עד שהן מוכנות לשימוש. על פי סקר שנערך לאחרונה, 63 אחוז מהצוותים המשתמשים בדגלי תכונה מדווחים על בדיקות טובות יותר ותוכנות באיכות גבוהה יותר. כלים לסימון תכונות כגון הפעלת CloudBees, הפעלות מיטביות ו- LaunchDarkly משתלבים בכלי CI / CD ומאפשרים תצורות ברמת התכונות.

טכניקה נוספת לניהול תכונות היא  הסתעפות בקרת גרסאות . נבחרה אסטרטגיית הסתעפות כמו Gitflow להגדרת פרוטוקולים על האופן שבו קוד חדש מוזג לענפים סטנדרטיים לפיתוח, בדיקה וייצור. נוצרים ענפי תכונות נוספים עבור אלה שייקחו מחזורי פיתוח ארוכים יותר. לאחר השלמת התכונה, היזמים יכולים למזג את השינויים מענפי התכונות לענף הפיתוח העיקרי. גישה זו עובדת היטב, אך היא עלולה להיות קשה לניהול אם ישנם תכונות רבות המפותחות במקביל.

תהליך הבנייה עצמו אוטומטי על ידי אריזה של כל התוכנות, מסד הנתונים ורכיבים אחרים. לדוגמה, אם היית מפתח יישום Java, CI היה אורז את כל קבצי שרת האינטרנט הסטטיים כגון HTML, CSS ו- JavaScript יחד עם יישום Java וכל סקריפטים של מסדי נתונים.

CI לא רק מארז את כל רכיבי התוכנה ומסד הנתונים, אלא שהאוטומציה תבצע גם בדיקות יחידה ובדיקות אחרות. בדיקה זו מספקת משוב למפתחים כי שינויים בקוד שלהם לא שברו בדיקות יחידה קיימות.

מרבית כלי ה- CI / CD מאפשרים למפתחים להתחיל בבנייה לפי דרישה, המופעלת על ידי התחייבות קוד במאגר בקרת הגרסאות, או בתזמון מוגדר. צוותים צריכים לדון בלוח הזמנים המתאים ביותר לגודל הצוות, מספר ההתחייבויות היומיות הצפויות ושיקולי יישום אחרים. שיטה מומלצת להבטיח שהתחייבויות ובניות מהירות, אחרת היא עשויה לעכב את התקדמות הצוותים המנסים לקודד במהירות ולהתחייב בתדירות גבוהה.

בדיקות רציפות חורגות ממיכון המבחנים

מסגרות בדיקות אוטומטיות מסייעות למהנדסי אבטחת איכות להגדיר, לבצע ולבצע אוטומציה של סוגים שונים של בדיקות שיכולות לעזור לצוותי הפיתוח לדעת אם בניית תוכנה עוברת או נכשלת. הם כוללים מבחני פונקציונליות שפותחו בסוף כל ספרינט ומצטברים למבחן רגרסיה לכל היישום. בדיקות רגרסיה אלה מודיעות לצוות אם שינוי קוד נכשל באחת או יותר מהבדיקות שפותחו בכל האזורים הפונקציונליים של היישום שבהם יש כיסוי בדיקה.

שיטה מומלצת היא לאפשר ולדרוש ממפתחים להריץ את כל או תת-קבוצות של מבחני הרגרסיה בסביבתם המקומית. שלב זה מבטיח שמפתחים יבצעו קוד לבקרת גרסאות רק לאחר שמבחני הרגרסיה מעבירים את שינויי הקוד.

מבחני רגרסיה הם רק ההתחלה. ניתן לבצע אוטומטיות גם בדיקות ביצועים, בדיקות API, ניתוח קוד סטטי, בדיקות אבטחה וטופסי בדיקה אחרים. המפתח הוא להיות מסוגל להפעיל בדיקות אלה באמצעות שורת פקודה, ווה-ווק או שירות אינטרנט וכי הם מגיבים בקודי מצב בהצלחה או נכשלים.

לאחר בדיקה אוטומטית, בדיקה רציפה מרמזת כי האוטומציה משולבת בצינור ה- CI / CD. ניתן לשלב חלק ממבחני היחידות והפונקציונליות ב- CI המסמנים בעיות לפני או במהלך תהליך האינטגרציה. בדיקות הדורשות סביבת מסירה מלאה כגון ביצועים ובדיקות אבטחה משולבות לרוב בתקליטור ומבוצעות לאחר העברת מבנים לסביבות היעד.

צינור התקליטורים מבצע אוטומציה של שינויים בסביבות מרובות

מסירה רציפה היא האוטומציה הדוחפת יישומים לסביבות משלוח. לרוב צוותי הפיתוח קיימת סביבת פיתוח ובדיקה אחת או יותר בהן נערכים שינויים ביישומים לבדיקה ולבדיקה. כלי CI / CD כגון Jenkins, CircleCI, AWS CodeBuild, Azure DevOps, Atlassian Bamboo או Travis CI משמש לאוטומציה של השלבים ולספק דיווח.

צינור תקליטורים טיפוסי כולל שלבי בנייה, בדיקה ופריסה. צינורות מתוחכמים יותר כוללים רבים מהשלבים הבאים:

  • משיכת קוד מבקרת גרסה וביצוע build.
  • ביצוע כל שלבי התשתית הנדרשים אוטומטיים כקוד לעמידה או פירוק תשתיות ענן.
  • העברת קוד לסביבת מחשוב היעד.
  • ניהול משתני הסביבה והגדרת התצורה שלהם לסביבת היעד.
  • דוחף רכיבי יישומים לשירותים המתאימים שלהם, כגון שרתי אינטרנט, שירותי API ושירותי מסדי נתונים.
  • ביצוע כל הצעדים הנדרשים להפעלת שירותים מחדש או נקודות קצה של שירות להתקשרות הדרושות לדחיפות קוד חדשות.
  • ביצוע בדיקות רציפות וסביבות החזרה אם בדיקות נכשלות.
  • מתן נתוני יומן והתראות על מצב המסירה.

כדוגמה, משתמשי Jenkins מגדירים את הצינורות שלהם בקובץ Jenkins שמתאר שלבים שונים כגון בנייה, בדיקה ופריסה. משתני סביבה, אפשרויות, מפתחות סודיים, אישורים ופרמטרים אחרים מוצהרים בקובץ ואז מתייחסים אליהם בשלבים. מדור ההודעה מטפל בתנאי שגיאה ובהודעות.  

תקליטור משוכלל יותר עשוי לכלול צעדים אחרים כגון ביצוע סנכרון נתונים, אחסון משאבי מידע או ביצוע תיקון יישומים וספריות. כלי CI / CD תומכים בדרך כלל בשוק של תוספים. לדוגמא, ג'נקינס מפרט יותר מ -1,500 תוספים התומכים באינטגרציה עם פלטפורמות של צד שלישי, ממשק משתמש, ניהול, ניהול קוד מקור וניהול בנייה.

לאחר שנבחר כלי CI / CD, צוותי הפיתוח חייבים לוודא שכל משתני הסביבה מוגדרים מחוץ ליישום. כלי CI / CD מאפשרים הגדרת משתנים אלה, מיסוך משתנים כגון סיסמאות ומפתחות חשבון, וקביעת התצורה שלהם בזמן הפריסה לסביבת היעד.

כלי תקליטור מספקים גם פונקציות לוח מחוונים ודיווח. אם מבנים או מסירות נכשלים, הם מתריעים למפתחים עם מידע על הכשלים. הם משתלבים עם בקרת גרסאות וכלים זריזים, כך שניתן להשתמש בהם בכדי לחפש אילו שינויים בקוד וסיפורי משתמשים היוו מבנה.

יישום צינורות CI / CD עם Kubernetes וארכיטקטורות ללא שרת 

צוותים רבים המפעילים צינורות CI / CD בסביבות ענן משתמשים גם במיכלים כמו Docker ומערכות תזמורת כגון Kubernetes. מיכלים מאפשרים אפליקציות אריזה ומשלוח בדרכים ניידות סטנדרטיות. מכולות מקלות על הגדלה או פירוק של סביבות בעלות עומסי עבודה משתנים.

ישנן גישות רבות לשימוש במכולות, בתשתית כקוד ובצינורות CI / CD יחד. אתה יכול לבחון את האפשרויות על ידי עבודה באמצעות מדריכים כגון Kubernetes עם Jenkins או Kubernetes עם Azure DevOps.

ארכיטקטורות מחשוב ללא שרתים מציגות דרך נוספת לפריסה ולשינוי גודל היישומים. בסביבה ללא שרתים, התשתית מנוהלת באופן מלא על ידי ספק שירותי הענן והיישום צורך משאבים לפי הצורך בהתבסס על תצורתו. ב- AWS למשל, ניתן לשלב יישומים ללא שרתים כפונקציות Lambda ופריסות בצינור Jenkins CI / CD עם תוסף. 

CI / CD מאפשר פריסות קוד תכופות יותר

לסיכום, חבילות CI ובודקות תוכנה בונה ומתריעה למפתחים אם השינויים שלהם נכשלו בבדיקות יחידה כלשהן. CD הוא האוטומציה המספקת שינויים בתשתית ומבצעת בדיקות נוספות. 

צינורות CI / CD מיועדים לעסקים שרוצים לשפר יישומים בתדירות גבוהה ודורשים תהליך אספקה ​​אמין. המאמץ הנוסף לתקן סטנדרטים של בנייה, פיתוח בדיקות ואוטומציה של פריסות הוא תהליך הייצור לפריסת שינויי קוד. ברגע שהוא במקום, הוא מאפשר לצוותים להתמקד בתהליך שיפור היישומים ופחות בפרטי המערכת של מסירתם לסביבות מחשוב.

CI / CD הוא שיטה מומלצת של devops כיוון שהיא מטפלת בחוסר התאמה בין מפתחים שרוצים לדחוף שינויים לעתים קרובות, עם פעולות שרוצות יישומים יציבים. עם אוטומציה במקום, מפתחים יכולים לדחוף שינויים בתדירות גבוהה יותר. צוותי תפעול רואים יציבות רבה יותר מכיוון שלסביבות יש תצורות סטנדרטיות, ישנן בדיקות מתמשכות בתהליך המסירה, משתני הסביבה מופרדים מהיישום ונהלי ההחזרה הם אוטומטיים.

ניתן למדוד את ההשפעה של יישום צינורות CI / CD כמדד ביצועי מפתח של devops (KPI). KPI כגון תדירות הפריסה, שינוי זמן ההובלה וממוצע זמן להתאוששות (MTTR) מאירוע משופרים לעיתים קרובות כאשר מיושם CI / CD עם בדיקה רציפה. עם זאת, CI / CD הוא רק תהליך אחד שיכול להניע שיפורים אלה, ויש תנאים מוקדמים אחרים לשיפור תדרי הפריסה.

תחילת העבודה עם CI / CD מחייבת צוותי פיתוח וצוותים תפעוליים לשתף פעולה בטכנולוגיות, פרקטיקות וסדרי עדיפויות. צוותים צריכים לפתח הסכמה לגבי הגישות הנכונות לעסקים והטכנולוגיות שלהם, כך שברגע ש- CI / CD יהיה במקום, הצוות נמצא על סיפון הפעולות הבאות באופן עקבי.