על DevOps וכאלה
מאמר שמתמקד באופן כללי על DevOps וקצת על הכלים וביכולות של Azure DevOps והכנה לקראת המאמרים הבאים בנושא Azure DevOps.
משרות חדשנות וטכנולוגיות, איפה אני נמצא בכל הבלאגן הזה? בעבר רשמתי מאמר על התקופה שאנו נמצאים בה, ועל זאת שתגיע בשנים הקרובות יחד עם כל השינויים בתפקידים הטכניים אשר מתרחשים סביבנו. למאמר של משרות, חדשנות וטכנולוגיה.
איך זה מתחבר לתחום הפיתוח ובפרט אל DevOps? התחום של DevOps הינו תחום שצבר תאוצה בשנתיים האחרונות באופן מהותי, ואפילו הצליח לשנות סדרי עולם בתחום הפיתוח.
עד כאן זה לא חדש במיוחד, אך לצד האימוץ של התחום בידי ארגונים (גם כאלה שאינם טכניים במיוחד), עדיין ישנם פערים בין הידע, הכלים המוצעים, ובין מה שממש אפשר לעשות בפועל.
לא מפתיע שהמון אנשי סיסטם ביצעו מעבר לתפקידי DevOps למינהם, ולצד זה שהמעבר לתפקיד DevOps שיפר את היכולות הטכניות של אותם אנשי סיסטם, המעבר לא דרש מהם להיות אנשי קוד ולדעת שפות תכנות.
הקונספט
לכל התחום והתהליכים של DevOps ישנה מטרה והיא לאפשר תהליכים גמישים ומהירים (Agile), וכמו שנאמר DevOps הוא משהו שנכנס לתוך חברות טכנולוגיות וחברות שאינן טכנולוגיות, מיותר לציין שחברות מתקדמות כמו Amazon, Microsoft, Facebook ודומיהם או סטארטאפים נשענות על DevOps בכל טכנולוגיה ופיתוח של פתרונות חדשים.
אם נקח למשל שוב את צוותי IT אז תהליכים כאלה מסייעים להסתגל לחדשנות, כמו קידום תשתיות IT וענן, עלייה בתדירות עדכוני תוכנה ובנוסף מאפשר להגיב במהירות רבה יותר לתהליכים ארגוניים.
למרות הכל ולמרות הפופולריות של תחום DevOps, עדיין אין הגדרה נפוצה למונח, ובדרך כלל DevOps מתואר כגישה מודרנית לפיתוח תוכנה שבה אנשי פיתוח ואנשי תפעול מאוחדים בצוות אחד.
ליתר דיוק, הגישה של DevOps מביאה איתה בשורה של אבטחת איכות (QA), תכנון, ניתוח פעולות בתהליך, ושיתוף פעולה עם סביבת עבודה אחת בה ישנו שיתוף פעולה בכל עדכון גרסה כאשר הפיתוח והבדיקות (QA)נעשים באמצעות כלים אחידים.
יחד עם זאת חשוב להדגיש כי הגישה הזאת של תהליכי DevOps לא תמיד יוצאת לפועל וישנם פערים בין התיאוריה לבין הפעולות שנעשות בשטח.
בתהליך סדיר כל מי שקשור לתהליך DevOps חולק אחריות לכל חלק אשר שייך אליו, החל מפרט של הדרישות דרך העברת היישום ועד מעקב אחר ביצועים ואמינות הקוד.
אם נקח לדוגמה מצב ללא תהליך DevOps מסודר ומצב שבו חברת פיתוח מייצרת שירות הזמנה מקוון, בתהליך פיתוח שאינו מסתמך על DevOps, צוות הפיתוח ככל הנראה שחרר קוד חדש או מעודכן בכל פרק זמן (למשל, רבעון) בכדי לעדכן את המערכת או הפאליקציה הקיימים.
לפני שהגיע לייצור, הקוד עבר מאנשי הפיתוח לצוות בדיקות, ואז לאישור של מהל הפיתוח או מנהלי המערכות השונים. במקרה של בעיות ושגיאות באפליקציה, צוות הפיתוח קיבל תיקן את הבעיות והבאגים באפליקציה.
אחת הבעיות הגדולות היתה היא שהיה צורך להשקיע המון זמן בכדי לזהות קוד פגום, השוואה בין גרסאות קוד של אנשי פיתוח, ולאחר שתוקנו הבעיות, צוות הבדיקות שוב ביצע את נהלי הבדיקות לאימות לפני שחרור גרסה.
לכן, גישה כזו לתהליך פיתוח היא איטית מסורבלת, לוחקת המון זמן ומראש גורמת לבעיות, ולכן ההשלכות הם הארכת תהליך הפיתוח + בדיקות + שחרור גרסה ומעבר לייצור.
נחזור לימינו, ובכדי לשפר את תהליך הפיתוח, להיות יותר אג’ילים, לוודא שהקוד מכיל פחות בעיות, שהמעבר לייצור יהיה פחות מסורבל ובכדי שהקוד מאובטח יותר אנו צריכים תהליך מסודר המבוסס על DevOps.
במצב של תהליך DevOps המצב פשוט יותר בגלל שכל חבר בצוות יודע את מקומות והאחריות שלו מוגדרת מראש בתהליך, למשל, צוות Ops מסייע לצוות Dev בניהול ותחזוקה של מערכות מידע וסיסטם. וצוות Dev, בתורו, עוזר לצוות Ops לקבוע את תצורת תשתית IT, כמו גם ליישום עדכוני תוכנה לשיפור האבטחה, האמינות והביצועים שלו.
נחזור רגע למשרות והשינויים שהוזכרו קודם והצורך בתפקידים מסוימים, ואם נביט על דרישות תפקידי DevOps, אז אפשר לראות את המגמה של עליה בצורך לתפקידי DevOps, אך יחד עם זאת צריך להפריד בין התפקידים השונים.
מבדיקה קצרה של משרות בארץ החיפוש הוא אחר אנשי DevOps שיודעים הכל (ארכיטקט, מיישם וכן הלאה), אך מבדיקה קצרה איך התפקיד בנוי במקומות אחרים בעולם ישנה חלוקה של התפקיד שנעשית בשלב ראשון על התפקידים הבאים:
- DevOps ארכיטקט – אחראי על תכנון, איפיון ובקרה של תהליכים בסביבה, ולכן אינו נכנס לפרטים הקטנים של אופן כתיבת הקוד אך כן אחראי לבניית תהליך מסודר.
- מיישם DevOps – מקבל את האיפיון ומיישם אותם לפי מדינות ברורה מראש, בנוסף אחראי להעביר את כל המידע tar יושם בתהליך ועל בסיס האיפיון. בנוסף אחראי לביצוע אופטימיזציה של התהליך.
- DevOps Engineer הוא זה שמבצע ניהול ותחזוקה בפועל מול הצוותים השונים, כולל מעבר וסיוע על כל חלק בתהליך. לצורך הענין הוא הגורם שאליו פונים בכל בעיה שהיא בתהליך.
מהו DevOps
רשמית, DevOps הוא שילוב של תיאוריות, פרקטיקות וכלים המאפשרים לארגון לספק אפליקציות ושירותי ענן (או רשת) באופן מהיר יחסי על גבי תהליכי פיתוח שונים אשר נעשים בקצב מהיר ובאופן סדיר.
DevOps היא מתודולוגיה של פיתוח המאפשרת לצוותים לעבוד ביחד על תכנון, פיתוח, בדיקות, הפצה ותפעול תהליכי תוכנה וקוד.
זאת באמצעות שילוב של כלים אוטומטיים, תשתית מחשוב גמישה ועקרונות שדורשים לעבור בצורה רציפה ככל האפשר בין שלבי הפיתוח השונים.
המתודולוגיה באה לידי ביטוי בפעולות היומיומית של DevOps באמצעות תפעול תשתיות מחשוב המותאמת לדרישות הארגון, בפיתוח של כלים אוטומטיים, פעולות או תהליכים המאפשרים בדיקות מהירות של גרסאות חדשות, מעקב וניטור של משאבי רשת, בדיקות אבטחה סביב קוד, איסוף מידע לגבי תקלות ואופן השימוש ושיפור חוויית השירות.
קצב השינויים והמהירות על גבי תהליך DevOps מאפשר לארגונים לספק שירות טוב יותר ולהתחרות מול לקוחות בצורה יעילה יותר מאשר תהליך פיתוח וניהול מסורתי.
בפועל, משתמשים בפרקטיקות לאוטומציה של תהליכים שעבר היו ידניים ואיטיים, פעולות רבות נעשות על גבי כלים וטכנולוגיה המסייעים להם להפעיל ולפתח יישומים במהירות ובאמינות.
כלים אלה גם מסייעים לבצע באופן עצמאי משימות, למשל, פריסת קוד שבדרך כלל היו זקוקים לעזרתם של צוותים אחרים, וזה מזרז עוד יותר את עבודת הצוות.
מתודולוגיה ותהליכי DevOps מביאים איתם יתרונות רבים, בין היתר:
- עדכוני אפליקציות מהירים
- העלאת אמינות בגרסאות המוצר
- תהליכי שחרור קוד מהירים יותר
- שיפור בשיתוף הפעולה בפעולות ובין הצוותים
- סגירת חולשות ושיפור מדיניות אבטחה
לצד הענין הטכני של DevOps במקביל ישנה דרישה לבצע שינוי במדיניות הארגונית, כלומר באופי תהליכי הפיתוח, שינוי נהלים וכן הלאה, ולכן DevOps מבוסס על מאפיינים שונים כדוגמת:
- שיתופי פעולה בין הצוותים
- התאמת נהלים ושיטות עבודה
- מעבר לתצורת אינטגרציה רציפה
- אימוץ שיטות חדשות Micro-Services
- תשתית כקוד
DevOps לא נוגע רק למדיניות פיתוח ארגונית חדשה וחיזוק שיתופי הפעולה בין הצוותים השונים, אלא גם יישום נהלי פיתוח חדשים.
Continuous Integration (בקצרה CI), ולמעשה אינטגרציה מתמשכת היא שיטת עבודה שבה כל סביבות הפיתוח עוברות מיזוג עם מקום מרכזי משותף מספר פעמים ביום במטרה לנהל גרסאות שונות.
במצב של CI הרעיון הוא שאותו קוד מערכת יהיה כל הזמן במצב תקין, ולכן העקרון הראשון הוא שאינטגרציה של קוד וביצוע merge הוא הכלי האולטימטיבי לזהות שבירות במערכת – ולכן עליכם לבצע אינטגרציה כל הזמן.
Continuous Delivery (בקצרה CD), ולמעשה אספקה מתמשכת אשר מרחיבה את שיטת CI בכך שהיא מוודאת שהקוד או הפיתוח אשר עודכן זמין לפריסה, כתוצאה מכך אנו מקבלים תהליך פריסה מהיר יותר.
לאחר בדיקת תקינות הקוד אנו מוודאים שניתן לשלוח את השינוי ולבצע פריסה.
ולכן אם בוצע שינוי למשל קידוד באג או אפילו שינוי ויזואלי ולאחר מכן בוצעו בדיקות והם נמצאו תקינות, לאחר מכן יגיע השלב של דחיפת השינויים לקוד המקור וליצצור. במצב כזה אנו עלולים להגיע למספר עדכוני גרסאות בכל שבוע ואפילו בכל יום.
Continuous Deployment ומטרתו היא זהה לשיטת Continuous Delivery אך עם הבדל משמעותי של אוטומציה בפריסת השינוי בקוד והכוונה היא ברגע שנעשה שבוצע Review על הקוד והשינוי נפרס אוטומטית.
מידע נוסף לגבי CI\CD במאמר CI/CD וזה
מהו Azure DevOps
DevOps מהווה שינוי מתודולוגי ודורש שיתוף פעולה בין צוותי פיתוח, צוותי תפעול וצוות בדיקות, ולכן לא קיים כלי יחיד ובודד של DevOps, אלא משפחת כלים שעובדת על גבי מספר כלים ובאינטגרציה אחד עם השני.
באופן כללי, ניתן לסווג כלי DevOps לפי הקטגוריות הבאות של תהליכי פיתוח ופריסת תוכנה:
- תכנות (Code) ובשלב זה מבצעים את פיתוח הקוד וסקירה (code review), כולל שילוב של כלים לניהול ומיזוג גרסאות
- בנייה (Build) באמצעות כלים שונים ולטובת ביצוע continuous integration וכן לקבלת סטטוס של בניית התוכנה
- בדיקות (Test) לביצוע בדיקות תוכנה ומדידת הביצועים
- אריזה (Package) לאחסון תוצרי בנייה בינאריים (artifact repository), והכנת היישום לפריסה
- שחרור גרסאות (Release) ובשלב זה מבצעים ניהול שינויים, אישור הוצאת גרסאות, אוטומציה להוצאה של גרסאות
- תצורה (Configure) ובמצב זה מגדירים ניהול ותצורה של תשתיות
- מעקב וניטור (Monitor) ביצועים של היישום בזמן ריצה
למרות שקיימים כלים רבים, ישנן כמה קטגוריות של כלים שהן חיוניות להקמת תשתית DevOps, כדוגמת Docker, Jenkins, Puppet.
מכיוון שמדובר על קטגוריות שונות ועל סדרה של כלים מגוונים, כאן נכנס לתמונה הכלים של Azure DevOps.
Azure DevOps הוא סדרת של שירותי ענן וכלים המיועדים לניהול מחזור הפיתוח במערך DevOps, ובתשתית פתוחה וגמישה התומכת בכל סוג של מערכת ואפליקציה ואינה תלויה בפלטפורמה, אינה תלויה בשפות פיתוח או או אינה תחויה בשירותי ענן, ולכן מאפשרת ניהול משותף של שירותי ענן, שפות פיתוח, פלטפורמות וחשוב מכל שיתוף פעולה בין צוותי פיתוח, צוותי תפעול וצוות בדיקות.
כיום שירות Azure DevOps נחלק לחמישה שירותי ענן ורכיבים מרכזיים המספקים את כלל הכלים הנדרשים לביצוע DevOps בארגון.
הכלים הקיימים בשירות Azure DevOps הם:
Azure Boards מאפשר לנהל פרויקטים ותהליכים באמצעות מעקב ודיון של פעולות הצוותים, ניהול באמצעות לוחות שונים כדוגמת לוח Kanban, דיווח לגבי פעולות ודוחות מותאמים באופן אישי.
בין היתר ניתן לבצע את הפעולות הבאות:
- הוספה ועדכוני של משימות ופעולות
- הגדרת שאילתות עבור פעולות ויצירת תרשימי סטטוס
- ניהול Backlog של התהליך או האפליקציה
- תכנון ספרינטים באמצעות משימות ופעולות
- ממשך לסקירת המשימות והספרינטים
Azure Repos – שימוש בלתי מוגבל במאגרים (repos) של Git בענן המאפשרים ניהול משותף של קבצים וע”י כל מאפשרים שיתוף פעולה לבניית קוד טוב יותר עם בקשות משיכה וניהול קבצים מתקדם.
ניהול קוד ע”י Repos היא כלי חיוני לפרויקטים מרובי מפתחים, בגלל שמאפשר למפתחים לשתף פעולה בקוד, ולעקוב אחר שינויים שבוצעו.
Azure Repos תומך בשני סוגים של Source Control המאפשרים לבדוק קבצים ולארגן קבצים: Git או TFVC.
הפעולות שניתנות לביצוע הם בין היתר:
- סקירה, הורדה ועריכת קבצים
- מעבר על שינויים של המאגר כולל היסטוריה
- ניהול ודחיפת שינויים
- בדיקה, יצירה ואישור של הקוד
Azure Pipelines -הרכיב המרכזי שמטרתו היא בניה, בדיקה ופריסה באמצעות תהליכים מבוססים CI\CD שידועים לעבוד עם כל שפה, פלטפורמה וענן.
באמצעות Azure Pipeline ניתן לבנות ולבדוק אוטומטית פרוייקט פיתול וקוד, ולהנגיש אותו לצוותים אחרים.
Azure Test Plans – פתרון כולל לניהול בדיקות המאפשרות לעקוב ולהעריך את איכות הקוד דרך כל מחזור הפיתוח מול האפליקציה.
Azure Artifacts – מערכת לניהול חבילות פיתוח (packages), המאפשרת יצירה, ניהול ושיתוף חבילות כגון npm או Nuget עם שאר צוותי הפיתוח.
מאמרים נוספים
מאמרים נוספים של פייתון, VSCode:
מאמרים נוספים של Azure DevOps (יעלו בקרוב)
- תחילת עבודה עם Azure DevOps
- איך ליצור Azure Pipline
- אבטחה ותהליך פיתוח
