ללמוד מאחרים: מסע ה-DevOps של Axonize

איך עוברים מה׳׳בלאגן היצירתי׳׳ של פיתוח ראשוני למתודולוגיה מוגדרת של פריסת מוצר? הסיפור של חברת Axonize

קרדיט צלם\תמונה: Oleh Slobodeniuk, Getty Images Israel

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

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

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

מה זה בכלל DevOps?

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

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

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

3. כלים – לבסוף DevOps נוגע בכלים ממש. כיום קיים היצע ענק של כלים פתוחים ומסחריים המסייעים לממש תהליכי DevOps, כמו Jenkins, Chef, Puppet, Ansible ואחרים. הכלים הרלוונטיים כוללים כלים לשלבים השונים של בנייה, אריזה, פריסה, בדיקה, וניטור של הפתרון.

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

מעבר לשלב הבנייה המואצת

השלב ההתחלתי – Optimized for Velocity: סטארטאפים רבים בשלב ראשוני ממוקדים בפיתוח טכנולוגי של הוכחת ההיתכנות הטכנולוגית, או של הגרסה הראשונית של המוצר. הצלחה או כישלון בשלב כה ראשוני היא ברוב המקרים שאלה של חיים ומוות עבור סטארטאפ, ועל כן סטארטאפים לרוב בוחרים (ובצדק) בגישה של “quick and dirty” – כתיבת קוד מהירה, כתיבה מינימלית של בדיקות והטמעה ידנית של הקוד. בשלב זה כמובן רוב הקוד הוא חדש ונכתב על ידי מספר קטן של מפתחים, אז בעיות של אי תאימות לגרסאות קודמות הן מועטות. בשלב זה גם לא באמת מוגדרים תהליכים, ואפשר אפילו לראות בעיסוק בהם כפגיעה בתפוקה שכן סטרטאפים עובדים במצב של אופטימיזציה למהירות, או Optimized for Velocity.

השלב המתקדם – Deployment Hell: ככל שהזמן עובר הפתרון הטכנולוגי שאותו בונה הסטארטאפ נהיה מורכב, ונוצר מצב הקרוי “Deployment Hell” – כל שינוי של המערכת הופך לאתגר, בין השאר מהסיבות הבאות:

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

לפתע המיקוד הטכנולוגי של החברה כבר אינו יכול להיות רק בבנייה מואצת, אלא גם בשליטה בפתרון הקיים ובהסדרה של התחזוקה שלו. במקרה של Axonize הפתרון המורכב כלל סוגים שונים של מסדי נתונים כגון SQL, MongoDB, Redis, Elasticsearch שירותי ענן שונים, וכן טכנולוגיות מורכבות כמו Apache Storm ומערכות Frontend ו-Backend שפותחו בשפות תכנות שונות. הכנסת שינויים תכופים למערכת לצורך תיקון תקלות או הוספת יכולות מערערת מאוד את יציבותה, והשימוש של לקוחות במערכת הפך את העניין למסוכן ובעל משמעות עסקית. בשלב זה, הסדרת תהליכים הפכה להיות לצורך אמיתי.

צלם/תמונה: Martin Barraud/ Getty Images Israel

צלם/תמונה: Martin Barraud/ Getty Images Israel

בניית תהליכים – איך מתחילים?

כאמור, DevOps נוגע בראש ובראשונה באנשים ובתרבות ארגונית. מעבר לגיוס איש DevOps ייעודי, כלל המפתחים של Axonize נרתמו למאמץ החשיבה והתכנסו לניתוח מעמיק של דרכי העבודה הקיימות. השלב הראשון בייעול הוא הבנה של התהליך הקיים. הצוות ביצע ניתוח באמצעות מתודולוגיה בשם VSM – Value Stream Mapping, בה פועלים להציג את כל שלבי התהליך הקיים באופן ויזואלי על לוח מחיק. הכוונה היא לצייר את התהליך כולו ובכל שלב להגדיר מה מתבצע, מי מאנשי הצוות יכול לבצע את הפעולה, כמה זמן השלב לוקח, אם הפעולות הן ידניות או אוטומטיות ומה הסיכוי שתצוץ בעיה שתחזיר את התהליך לשלב קודם.

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

אימוץ פרקטיקות חדשות

תהליך ה-VSM הביא את Axonize לבחור במספר פרקטיקות לייעול והסדרה של תהליכי הפיתוח והפריסה.

Infrastructure as Code – הרמת תשתית והגדרת קונפיגורציה באמצעות סקריפטים וקבצי טקסט המתארים את הסביבה העננית של הארכיטקטורה (למשל בפורמט JSON). כך ניתן לשמור את הגדרת הסביבה, בדומה לקוד במערכות כמו git, לשכפל באופן מהיר ועקבי סביבות וכן לבצע rollback מהיר ברמת התשתית. במקרה של Axonize, הגדרת התשתית המורכבת אפשרה אוטומציה וייעול בתהליך הפריסה של סביבת הענן ופישוט התהליך שעד כה היה ידני.

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

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

(Continuous Delivery (CD – יצירת תהליך אוטומטי של פריסת גרסאות קוד חדשות באופן תכוף לתוך סביבותDevelopment, Staging ,Production. בדומה ל-CI, השימוש בבדיקות אוטומטיות ותכיפות הפריסה של שינויים קטנים מביאה לשליטה ולניטור טובים יותר וליציבות הסביבות השונות.

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

הכתבה בחסות Microsoft Visual Studio Team Services

Visual Studio Team Services (VSTS) הוא שירות המאפשר להגדיר ולנהל ביעילות תהליכי DevOps כגון Build, Release management, CI/CD ועוד. VSTS מאפשר אינטגרציה של כלים נפוצים בתעשייה וטכנולוגיות פתוחות כגוןJenkins, Chef, Puppet, Docker ועוד. בדוק את עצמך! האם אתה DevOps Ready?

כתב אורח

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

הגב

Be the First to Comment!

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 
wpDiscuz

תגיות לכתבה: