כדאי להכיר: הרביעיה הקלאסית למפתחי תוכנה
במסגרת תפקידי אני משוחח לא מעט עם מנהלי פיתוח, מנהלי פרוייקטים, ראשי צוותים ומפתחי תוכנה.
אחת המגמות שאני רואה בשנה-שנתיים האחרונות היא ההבנה (מצד המנהלים והמפתחים) שמפתחי תוכנה צריכים לעשות שימוש יומיומי ב- 4 הכלים הבאים (המממשים תהליכי פיתוח):
Version Control, Issue Tracking, Code Review, Continuous Integration
לא מזמן התחלנו לקרוא לזה אצלנו בחברה בשם "הרביעיה הקלאסית", משום שאנו רואים שההבנה שצריך את כל הרביעיה הנ"ל נמצאת כמעט בכל חברה המפתחת תוכנה – בין אם זה סטרטאפ ובין אם זו חברת ענק. וההבנה הזו משותפת לכל סוגי החברות (בין אם זה תוכנה לבנקים / לחברה בטחונית / לחברה במכשור רפואי / ad-tech וכו')
הצורך וההבנה שהרביעיה הזו נדרשת, נובע בין השאר מהדרישה הגוברת היום מהמפתחים – לדלבר מהר יותר ובאיכות גבוהה יותר. שימוש ב-4 סוגי הכלים האלה (בהנחה והם מממשים תהליך פיתוח בריא כמובן) תורם למסירת תוכנה מהירה יותר ולשיתוף פעולה טוב יותר (ומהיר יותר) בין כל המפתחים, ולמעשה גם תורם לתקשורת טובה יותר מול המשתתפים בפיתוח התוכנה (מנהלים, בודקים, אנשי DevOps, אנשי מוצר ועוד).
למעשה ניתן גם לראות את השימוש ברביעיה הנ"ל כמירוץ שליחים, שבהם לא רק כל מפתח בודד נוגע בכל הרביעיה ביומיום, אלא כל המפתחים, וכך גם למעשה הם יכולים למסור מידע מאחד לשני ובמהירות. אני מצרף וידאו ותמונה הממחישים זאת (הלקוחים מאחת המצגות שלנו):
למעשה גם מומלץ (כפי שניתן לראות בתמונה), שכל רביעיית הכלים גם תהיה מחוברת זו לזו (כולם לכולם), כך שניתן יהיה להעביר בקלות מידע מאחד לשני .
לדוגמא: כאשר מפתח א' מבצע commit, המידע יוכל להשתקף ישירות לראש הצוות שלו – שיבצע לו Code Review כדי לבדוק הסתכלות מהירה על הקוד ולוודא שהוא נראה תקין לפני שימוזג לענף משותף.
דוגמא נוספת: כאשר מפתח מבצע commit או push, ירוץ תהליך CI אוטומטי שיריץ כמה בדיקות כדי לוודא שהקוד תקין (למשל בדיקות sanity ; בדיקות שאין בעיות בשימוש בקוד פתוח שהוכנס וכד').
ודוגמא נוספת ואחרונה: לאחר מיזוג מוצלח של קוד, סטטוס המשימה הרלבנטית ב- Issue Tracking יקודם אוטומטית או יסגר אוטומטית.
בעקבות כך אנו גם ממליצים לחברות שנמצאות בתהליך תכנוני של תהליכי עבודה ו/או בחירת כלים חדשים ומודרניים, להסתכל מראש על תהליכים שקשורים לכל הרביעייה הנ"ל.
אנחנו מודעים לכך שלפעמים הצורך הבוער ביותר לחברה הוא להתמקד באחד ההיבטים (למשל Version Control או Issue tracking), אבל לטעמי, בהסתכלות ארוכת טווח, כדאי להשקיע עוד קצת מחשבה ולתכנן מהלך שיקח בחשבון את כל הארבעה, משום שהצורך בהם יגיע בהמשך במוקדם או במאוחר, ויתכן ואז יהיה קשה יותר להטמיע תהליך כזה.
ובנוסף – תכנון שלוקח בחשבון את כל הארבעה מגדיל מנסיוני את הסיכוי להטמעה מוצלחת יותר של תהליכי פיתוח וכלים, וגם יחזיר את ההשקעה (ROI) מהר יותר.
לגבי הכלים עצמם
בחירת כלים היא נושא בפני עצמו שמצריך מחשבה לגבי הציפיות מהכלים וכן זמן בבחינת הכלים.
בפוסט הזה אני לא ארחיב על כך, אבל רק אומר שהכלים הנפוצים כיום כפי שאני נתקל בהם בחברות:
git, GitLab, Jira, Jenkins, GitHub, Bitbucket (כאשר כל אחד מהם נותן מענה רק לאחד הרכיבים או יותר).
אם חשוב לכם לעבוד עם מערכת אחת שמספקת את כל הרביעיה – אזי GitLab היא כיום המערכת היחידה מבין הנ"ל שמספקת את כל הרביעיה, ובצורה טובה.
אם אתם כבר עובדים עם Jira (שנותנת מענה רק לרכיב אחד מהארבעה), ורוצים לחבר מינימום כלים שיתנו מענה לכל הרביעיה, אזי כדאי לחבר זאת ל- GitLab (בין Jira ל- GitLab יש אינטגרציה מצויינת שלא נופלת מהאינטגרציה בין Bitbucket ל- Jira למרות שהם שייכים לאותו יצרן).
כמובן שאלה רק חלק קטן מהשיקולים, וחשוב לקחת בחשבון שיקולים נוספים.
לסיום אציין שיש גם חברות שמצרפות לרביעיה הנ"ל גם כלי ChatOp (כגון Slack או Mattermost ) כדי לייצר תקשורת מהירה עוד יותר של שאלות/תשובות (ועל כך אולי ארחיב באחד הפוסטים הבאים).
חברת ALMtoolbox מתמחה בליווי קבוצות פיתוח ובדיקות במסע ה- DevOps ובשיפור תהליכי עבודה המשלבים כלי-עזר לפיתוח לבדיקות ול- CI , דוגמת Jira, Git, Bitbucket, GitLab, Jenkins , SonarQube, Hashicorp's Terraform, Spotinst, Rancher Labs, Artifactory, Nexus, Snyk, White Source, Coralogix, GitHub ונוספים, ביעוץ ובמכירת רישוי לכלים (רשימת הכלים המלאה נמצאת כאן).
לשאלות: 072-240-5222 או devops@almtoolbox.com
קישורים רלבנטים:
