תובנות על OpenShift בחברות גדולות

יוצא לי בלא מעט מקרים לתת יעוץ לחברות גדולות לגבי עניין המעבר ל-Devops, שימוש בקונטיינרים, Docker, שימוש ב-Jenkins ושאר כלים. כמובן, כמו תמיד, בחברות גדולות, אף אחד אינו רץ להטמיע טכנולוגיה זו או אחרת רק בגלל שחץ בן חמו (או נציגי Presale של רד-האט, אין לי קשר אליהם) המליץ עליה. יחד עם זאת, בדרך כלל ההמלצה שלי לפני שמרימים אפילו PoC של OpenShift – אני מבקש מהחברה שתתן לי להיות "הטיפש" – להיות עם צוות שינסה את הדברים החדשים ובעצם ללמוד את התהליכים שהצוות משתמש בהם – החל מכתיבת קוד, שימוש ב-SCM, קומפילציה, טסטים, תהליכים נוספים עד לתוצר הסופי (קבצים בינאריים, Artifacts וכו').

מהנסיון שלי, להעביר Enterprise ל-OpenShift (ולמען האמת גם ל-Kubernetes שהוא פחות מאובטח) מצריך עבודה ארוכה וההנהלה הטכנית יצטרכו לקחת כמה החלטות חשובות, כי יש צורך בשינויים. הנה כמה נקודות.

  1. ניהול קוד (Source Code Management – SCM)
    ברוב המקרים שישבתי לפגישת היכרות ושיחה על המערכות הקיימות, בד"כ מערכת ניהול הקוד היתה TFS של מיקרוסופט או בחלק מהמקרים SVN. מקומות בודדים הכניסו איזו "תת מערכת" של GIT (בשימוש של Gitlab או BitBucket).
    הבעיה: שום מערכת קונטיינרים המבוססת על Kubernetes לא תומכת באופן רשמי לא ב-TFS ולא ב-SVN. כולן תומכות באופן טבעי ב-GIT.
    הפתרונות שיש הם מאוד עקיפים:
    עם TFS יש פתרון די עקיף לבעיה כפי שמוסבר כאן.
    עם SVN הפתרון הוא למשוך את הקוד למכונה מקומית שמחוברת לשרת GIT, ולאחר מכן לבצע Commit, Push לשרת ה-GIT המקומי. זה פתרון די "מכוער" ובעייתי מכיוון שאם מישהו שכח להוריד ולהעלות קוד ל-GIT, ה-Build יהיה בעייתי. אגב, שרת SVN הוא יחסית קל מאוד להמרה ל-GIT, במידה והחברה מעוניינת לעבור ל-GIT.
  2. מכונות Windows ולינוקס ביחד.

    לא מעט חברות גדולות כותבות קוד ל-Windows וסקריפטים ל-Windows (ראיתי גם מקרים של Build ל-JAR/WAR שכתובים ב-Batch file), וכאן ישנה בעיה מהותית – Kuberenetes בעצמו לא רץ בצורה טובה על Windows והפתרון שיגיע בשנה הבאה יאפשר גם ל-Kubernetes וגם ל-OpenShift להשתמש ב-Nodes שהם גם Windows וגם לינוקס (אם כי שרתי ה-Master וה-Infra יצטרכו להיות מבוססי לינוקס).
    עד אז תהיה בעיה לקמפל קוד בצורה יציבה של דברים כמו DOT Net (כדאי לעבור ל-Dot Net Core שנתמך ורץ על לינוקס), ויהיה צורך להמיר קבצי batch ל-shell כדי לקמפל את הדברים על Windows.

  3. בחירת אסטרטגיה ב-OpenShift
    באופן עקרוני, שימוש ב-OpenShift מחייב בחירת אסטרטגיה, ו-OpenShift תומך ב-4 אסטרטגיות פופולריות: Docker, Source to image (S2I), Jenkins Pipeline ו-Custom (שהוא מאוד מתקדם וברוב המקרים לא יהיה בו שימוש אלא במקרים מיוחדים ששאר האסטרטגיות אינן עונות על כך)

    1. אסטרטגיית Docker מאפשרת שימוש ב-Images קיימים מבחוץ (ממקומות כמו Docker Hub לדוגמא) ושניבנו פנימית כחלק מהרמת אפליקציות. יש עם האסטרטגיה הזו 3 בעיות:
      1. רוב ה-Images שתמצאו בחוץ לא יפעלו עם OpenShift כי הם רצים כ-root ו-OpenShift בנוי בראש ובראשונה לאבטחה הדוקה ולכן הוא חוסם מיידית הרצה של Images כאלו (אפשר לבטל זאת אבל אז מישהו יחטוף על כך ממחלקת אבטחת מידע)
      2. בלא מעט מקרים שוחררו Images שמריצים מספר אפליקציות במקביל בתוך אותו Image וזה הורס כל דבר שקשור לגדילה רוחבית (Scaling) ולכן לא מומלץ להשתמש ב-Image כזה.
      3. טכנית, מבחינת אבטחה בקונטיינרים, דברים צריכים לרוץ רק ב-Foreground ולא ב-background ולכן קונטיינרים שיריצו דברים ב-background (שרותים כמו nginx, apache, postfix ועוד ועוד) – הקונטיינר "ימות" לאחר זמן קצר והמערכת תנסה להקים אותו שוב ושוב, מה שיצור loop (במיוחד אם מופעל Replication Controller – RC).
    2. אסטרטגיית Source to image (כלומר S2I): עם אסטרטגיה זו מערכת OpenShift מושכת ImageStream (כלומר Image "שלד"), יוצרת Image חדש שאליו היא "שופכת" את הקוד מ-GIT, מבצעת שינויים שצריך (הרשאות, התקנת קבצים נוספים כמו דרך PHAR ב-PHP או NPM עבור Javascript ועוד ועוד), ולבסוף בונה Image סופי שאותו המערכת מריצה ומקימה POD עם קונטיינר המכיל את ה-Image. באסטרטגיה זו ניתן "לקשור" (דרך Webhook) בין REPO של GIT לבין אפליקצייה ב-OpenShift וברגע שיש שינוי ב-GIT, המערכת תבנה אוטומטית Image חדש וכשתסיים היא תוריד את ה-POD הקיים ותפעיל מיידית את ה-POD עם הקונטיינר החדש (ניתן כמובן לבצע Blue/Green Deployment – פרטים כאן וזה קיים לא רק ברמת אפליקציות אלא גם ברמת מכונות)
    3. אסטרטגיית Jenkins: עם אסטרטגיה זו אנחנו מגדירים הכל מראש: מאיפה הקוד ימשך, מה ה-pipelines וכו' וכו' ו-OpenShift יקים בכל פעם קונטיינר Jenkins, יקמפל, יריץ את ה-pipelines, יפזר מה שצריך לפזר, יבנה Image חדש ויריץ POD עם קונטיינר המבוסס על ה-Image החדש. הדרך הזו יכולה להתאים לאלו שכבר משתמשים ב-Jenkins על לינוקס.

ישנם עוד חלקים הקשורים להקמת מערכת שיש צורך לערב הן את מחלקת אבטחת מידע והן את צוות ה-Storage. בגופים פיננסיים ובטחוניים יהיה צורך לשים דגש על שרתי Registry מקומיים (לחשיפה מופחתת לאינטרנט, אבל עדיין יש צורך לשאוב קבצי Image, בלי זה אי אפשר להקים שום דבר, ואין זה משנה אם מדובר ב-OpenShift או בכל מערכת אחרת מבוססת Kubernetes), שילוב עם Active Directory, הרשאות וכו' (מובנה ב-OpenShift, לא קיים ב-Kubernetes) ועוד דברים רבים.

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

מעבר ל-CI/CD בחברות גדולות

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

מנסיון אחר שלי עם חברה בינונית באותו נושא, דברים התקדמו בצורה מאוד יפה. בפגישה הראשונה הסברתי את נושא ה-CI/CD, בפגישה השניה דיברנו על טכנולוגיות שאתקין להם ועל מה שיש להם כרגע ואיך להעביר את הדברים, פגישה הבאה היתה תכנון ההתקנה ובמשך כמה ימים לאחר מכן ההתקנה בוצעה, לאחר מכן בוצעה המרה והטמעה של מס' טכנולוגיות שהם משתמשים ולאחר מכן היתה הדגמה של איך הדברים יעבדו. בפגישות הבאות היתה הדרכה כיצד לעבוד עם הכלים החדשים, כיצד הדברים רצים "מאחורי הקלעים" ומה ניתן לקבל מהכלים ולבסוף הדרכות כיצד כל מפתח יכול וצריך לעבוד מעתה. סה"כ זמן הפרויקט: חודשיים (2-3 פעמים בשבוע). טיפ לחבריי הפרילאנסרים – מומלץ לחשוב על מחיר שעה במקום מחיר פרויקט. זה היה הרבה יותר ממה שקבענו.

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

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

  1. לבחור צוות שיעבור ל-CI/CD מתוך כל הצוותים שיש בחברה. כדאי שבצוות יהיו אנשים עם מוטביציה ועם ראש פתוח. בלי זה – המעבר יכשל, מבטיח לכם.
  2. להעדיף כלים מבוססי קוד פתוח או פתרונות מסחריים מבוססי קוד פתוח. כלים קנייניים הם מקור לצרות בעולם ה-CI/CD שמתפתח בקצב מהיר. לעומת זאת, כלים בקוד פתוח צריכים בד"כ הרצה של פקודת YUM או APT כדי לעדכן.
  3. האם בהזדמנות זו מכניסים פתרון קונטיינרים? (אפשר לבצע CI/CD ללא קונטיינרים) – אם כן, כדאי להחליט אם הולכים על פתרון מסחרי של Kubernetes (כמו CAAS של SuSE) או על OpenShift של רד-האט שהוא גם מבוסס Kubernetes אבל נותן הרבה הרבה יותר יכולות. (ישנם כמובן גם פתרונות אחרים אבל הם לא עונים לצרכים של Enterprise).
  4. פיתוח כ-Multi Platform – חשוב במיוחד לבנקים, חברות ביטוח וחברות פיננסיות. זה נחמד וטוב לפתח ל-Windows אבל אפשר בעזרת עבודה די קצרה לעבור ל-Multi Platform. עובדים ב-JAVA? מצוין, אפשר גם עם לינוקס, צריך בסה"כ לשנות מספר סקריפטים (אם כתבתם) כדי לעבוד בלינוקס. עובדים עם Dot Net? תכירו את Dot Net Core שמאפשר לכם עבודה עם Windows ולינוקס. היתרון של עבודה עם לינוקס הוא שמגוון רחב של כלים יהיה זמין לכם (במיוחד אם אתם עובדים עם קונטיינרים).
  5. טסטים טסטים טסטים … יש עדיין מקומות שמעסיקים אנשי QA. ברוב המקומות לעומת זאת, כבר אין חיה כזו מהסיבה הפשוטה שהיום פשוט כותבים טסטים שרצים במערכת כמו Jenkins המבצעים בדיקות Unit testing ועוד מספר סוגי טסטים על מנת לוודא שמה שמפותח – הוא יציב ועובד.

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

ועוד משהו אחד שרבים לא יאהבו שאני כותב זאת: החיה הזו בשם "איש Devops" זו המצאה שגויה של אנשים שלא מבינים מה זה Devops. הבה נסתכל על משהו פשוט בחברה גדולה: החברה מחליפה תוכנת גיבוי, תוכנת Code Repository, אולי כלי אוטומציה ועוד מספר דברים. האם אותה חברה צריכה פתאום שכיר נוסף? לא, כי צוות ה-IT אמור לדעת לתמוך בכלים. אפשר לקרוא למישהו מבחוץ שילמד ויתרגל את הצוות, אבל הצוות יכול בהחלט להמשיך ולתחזק את אותם כלים. אדרבא, הן אנשי ה-IT והן צוותי הפיתוח צריכים להכיר את הכלים (ברמות מסויימות כמובן, ה-IT ברמה של Sysadmin והשאר ברמה של Usage).

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

אתם באמת צריכים איש Devops? (חלק שני)

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

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

אתן דוגמא: כפרילאנסר, אין לי שום בעיה להרים Software Defined Storage, או קונטיינרים או לבנות מערכות לינוקס גדולות לבצע תפקודים מסויימים, או מערכות וירטואליזציה סגורות או בקוד פתוח, אבל כשזה מגיע למערכות כאלו, יודעים כמה חברות גדולות יכנסו לדף ה"אודות" כדי להזמין אותי, לשפוך כמה מאות אלפי דולרים ולשלם לי כמה עשרות אלפי שקלים בפגישה הראשונה? אפס. אף אחד לא מוכן להקים מחר בבוקר מערכת כזו. כל מי שיפנה – אז הוא יצור קשר להתעניינות, אולי להיפגש ואם זה ישמע לו, הוא ירצה בתור התחלה PoC (כלומר Proof Of Concept) ורק אם ה-PoC מראה תוצאות טובות – אז החברה תיקח זמן לחשוב, אולי תסתכל על הצעות אחרות ואם הם ירצו – הם יפנו מחדש כדי להקים מערכת כזו. כל פרילאנסר שעובד עם גופים גדולים יכול לספר לכם על כך. באופן עקרוני – ככל שהגוף/חברה יותר גדולה, דברים נעשים יותר לאט. מה שאנשים מקצועניים עושים בסטארט-אפ מהבוקר שהם מתחילים לעבוד ועל הפסקת הצהרים – יתורגם לשבועות ואף לחודשים – בחברות גדולות.

בסטארטאפ, הדברים הם פשוטים: כולם עובדים יחד. יש כמובן צוותים, ובתוך כל צוות פיתוח – כל אחד כותב חלק מסוים של הקוד, וסביר להניח שהוא יכתוב את קוד ה-Units testing, את ה-UAT או את ה-User Stories (לפי ה-Agile Development) לאותו קוד שהוא כתב. בקיצור – יש הרמוניה, וכשיש דינמיקה, דברים זזים מהר, ותמיד יהיה מישהו שיהיה אחראי על אוטומציה, תשתית ושאר ירקות שקשורים ל-Devops.

בחברות גדולות לעומת זאת, דברים זזים לאט ולפעמים "נתקעים". אז אתה רוצה לעבוד במתודולוגיית Agile? כאילו ה-Devops הזה ששומעים עליו? אוקיי, נתחיל עם PoC. הגיוני, לא? רק שאז צצה לה ה"פוליטיקה" של הארגון. ההוא שם טיפוס מבודד שלא מוכן לעבוד עם אף אחד (ומה לעשות, הדבר הראשון ב-Devops זה עבודה ביחד) ההוא לא רוצה לעבוד עם ההיא וכו', אנשים לא רוצים עבודות נוספות כמו כתיבת טסטים, Stories וכו', יש חוסר רצון בולט בלעבור לכלים יותר מודרניים (גם אם אתה מציע כלים שישמרו על תאימות לדברים הקלאסיים) ובכלל – בארגונים רבים מנסים (וחברות גולגלות/כ"א די מסייעות לכך מבלי לשים לב) "לכמת" את זה למישהו מסוים, אולי 2-3 לצוות – בדיוק כמו שיש צוות לסטורג', לנטוורק, לוירטואליזציה – אז עכשיו יהיה "צוות Devops".

כאן, בשביל ה-PoC מישהו חיצוני (פרילאנסר) יכול להוות פתרון. החלק הראשון הוא ההסברה לגבי מה זה לכל הרוחות Devops, מה זה מתולודוגיית Agile software development, מה נדרש בעצם מהמפתחים, איך זה הולך להיות וכו', כלומר הרבה לפני שבכלל מרימים אפילו VM או קונטיינר אחד – יש ישיבות על גבי ישיבות, הסברה עם מצגות, צריכים הסכמות לגבי הדברים, אישורים עקרוניים מצד מנהלי צוותים שונים, חישוב ואישור תקציב – וכל זה לפני שאתה נוגע במקלדת בשביל לבנות משהו. האמינו לי, בחברה מסויימת אני אמור להקים קונטיינר יחיד ב-Docker. כמה זה מסובך? זה לא, אבל אנחנו כבר 6 חודשים בישיבות. בגלל זה, פרילאנסר מתאים לחלק של ה-PoC. הסכימה החברה לשנות את כל העבודה שלה ועבודת הצוותים? שם כבר יכול להיכנס שכיר (ולשכירים שנכנסים לגופים גדולים ההמלצה שלי: הצטיידו בטונות של סבלנות).

במהלך היום (אני קצת חולה עדיין) עברתי המון על קליפים ביוטיוב שיכולים להסביר בצורה עניינית ולא בצורה של בלה-בלה-בלה מה זה Devops ולבסוף מצאתי אחד שמסביר בצורה טובה (לדעתי) את הדברים. הוא לא נכנס לפרטים של איזה בדיוק כלי לבחור ולשם מה, אבל הוא מסביר את זה בקטגוריות. הוא גם מתייחס לדברים בחברות גדולות. אורכו של הקליפ הוא שעה וחצי, אבל יש חלקים שונים שאפשר לדלג מעליהם (השתמשו במקשים L ו-J [ללא shift] כדי לקפוץ 10 שניות כל פעם) ולדעתי הקליפ די עוזר לתפוס מה זה Devops.

לסיכום: כפי שציינתי אתמול, חברות כ"א עדיין ימשיכו לקטלג את Devops כעוד תחום, כלומר עוד מישהו נפרד תוך התעלמות מוחלטת שזה בראש ובראשונה עבודה בצוות בנושאים שונים ויש צורך בשיתוף פעולה מכולם, וחברות צריכות לזכור שבראש ובראשונה עוד לפני ששוכרים מישהו, צריך לגרום לכולם לעבוד ביחד ובשיתוף פעולה. אם כל אחד עובד בנפרד מבלי לרצות לשתף פעולה, שכירת שכיר שיעזור להכניס את החברה ל-Agile Development/Devops פשוט לא תעבוד, כי מה לעשות – אף מפתח ותיק לא ירצה להקשיב לבחור החדש.

אתם באמת צריכים איש Devops?

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

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

אני אקח ברשותכם את הדברים טיפה קדימה. אני יותר ממשיל "איש Devops" (המרכאות בכוונה) למשהו מהדת הנוצרית: לאוונגליסט. הוא האדם ש"מצעיד" את החברה ממצב עבודה "קלאסי" (כתיבת קוד, קימפול, הכנסה ל-source repository, הוצאת Build, העברה ל-QA, תיקונים, קימפול, הוצאת Beta, תיקוני באגים, עוד Beta, עוד תיקונים ושחרור גירסה – כל זה ב"מבט על" וקפיצה על כל מיני שלבים בדרך) למצב עבודה שונה וזריז בהרבה.

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

בתוך Jenkins (וכלים אחרים שנותנים פחות או יותר אותו דבר) יש לנו גם "צינורות" שבהם אנחנו מתכננים את כל התהליך מרגע שהמערכת מושכת קוד מה-GIT, מקמפלת ועושה שורה של דברים (חלקם מותנים, כך שיש מעין "תתי צינורות")  עד לחלק האחרון שאנחנו רוצים שהמערכת תעשה וניתן יהיה לשלב זאת בפרודקשן או לבצע מהלכים כלשהם (בדיקה ידנית, Selenium ואחרים).

בקיצור – לא רק הכלים שונים, השיטה שונה.

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

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

אבל מי שיציץ בפורומי מודעות דרושים, ימצא פעמים רבות מודעות שמחפשים "איש Devops" שיהיה, ותסלחו לי על הביטוי: סופר-כלבויניק. מקוששים מכל אחד מאנשי הצוות דברים שהם לא רוצים לעשות וזורקים את הכל על מישהו אחד, ושבדרך גם יעשה אוטומציה עם כלי כלשהו, שיהיה "ספץ" Linux וסקריפטים וכמובן שיהיה מומחה ב-Windows עם נסיון פיתוח. מהיכרות עם שכירים רבים, אני יכול לאמר שכאן בפירוש כיוונו לשמיים (ואני מתקשה להאמין שימצאו מישהו בדיוק עם אותה "רשימת קניות") ואין כמו פתגם שמדייק למטרה זו: תפסת מרובה, לא תפסת. הנה דוגמא של מודעה:

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