‏04/2017

Continuous Integration (CI) With Gerrit/Git/Jenkins

מאת: דמי גולדברג -  DevOps Expert

הפעם נדבר על תהליך CI בעזרת 3 כלים, 2 מהם מאד מוכרים למי שנמצא בעולם ה- DEVOPS/CM/ALM, אלו  כלי Open-Source שהפכו לכמעט סטנדרט בתעשייה, במיוחד בחברות סטארט-אפ ובחברות בינוניות עד גדולות. כמובן שמדובר בכלים Git  ו-Jenkins.

במאמר זה אתרכז בכלי השלישי ברשימה – Gerrit, שגם הוא ניתן לשימוש והטמעה ללא עלות.

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

CI (Continuous Integration) ובעברית "אינטגרציה רציפה", היא שיטת עבודה שהתגבשה כחלק מתמיכה במתודולוגיות פיתוח זריזות (Agile), כאשר המטרה היא להגיע לסביבות הייצור (production) בצורה מהירה ובאופן רציף (שמוביל ל צמצום ה- Time to Market).

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

המטרה היא להריץ תהליך בניית מוצר אוטומטי על הענף הראשי של המוצר על כל שינוי (או כמעט כל שינוי- תלוי בארגון) שנכנס לענף ,כאשר התהליך כולל כל מה שאפשר להריץ אוטומטית כדי לבנות את המוצר ולקבל תוצר הכי איכותי בסוף התהליך. בדרך כלל התהליך כולל קומפילציה ,בדיקות יחידה (Unit Test), ניתוח קוד סטטי (Code Analysis), בדיקות ביצועים, הפקת דוחות, תהליך אריזה (או פריסה בסביבת ריצה, זה השלב הבא אחרי  CI ונקרא כבר Continuous Delivery  CD=), עד לקבלת תוצר שניתן לשימוש (או סביבה עובדת).

כדי להגיע למטרה זו נכנסים לתמונה הכליםGit  ו-Jenkins כאשר Git מאפשר ניהול קוד (גרסאות, ענפי פיתוח, תגים וכד') ו-Jenkins משמש ככלי ש"מנצח" על כל המשימות עד לקבלת התוצר.

במרכז התהליך הנ"ל נכנס כלי נוסף בשם Gerrit שמביא עמו 2 תכונות חשובות שמשתלבות בתהליך ה- CI, ומאפשרות קבלת מוצר יותר איכותי בסוף התהליך:

·         סקר קוד – Code Review

·         מיזוג מאוחר לאחר ווידוא של בניה והרצת בדיקות -  Pre-Tested or Delayed Commits

שרת ה- Gerrit משמש את הפיתוח כשרת הGit- המרכזי, המקום שמרכז את הפרויקטים השונים , את הענפים הראשיים של הפיתוח וגם מאפשר ניהול מרכזי כמו הרשאות לפרויקטים, לענפים, ולפעילויות השונות, קרי, למי מותר מה.

מתודולוגית העבודה ב- Gerrit

כל מפתח שמסיים את עבודתו ב-Git המקומי, מעביר את השינויים לשרת הראשי (Push) ובשלב הזה Gerrit מעביר את השינוי (שהגיע מהמפתח) לענף צדדי שמחכה לסקר קוד של שאר המפתחים ו\או הראש צוות – שיכולים להגיב בהערות על השינוי ולתת ציון חיובי או שלילי   +/- 1/ 2 .

במקביל, באמצעות Jenkins, מתחיל לרוץ תהליך בנייה שמוודא שהשינוי של המפתח לא "שובר" את הקוד , וכל זה עוד לפני שהשינוי נכנס לענף הראשי.

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

במידה והשינוי "נכשל" – השינוי יכול להדחה לתמיד (Abandon) או חוזר בחזרה למפתח לתיקון בהתאם להערות שקיבל.

כמובן שהכול מתנהל לפי ההרשאות של המערכת שניתנות לשינוי בהתאם לקבוצת הפיתוח.

Gerrit - תרשים כללי

  

  

כדי להבין טוב יותר את תהליך העבודה הקלאסי עם Gerrit נעיין בשרטוט הבא:

1.      מפתח דוחף שינויים ל-Gerrit.

2.      Gerrit מיידע את הסוקרים (Code Reviewers) שקיים שינוי חדש.

3.      הסוקרים מתחילים לעבור על הקוד, מוסיפים הערות ונותנים ציון \-+1 או \-+2 לפי הרשאות.

כאשר +2 בדרך כלל ניתן על ידי הראש צוות ומאפשר מיזוג לענף הראשי וציונים -1 או -2

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

4.      במקביל מתבצע תהליך בניה שבסופו יש ציון אוטומטי של +1 עבר או -1 נכשל.

5.      במידה והשינוי אושר (ציון סקר חיובי ו-תהליך בניה עבר) יכנס השינוי לענף.

6.      במידה ולא אושר – יחזור לתיקון של המפתח או מישהו אחר מהצוות או ידחה לגמרי.

ניתן להסתכל על תרשים נוסף שמפשט את התהליך :

Verified - ציון +1 מסמן ש Jenkins העביר את תהליך הבניה בהצלחה, ו- 1- התהליך נכשל.

Reviewed +2 מסמן שסקר הקוד עבר בהצלחה ומוכן למיזוג לענף.

כמובן כמו שציינתי – כל תהליך מתן הציונים 1 או 2 והדחיפה לענף זה עניין של הרשאות וניתן לשינוי.

תהליך התקנה והטמעת Gerrit:

הכלי Gerrit כמו שציינתי הוא open source  וניתן לשימוש בארגון ללא עלות )מומלץ תמיד לעבור על הרישיון שימוש למרות שלא כל כלי שהוא open source זה חופשי לשימוש כמו שחושבים ...)

תהליך ההתקנה – לא ארחיב במאמר זה על תהליך ההתקנה, ניתן למצוא את כל הפרטים באתר  https://www.gerritcodereview.com/

רק אציין שנדרשת מכונה ייעודית (רצוי) עם מספיק מקום להחזיק את הקוד מקור של החברה, נדרש java  בגרסה רלוונטית ומתאימה לגרסת ה- gerrit  שבחרתם להשתמש, ובסיס נתונים – אני ממליץ על MySQL  או PostgreSQL .

Gerrit  - מאפשר אינטגרציה עם LDAP  כך שאם יש לכם מערכת Active Directory , או כל מערכת אחרת תומכת LDAP, ניתן לנהל את תהליך הכניסה והזיהוי ((login וכל ההרשאות השונות בקבוצות ומשתמשים שמגיעים מה- LDAP.

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

לינק לפלאג אין:

https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Trigger

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

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

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

כמו בכל תהליך הטמעה של מוצר, ההמלצה היא להגדיר את זה ההטמעה כפרויקט (גם אם זה פרויקט קצר) שינוהל ויובל ע"י גורם מקצועי (פנים או חוץ ארגוני) בתמיכה של ההנהלה (מנהל פיתוח, ראשי צוותים וכד').

לפני התחלת התהליך על הארגון לקבוע כיצד הוא רוצה לעבוד, מי הגורמים הרלוונטיים בכל שלב בתהליך, מי מורשה להיות סוקר קוד? מי מורשה לדחוף קוד למערכת? האם רק הראש צוות? מי האינטגרטור? ומי מנהל המערכת בפועל  (Administrator) שינהל הרשאות ויפתור בעיות טכניות שצריך?

יתרונות \ חסרונות – סיכום

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

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

חסרון נוסף (שהוא גם יתרון מבחינת עלות) - Gerrit הוא Open Source  ואין לו ממש "אבא ואמא" כלומר במידה ויתגלה באג תצטרכו להתמודד עם פורומים שונים ומשונים ופתרונות יצירתיים אחרים, אבל אתם כבר מורגלים לעולם ה-Open Source  כך שהתמודדות כזאת לא אמורה להיות לכם זרה 😊.

מה שבטוח – היתרונות בשימוש ב- Gerrit עולים במספר מידות על החסרונות,  ומבטיחים תהליך פיתוח אמין ואיכותי יותר.

בהצלחה,

דמי גולדברג

Demi.goldberg@gmail.com