השלבים הנדרשים להקמת DevOps בארגון

מרץ 16, 2014

תגיות: , ,
אין תגובות

הפוסט שכתבתי בנושא זה פורסם ב – MSDN Blog, ניתן לקרוא אותו כאן

לנוחיותכם אני מפרסם עותק שלו גם בבלוג.

תיהנו!!!

===============================================================================

נתחיל בתיאור מהיר של הבעיה, מה קורה בארגון שאין בו DevOps מסודר?

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

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

למעשה התמונה הבאה ממחישה את התסכול של מי שאמור לנהל את התזמורת הלא מתואמת הזאת: (שכול אחד ינסה לראות איפה הוא עומד ומה קורה ששני הסוסים האלה ירוצו לשני כיוונים שונים, במילה אחת כואב!)

The Problem

הפתרון כמו תמיד תקשורת תקשורת תקשורת ותיאום בין ה – Development ל – Operations, כלומר הקמת תהליך DevOps.

ישנם שלושה פרמטרים חשובים אותם צריך לקחת בחשבון בהקמת DevOps:

  • תהליך – התהליך חייב לתמוך ב – DevOps, אם אני לא יבנה וינהל את קוד המוצר בצורה נכונה לא ניתן יהיה לבצע Deployment יעיל או בשלב הבא אוטומטי.
  • כלים – שימוש בכלים המאפשרים לי אוטומציה מלאה ויתמכו ב – Continues Deployment, אני חייב לבנות (Build) את הקוד בצורה אוטומטית, להריץ Unit Tests, לבצע Deployment לסביבת בדיקות, להריץ בדיקות אוטומטיות וכו’
  • תרבות ארגונית – אנשים חייבים להבין את כול התהליך וההשפעות שלהם על התהליך, אנשים צריכים להיות מאוד מעורבים כדי שזה יצליח, המפתחים צריכים להתאים את אופן כתיבת הקוד שלהם לתהליך ה – Deployment, הבודקים צריכים להתאים את צורת הבדיקות שלהם לתצורת ה – Deployment וכו’

כדי לכתוב פוסט ולא ספר ניקח בחשבון את הדברים הבאים: (אני אכתוב על סעיפים אילו בפוסטים עתידיים)

  • תהליכי הפיתוח עברו את השינויים המתאימים והם יודעים לתמוך ב – DevOps, בדרך כלל התהליכים יהיו אג’ילים
  • יש Unit Test בעל Coverage גבוה
  • יש Automation Testing המכסה את ה – Sanity וה – Regression לפחות
  • המפתחים כותבים Features שניתן לשלוט בהם, כלומר ניתן להדליק אותם על ידי קונפיגורציה מתאימה בעדיפות גם שליטה על מידת החשיפה שלהם כלפי לקוחות מסוימים או משתמשים מסוימים.
  • הקומפוננטות השונות במוצרים השונים מופרדות או שקיים מינימום תלות ביניהם

 

השלבים אותם צריך לבצע בבניית ה – DevOps:

שלב 1: SCM – Software Configuration Management – בשלב זה נבנה ניהול נכון של קוד וגרסאות, שלב זה מבוצע בעזרת ה – Source Control ומיושם על ידי ניהול Branches נכון.

שלב 2: בניית בילדים אוטומטיים האחראים על:

  • קימפול המוצר
  • הרצת Unit Tests
  • הכנת התוצרים ל – Deployment

שלב 3: הכנת Deployer שיהיה אחראי על:

  • התקנת סביבת Testing, חשוב להתקין סביבת Vanilla ולא סביבה שכבר הרצנו עליה בדיקות ועשויה להיות “מזוהמת”
  • הרצת הבדיקות האוטומטיות על הסביבה שהותקנה
  • התקנת סביבת Staging/Preproduction – בשלב זה נוכל לבצע בדיקות ביצועים למוצר אוטומטיים או ידניים
  • התקנה\שדרוג של סביבת ה – Production

שלב 4: ניתור סביבת ה – Production בעזרת כלי ניתור ייעודיים:

  • התראות ביצועים
  • התראות על בעיות
  • איסוף מידע על בעיה שעלתה והעברת המידע ל – Developers/Testers
  • וכו’

בנוסף לשלבים אילו נקים DevOps Backlog שיכיל את התכולה להעלאה, צוות ה – DevOps בשיתוף עם ה – Operations יפעלו על פי ה – DevOps Backlog.

 

באיזה כלים נשתמש?

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

שלב 1: לשלב הראשון נשתמש ב – TFS Source Control, גרסת ה – 2013 מכסה כמעט כול דרישה בתחום זה, ההפתעה הגדולה היא כיסוי ה – git.

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

שלב 2: כאן ההמלצה שלי היא ה – Team Builds, יצא ל לעבוד עם לא מעט כלי בילדים אוטומטיים הנפוץ שבהם ה – Jenkins לא דורש הרבה ידע לשימוש אך יחד עם זאת די מוגבל (מניסיוני האישי ואני בטוח שיהיו אילו שיחלקו עלי), ה – Team Build דורש ידע ב – Workflow Foundation ופיתוח על מנת לבצע פעולות מורכבות אך בילד זה נותן מרחב פעולה כמעט בלתי מוגבל מה שנחוץ ברוב המערכים של DevOps שנקים.

שלב 3: ישנו כלי חדש יחסית שמיקרוסופט רכשה שנקרה InRelease, כלי זה להערכתי די טוב כאשר מדובר על סביבות מיקרוסופטיות בלבד. כמו כן מהיקרותי את מיקרוסופט אני בטוח שנראה בו התקדמות משמעותית בעתיד הקרוב.

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

שלב 4: ניתור סביבות נוכל לבצע בעזרת ה – System Center של מיקרוסופט על חלקיו, ב – TFS 2013 ישנה אינטגרציה מאוד מעניינת עם ה – System Center כך שניתן לפתוח Work Items מה – System Center ב – TFS ולבצע מעקב אחר ה – Work Item שנפתח.

עבור בניית ה – DevOps Backlog וניהולו ניתן להשתמש ב – Work Items של ה – TFS.

כלים נוספים בהם ניתן להשתמש הם ה – MSTest עבור ה – Unit Tests וה – Coded UI Test עבור בדיקות GUI, כמובן לא הזכרתי את ה – Visual Studio למפתחים וה – Microsoft Test Manager לבודקים הכולל גם ניהול בדיקות וגם ניהול מעבדות…

לסיכום:

בכדי להקים DevOps בארגוננו נצטרך לשפר את התהליך ולשנות את התרבות הארגונית.

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

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

תיהנו!!!

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *