במאמר זה נלמד על DevOps וכיצד הוא שונה משיטת Agile. כמו כן, נסקור כמה כלים פופולריים ב-DevOps ותפקידם במחזור חיי ה-DevOps.
אתם תלמדו
- מה זה Docker, Kubernetes ו-Azure DevOps
- מה זה DevOps ולמה אנחנו צריכים את זה?
- איך DevOps שונה מ-Agile?
- מהם כמה כלים חשובים ב-DevOps?
- איך Docker עוזר ל-DevOps?
- איך Kubernetes עוזר ל-DevOps?
- איך Azure DevOps עוזר ל-DevOps?
- מה זו אינטגרציה רציפה ומשלוח רציף (CI/CD)?
- מה זה תשתית כקוד?
- איך Terraform ו-Ansible עוזרים ל-DevOps?
Docker
Docker הוא כלי תוכנה קוד פתוח המשמש לבניית, בדיקה והפצה של יישומים במיכלים. מה זו מיכליזציה, אגב? מיכליזציה היא המושג של אריזת כל הספריות והקבצים יחד עם קוד היישום ביחידה אחת הנקראת "מיכל" כך שהיא תוכל לרוץ על כל תשתית.
Kubernetes
קוברנטיס הוא מערכת אורקסטרציה של תוכניות בקונטיינרים שמנהלת אפליקציות תוכנה ושירותים בקונטיינרים. היא טופלת את המשימות שנעשות בסביבת הקונטיינרים כגון התרחבות, הצבת אפליקציות, איזון העומס ועוד. קוברנטיס היא ניידת, יעילה וכלכלית, ומציעה תכונות כמו שילובי מערכות, תמיכה ב-API ועוד.
אזור DevOps הוא מוצר של חברת מיקרוסופט שמספק מגוון רחב של כלים ותכונות שהופכים את תהליך פיתוח תוכנה והצבתה למהיר יותר ומאורגן יותר. הוא מציע סדרת תהליכים שמאפשרים למפתחי תוכנה, מנהלי פרויקט ותורמים אחרים לעבוד ביחד כדי לפתח תוכנה. ניתן להוסיף אותו לעורכים או לסביבות פיתוח משתמשים בהן כדי לאפשר לצוות לעבוד ביעילות על פרויקטים בכל גודלם.
בואו נתחיל עם מקרה שימוש פשוט.
קורסים חינמיים — למדו ב-10 שלבים
מהו DevOps?
כמו ברוב המילים החמות סביב פיתוח תוכנה, אין הגדרה מקובלת ל-DevOps.
ההגדרות משתנות מ-simple, כמו זו למטה, ל-complex, שיכולות להימשך עמוד שלם בספר.
DevOps היא השילוב של פילוסופיות תרבותיות, פרקטיקות וכלים שמגדילים את היכולת של ארגון לספק אפליקציות ושירותים במהירות גבוהה — Amazon Web Services (AWS)
במקום לנסות להגדיר את DevOps, נבין כיצד התפתח פיתוח התוכנה ל-DevOps.
מודל המפלים
מודל המפלים הוא מתודולוגיה שעוקבת אחר גישה מסודרת. הוא מורכב משישה שלבים: דרישות, עיצוב, יישום, בדיקה, פריסה, ותחזוקה. כל שלב מתבסס על סיום השלב הקודם. הוא מתפתח דרך שלבים אלו מבלי לחזור לתהליכים קודמים, מה שהופך אותו לתהליך ליניארי.
העשורים הראשונים של פיתוח תוכנה היו ממוקדים סביב מודל המפלים, והוא גישש לפיתוח תוכנה באותה דרך שבה היית גישש לבניית פרויקט נדל"ן — לדוגמה, בניית גשר.
תבנה תוכנה בכמה שלבים שיכולים לנוע בין כמה שבועות לכמה חודשים.
במרבית פרויקטי המפלים, יחלפו חודשים עד שהעסק יראה גרסה עובדת של אפליקציה.
מרכיבים מרכזיים לבניית תוכנה נהדרת
במהלך עבודתנו במודל המפלט, בהמשך שנים, הבנו מספר אלמנטים מרכזיים בפיתוח תוכנה מעולה:
- תקשורת
- משוב
- אוטומציה
חשיבות התקשורת
התקשורת בין אנשים היא חיונית להצלחת פרויקט תוכנה.
במודל המפלט, ניסינו לשפר את התקשורת על ידי כתיבת מסמכים בעשרות עמודים על דרישות, עיצוב, ארכיטקטורה ואיחסון.
אך, עם הזמן, גילינו כי:
- הדרך הטובה ביותר לשפר את התקשורת בקבוצה היא לאגור את האנשים ביחד. ולאגור מגוון של כישורים באותה צוות.
- צוותים צילומיים — עם מגוון רחב של כישורים — עובדים מצוין.
חשיבות המשוב המוקדם
קבלת משוב מהירה היא חשובה. בניית תוכנה מעולה היא על פי מהירות בקבלת משוב.
- האם אנו בונים אפליקציה שעומדת בציפיות העסקיות?
- האם האפליקציה שלך תהיה עם בעיות בהעלאה לייצור?
אתה לא רוצה לגלות את זה לאחר כמה חודשים. אתה רוצה לגלות זאת באופן מהיר ככל שניתן כי כך כל כך יותר קל לתקן בעיה.
גילינו כי צוותי התוכנה הטובים ביותר מורכבים כך שמאפשרים משוב מהיר.
חשיבות האוטומציה
האוטומציה חיונית. פיתוח תוכנה משלב רחב של פעילויות. לעשות דברים באופן ידני הוא איטי ומסוכן. אנו מבינים כי חשוב תמיד לחפש הזדמנויות להכניס אוטומציה.
הבנת הרכיבים המרכזיים לפיתוח תוכנה מעולה, בואו נסתכל על כיצד חלה התפתחות ל-Agile ול-DevOps.
התפתחות ל-Agile
Agile היא גישה שמדגישה התקדמות בהתרכזות, משוב תדיר ויכולת להגיב לדרישות משתנות באמצעות מחזור חיי הפיתוח. Agile מעודד צוותים צורתיים לעבוד במחזורי פיתוח קצרים, שמקדמים שיפור רציף ומספקים ערך למשתמשים במהירות. זו הייתה השלב הראשון בתהליך התפתחות כלפי מימוש הלמידות שלנו עם תקשורת משופרת בין הצוותים, קבלת משוב והבאת אוטומציה.
Agile הביא את העסקים וצוותי הפיתוח יחד לצוות אחד, שעובד לבנות תוכנה מעולה באיטרציות קטנות בשם ספרינטים.
במקום לבלות שבועות או חודשים בכל שלב של הפיתוח, Agile מתמקדת בקחת דרישות קטנות בשם סיפורי משתמשים דרך מחזור הפיתוח בתוך כמה ימים, לפעמים אפילו באותו היום.
איך Agile העצימה את התקשורת בין הצוותים?
Agile הביאה את העסקים וצוותי הפיתוח יחד.
- העסקים אחראים על הגדרת מה לבנות. מהן הדרישות?
- הפיתוח אחראי על בניית מוצר שעומד בדרישות. התפתחות כוללת את כל מי שמעורב בעיצוב, כתיבת קוד, בדיקות ואריזת התוכנה שלך.
באג'ייל, נציג מהעסק, הנקרא בעל מוצר, תמיד נוכח עם הצוות, והצוות מבין את המטרות העסקיות באופן ברור.
כאשר צוות הפיתוח אינו מבין את הדרישות והולך בדרך הלא נכונה, בעל המוצר עוזר להם לבצע תיקון כיוון ולהישאר על הדרך הנכונה.
תוצאה: המוצר הסופי שהצוות בונה הוא משהו שהעסק רוצה.
גורם חשוב נוסף הוא שהצוותים האג'יליים בעלי מיומנויות חוצות תחומים: מיומנויות קידוד (פרונט אנד, API, ומסדי נתונים), מיומנויות בדיקות, ומיומנויות עסקיות. זה משפר את התקשורת בין אנשים שצריכים לעבוד יחד כדי לבנות תוכנה נהדרת.
אג'ייל ואוטומציה
אילו תחומי אוטומציה מתמקדים בהם צוותים אג'יליים?
מוצרי תוכנה יכולים להיות להם מגוון של תקלות:
- תקלות פונקציונליות פירושן שהמוצר אינו פועל כמצופה.
- תקלות טכניות מקשות על תחזוקת התוכנה. לדוגמה, בעיות באיכות הקוד.
באופן כללי, צוותים אג'יליים מתמקדים בשימוש באוטומציה כדי למצוא תקלות טכניות ופונקציונליות מוקדם ככל האפשר.
צוותים אג'יליים גם מתמקדים באופן נרחב באיכות הקוד. כלים כמו SONAR משמשים להעריך את איכות הקוד של אפליקציות.
האם זה מספיק אם יש לך בדיקות אוטומציה נהדרות ובדיקות איכות קוד מעולות? המפתח הוא להפעיל את התהליכים הללו בתדירות. צוותי Agile מדגישים את האינטגרציה הרציפה, שבה הפקודות לשליטת גרסאות מפעילות סדרת פעולות. זה כולל את ביצוע בדיקות יחידה, בדיקות אוטומציה ובדיקות איכות קוד, הכל משולב בצורה חלקה בצינור האינטגרציה הרציפה. Jenkins, כלי CI/CD נפוץ בתקופה המוקדמת של Agile, שיחק תפקיד מרכזי באורכסטרציה של תהליכים אוטומטיים אלה.
כיצד קידם Agile משוב מיידי?
הגורם החשוב ביותר הוא שעסק לא צריך לחכות חודשים כדי לראות את המוצר הסופי. בסוף כל ספרינט, המוצר מוצג לכל הצדדים, כולל צוותי ארכיטקטורה ועסקיים. כל המשוב נלקח בחשבון בזמן שמתווספים סיפורי משתמש עבור הספרינט הבא. תוצאה: המוצר הסופי שהצוות בונה הוא משהו שהעסק רוצה.
גורם נוסף שמאפשר משוב מיידי הוא אינטגרציה רציפה. נניח שאני מבצע קוד מסוים בשליטת גרסאות. בתוך 30 דקות, אני מקבל משוב אם הקוד שלי גורם לכשל בבדיקת יחידה או בבדיקת אינטגרציה. אני אקבל משוב אם הקוד שלי אינו עומד בתקני איכות הקוד או אין לו מספיק כיסוי בבדיקות היחידה.
האם Agile הצליח? כן. ללא ספק. על ידי התמקדות בשיפור התקשורת בין צוותי העסק והפיתוח, והתמקדות בגילוי מגוון פגמים בשלב מוקדם, Agile הביא את פיתוח התוכנה לרמה הבאה.
חוויתי חוויה נהדרת בעבודה עם כמה צוותים מדהימים תוך שימוש בשיטת אג'ייל. הנדסת התוכנה, אשר עבורי מייצגת את כל המאמצים בבניית תוכנה מהדרישות ועד להעלאת אפליקציות לאוויר, לראשונה, הייתה מהנה כמו תכנות.
אבל האם האבולוציה נעצרת? לא.
אתגרים חדשים צצו.
אבולוציה של ארכיטקטורות מיקרו-שירותים
התחלנו לנוע לעבר ארכיטקטורת מיקרו-שירותים, והתחלנו לבנות כמה APIs קטנים במקום לבנות אפליקציות מונוליתיות גדולות.
מה היה האתגר החדש?
הפעולות הפכו להיות יותר חשובות. במקום לבצע שחרור אחד מונוליתי בחודש, אתם מבצעים מאות שחרורים קטנים של מיקרו-שירותים בכל שבוע. ניפוי בעיות בין מיקרו-שירותים והשגת שקיפות לגבי מה שמתרחש עם המיקרו-שירותים הפכו להיות חשובים.
הגיע הזמן למונח חדש בפיתוח תוכנה. דב-אופס.
הופעת דב-אופס
מה היה המוקד של דב-אופס?
המוקד של דב-אופס היה לשפר את התקשורת בין צוותי הפיתוח לצוותי התפעול.
- איך נקל על הפריסות?
- איך נעשה את העבודה שהצוות התפעולי עושה יותר גלויה לצוות הפיתוח?
איך דב-אופס שיפר את התקשורת בין הצוותים?
דב-אופס קרב את צוותי התפעול לצוותי הפיתוח.
- בארגונים בשלים יותר, צוותי הפיתוח והפעולות עבדו כצוות אחד. הם התחילו לשתף מטרות משותפות ושני הצוותים התחילו להבין את האתגרים שהצוות השני נתקל בו.
- בארגונים, בשלב ההתחלתי של התפתחות DevOps, נציג מצוות הפעולות יכול להיות מעורב בספרינטים — עמידות ורטרוספקטיבות.
אילו תחומי אוטומציה צוותי DevOps מתמקדים בהם?
בנוסף לתחומי ההתמקדות של Agile — אינטגרציה רציפה ואוטומציה של בדיקות — צוותי DevOps התמקדו בעזרה באוטומציה של מספר פעילויות צוות הפעולות כמו הקצאת שרתים, קונפיגורציה של תוכנה על שרתים, פריסת יישומים, ומעקב אחרי סביבות ייצור. כמה מונחים מרכזיים הם פריסה רציפה, מסירה רציפה, ותשתית כקוד.
פריסה רציפה עוסקת בפריסה מתמדת של גרסה חדשה של תוכנה בסביבות בדיקה. בארגונים אפילו יותר בשלים כמו גוגל ופייסבוק, מסירה רציפה עוזרת בפריסה מתמדת של תוכנה לייצור — אולי מאות פריסות ייצור ביום.
תשתית כקוד עוסקת בטיפול בתשתית שלך כמו שאתה מטפל בקוד היישום שלך. אתה יוצר את התשתית שלך — שרתים, מאזן עומסים, ובסיסי נתונים — בצורה אוטומטית באמצעות קונפיגורציה. תבצע בקרת גרסאות על התשתית שלך — כך שתוכל לעקוב אחרי שינויים בתשתית שלך לאורך זמן.
איך DevOps קידם משוב מיידי?
DevOps מקשר בין צוותי הפיתוח והתפעול. מאחר שהתפעול והפיתוח הם חלק מאותו צוות, כל הצוות מבין את האתגרים הקשורים לתפעול ולפיתוח.
- כל בעיה תפעולית מקבלת תשומת לב מהירה מצד הפיתוח.
- כל אתגר בהעלאת התוכנה לאוויר מקבל את תשומת לב הצוות לתפעול במוקדם.
DevOps מעודד אינטגרציה רציפה, מסירה רציפה, ותשתיות כקוד.
- בגלל מסירה רציפה, אם אני עושה שינוי בקוד או בהגדרת התצורה שעשוי לשבור בדיקה או סביבת ניסיון, אני אדע זאת בתוך מספר שעות.
- בגלל תשתיות כקוד, מפתחים יכולים להפעיל סביבות באופן עצמאי, להעלות קוד, ולמצוא בעיות בעצמם בלי עזרה מצוות התפעול.
אני רואה את Agile ו-DevOps כשני שלבים שעוזרים לנו לשפר איך אנו בונים תוכנה מעולה. הם לא מתחרים זה נגד זה, אלא ביחד הם עוזרים לנו לבנות מוצרי תוכנה מדהימים.
כפי שאני רואה את זה, המטרה של Agile ו-DevOps ביחד היא לעשות דברים ש:
- מקדמים תקשורת ומשוב בין צוותי העסקים, הפיתוח והתפעול
- מקלים על הנקודות הכואבות עם אוטומציה.
סיפור של DevOps
הנה דוגמה לסיפור:
- אתה המפתח המוביל בצוות, ואתה צריך לבצע תיקון מהיר.
- אתה הולך למאגר GitHub.
- אתה במהירות מתאגד לפרויקט.
- אתה עושה שינוי. אתה בודק אותו. אתה מעדכן את בדיקות היחידה והאוטומציה.
- אתה מתחייב לזה.
- אתה מקבל אימייל שאומר שזה הושק ל-QA.
- כמה בדיקות אינטגרציה מתבצעות אוטומטית.
- צוות ה-QA שלך מקבל אימייל שמבקש אישור. הם עושים בדיקה ידנית ומאשרים.
- הקוד שלך חי בייצור תוך כמה דקות.
- אתה עשוי לחשוב שזה תרחיש אידיאלי. אבל, האם אתה יודע שזה מה שקורה בעסקים חדשניים כמו נטפליקס, אמזון וגוגל יום ביומו?
זו הסיפור של DevOps.
DevOps = פיתוח + תפעול
DevOps היא אבולוציה טבעית של פיתוח תוכנה. DevOps היא לא רק כלי, מסגרת או פשוט אוטומציה. זו קומבינציה של כל אלה.
DevOps מתמקדת באנשים, תהליכים ומוצרים. הצד האנושי של DevOps עוסק בתרבות וביצירת חשיבה נהדרת – תרבות שמעודדת תקשורת פתוחה ומעריכה משוב מהיר, תרבות שמעריכה תוכנה באיכות גבוהה.
אג'יל עזר לגשר על הפער בין צוותי עסקים לצוותי פיתוח. צוותי הפיתוח הבינו את העדיפויות של העסק ועבדו עם העסק כדי לספק את הסיפורים שמספקים את הערך הגבוה ביותר קודם; עם זאת, צוותי הפיתוח והאופרציה לא היו מסונכרנים.
היו להם מטרות שונות.
- המטרה של צוות הפיתוח היא לקחת כמה שיותר תכונות חדשות לייצור.
- מטרת צוות האופס הייתה לשמור על סביבת הפקודה כמיטבית.
כפי שתוכלו לראות, אם להעביר דברים לפקודה קשה, פיתוח ואופס אינם מיושרים.
DevOps נוקטת במטרה ליישר את צוותי הפיתוח והאופס עם מטרות משותפות.
צוות הפיתוח עובד יחד עם צוות האופס כדי להבין ולפתור את האתגרים האופרטיביים. צוות האופס הוא חלק מצוות הסקראם ומבין את התכונות שבפיתוח.
כיצד נוכל להפוך זאת לאפשרי? להרס את הגדר בין פיתוח ואופס!
הבאת פיתוח ואופס לעבוד ביחד
אפשרות 1
בארגונים בוגרי DevOps, פיתוח ואופס עובדים כחלק מאותו צוות סקראם וחולקים אחריות זה בזה.
אפשרות 2
אם נמצאים בשלבים הראשונים של התפתחות DevOps, כיצד נכול להביא את פיתוח ואופס להגיע למטרות משותפות ולעבוד ביחד?
הנה כמה דברים שניתן לעשות:
- הרכיבו את צוות הפיתוח לשתף פעולה בחלק מהאחריות של צוות האופס. לדוגמה, צוות הפיתוח יכול לקחת על עצמו אחריות על גרסאות חדשות לשבוע הראשון לאחר ההעברה לפרודוקשן. זה יעזור לצוות הפיתוח להבין את האתגרים שנתקלים בהם אופרציה בהעברת גרסאות חדשות לאוויר ויעזור להם להתקרב זה לזה ולמצוא פתרונות טובים יותר.
- דבר נוסף שניתן לעשות הוא לשתף נציג מצוות האופס בפעילויות הסקראם. השתתפותם בסטנדאפים וברטרוספקטיבס.
- הדבר הבא שאתה יכול לעשות הוא להפוך את האתגרים שהצוות התפעולי נתקל בהם ליותר גלויים לצוות הפיתוח. כשאתה נתקל באתגרים כלשהם בתפעול, הפוך את צוותי הפיתוח לחלק מהצוותים שעובדים על פתרונות.
באיזו דרך שתבחר, מצא דרכים לפרוץ את החומה ולקבץ את צוותי הפיתוח והתפעול.
אפשרות מעניינת נוספת עולה בזכות האוטומציה. באמצעות תשתית כקוד ואפשרות לספק את עצמם עבור המפתחים, אתה יכול ליצור שפה משותפת שצוותי התפעול והפיתוח מבינים — קוד.
מקרה שימוש ב-DevOps
שקול את התמונה למטה:
תמונה זו מציגה שני תהליכי עבודה פשוטים
- תשתית כקוד באמצעות Terraform ו-Azure DevOps כדי לספק אשכולות Kubernetes.
- פריסה רציפה של מיקרו-שירותים באמצעות Azure DevOps כדי לבנות ולפרוס דימויי Docker עבור מיקרו-שירותים לאשכולות Kubernetes.
האם זה נשמע מורכב?
בוא נפרק את זה וננסה להבין אותם.
נח开始 עם #2 — פריסה רציפה קודם.
#2: DevOps פריסה רציפה עם Azure DevOps ו-Jenkins
מה השימוש בבדיקות נהדרות ובדיקות איכות קוד אם אתה לא מריץ אותן לעיתים קרובות?
מה השימוש באוטומציה של פריסה אם אתה לא פורש תוכנה לעיתים קרובות מספיק?
ברגע שמפתח מתחייב לקוד במערכת ניהול גרסאות, הצעדים הבאים מתבצעים:
- בדיקות יחידה
- בדיקות איכות קוד
- בדיקות אינטגרציה
- אריזת אפליקציות — בניית גרסה שניתנת להתקנה של האפליקציה. כלים — Maven, Gradle, Docker
- הטמעת אפליקציות — העלאת אפליקציות חדשות או גרסאות חדשות של האפליקציה לאוויר
- דוא"ל לצוות הבדיקות כדי לבדוק את האפליקציה
כשיש אישור מצוות הבדיקות, האפליקציה מוטמעת מיידית לסביבה הבאה
זה נקרא הטמעה רציפה. אם אתה ממשיך להטמיע עד לסביבת הייצור, זה נקרא מסירה רציפה
הכלים ל-CI/CD הפופולריים ביותר הם Azure DevOps ו-Jenkins
#1: תשתיות כקוד עם Terraform
לפני שנה, השתמשנו ליצירת סביבות והטמעת אפליקציות באופן ידני
בכל פעם שיש ליצור שרת, זה צריך להתבצע ידנית
- צריך לעדכן את גרסת התוכנה
- חובה להתקין תיקוני אבטחה באופן ידני
אתה עושה זאת באופן ידני, והתוצאות הן:
- סיכוי גבוה של שגיאות
- סביבות שכפול קשות
תשתיות כקוד
תשתיות כקוד — לטפח את התשתיות באותו אופן כמו קודי האפליקציה
להלן כמה מהנקודות החשובות להבנה בנושא תשתיות כקוד:
- צוות התשתיות מתמקד בעבודה המוסיפה ערך (במקום עבודה רגילה)
- פחות שגיאות ושחזור מהיר מתקלות
- השרתים עקביים (ממניעת תזוזת תצורה)
הכלים הפופולריים ביותר ל-IaC הם Ansible ו-Terraform.
בדרך כלל, אלה הצעדים ב-Infrastructure as Code (IaC):
- פריסת שרתים (מופעל על ידי ענן) מתבנית
- התקנת תוכנה
- קונפיגורציית תוכנה
פריסת שרתים
בדרך כלל, משתמשים בכלי פריסה כדי לפרוס שרתים ולהכין את השרת החדש עם יכולות רשת. הכלים הפופולריים ביותר לפריסה הם Cloud Formation ו-Terraform.
באמצעות Terraform, ניתן לפרוס שרתים ואת שאר התשתית שלך, כמו מאזן עומסים, מסדי נתונים, קונפיגורציית רשת, וכו'. אתה יכול ליצור שרתים באמצעות תמונות שהוכנו מראש שנוצרו באמצעות כלים כמו Packer ו-AMI (תמונת מכונה של אמזון).
ניהול קונפיגורציה
כלי ניהול קונפיגורציה משמשים ל:
- התקנת תוכנה
- קונפיגורציית תוכנה
כלי ניהול קונפיגורציה פופולריים הם Chef, Puppet, Ansible ו-SaltStack. כלים אלה מיועדים להתקנה ולניהול תוכנה על שרתים קיימים.
תפקיד Docker ו-Kubernetes ב-DevOps
בעולם המיקרו-שירותים, כמה מיקרו-שירותים עשויים להיות בנויים ב-Java, כמה ב-Python, וכמה ב-JavaScript.
מיקרו-שירותים שונים יהיו להם דרכים שונות לבנות יישומים ולפרוס אותם על שרתים. זה מקשה על עבודת צוות התפעול. איך נוכל שיהיה לנו אופן דומה לפרוס סוגים שונים של יישומים? הכנסו קונטיינרים ודוקר.
באמצעות דוקר, אתה יכול לבנות תמונות של מיקרו-שירותים — ללא קשר לשפת התכנות שלהם. אתה יכול להריץ את התמונות הללו באותה דרך על כל תשתית. זה מפשט את התפעול.
Kubernetes מוסיף לזה על ידי עזרה באורכסטרציה של סוגים שונים של תופסים ופיתוחם לאשפוזים.
Kubernetes גם מספק:
- גילוי שירות
- איזון משאבים
- תצורה מרכזית
Docker ו־Kubernetes הופכים את DevOps לקל.
מדדי DevOps חשובים
הנה כמה מהמדדים החשובים של DevOps שניתן לעקוב אחריהם ולשפרם במהלך זמן מסוים.
- תדירות ההטמעה — כמה פעמים יישארו היישומים ביצור לייצור?
- זמן לשוק — כמה זמן אתה צריך כדי לקחת תכונה מהקידוד לייצור?
- שיעור כשלונות בהטמעות חדשות — כמה מההטמעות שלך נכשלות?
- זמן מוביל לתיקונים — כמה זמן אתה צריך כדי לבצע תיקון לייצור ולשחרר אותו לייצור?
- זמן ממוצע לשחזור — כמה זמן אתה לוקח לשחזר את סביבת הייצור שלך מבעיה גדולה?
שיטות מובילות של DevOps
ניהול פרויקט אג'ייל
ניהול פרויקט אג'ייל הוא גישה איטרטיבית לפיתוח יישומי תוכנה. דרך שיטה זו, צוותים יכולים לשפר את מהירות הפיתוח ולהגיב בצורה יעילה לצרכי הלקוח. מתודולוגית ה־Agile שונה משיטת ה־Waterfall המסורתית שבה היו מחזורי הוצאה ארוכים. Agile משתמשת במסגרות Scrum ו־Kanban כדי לספק את התוכנה לפי צרכי הלקוח.
שימוש במערך הכלים הנכון
מפתחי תוכנה ומנהלי מערכות צריכים לבחור ולהשתמש בערכת הכלים הנכונה של DevOps בכל שלב במחזור חיי DevOps כדי לבנות אפליקציות בעלות ערך גבוה.
להלן כמה דוגמאות לכלים שמהנדסי DevOps, מנהלי מערכות ואחרים יכולים להשתמש בהם:
- כלים כמו Jira יכולים לעזור לצוות להפריד משימות לחלקים קטנים ומנוהלים יותר וכך לסייע בהגברת הפרודוקטיביות של הצוות.
- כלים כמו Jenkins ו-Bitbucket יכולים לעזור לך לאוטומט את זרימות הקוד החל משלב הבדיקה ועד שלב ההפצה.
- כלים כמו Slack, GetFeedback וכו' יכולים לעזור לצוותי DevOps לשלב כלים לצ'אט עם פלטפורמות סקרים כדי לאסוף ולסקור משוב בזמן אמת.
אינטגרציה מתמשכת/הפצה מתמשכת
אינטגרציה מתמשכת (CI) והפצה מתמשכת (CD) הן שיטות מודרניות לפיתוח תוכנה שעוזרות לארגונים לשחרר תוכנה במהירות וביעילות. עם CI, מפתחים מחויבים באופן מתמשך לקוד האפליקציה במאגר משותף מספר פעמים. עם CD, הקוד מועבר לייצור במהירות וללא תקלות. CD גם מבטיחה שהאינטגרציה מתבצעת ללא עיכובים או תקלות.
אינטגרציה של אבטחה
אבטחה היא חלק חשוב מתהליך פיתוח התוכנה. בעולם הנוכחי, שבו פשעי סייבר ואירועי פריצה לנתונים נמצאים במגמת עלייה, ארגונים מבינים את החשיבות של שילוב אבטחה במערכות שלהם. בעבר, אבטחה נחשבה בדרך כלל בשלב האחרון של מחזור חיי הפיתוח של תוכנה, אך עם הופעת DevSecOps, אבטחה נחשבת ומשולבת מהיום הראשון של פיתוח היישום.
נראות
נראות היא חשובה בעת פיתוח יישומים מורכבים שמשתמשים במיקרו-שירותים ובארכיטקטורות ענן. נראות מסייעת לצוותי DevOps להבין את המבנה המורכב של יישומים שונים (מיקרו-שירותים, יישומי ענן וכו') ועוזרת להתמודד עם הצרכים העתידיים של הסביבה. נראות בקוברנטיס ו-Splunk הם חלק מהפלטפורמות הנראות הטובות ביותר.
סימני בשלות DevOps
איך מודדים את הבשלות של יישומי DevOps שלך?
- הזמן שדרוש מתהליך הפיתוח ועד ההפצה צריך להיות מספק באופן כללי
- קביעת תדירות ההפצה של קוד חדש
- זמן ממוצע לשחזור (MTTR) מאירוע או מקרה בלתי צפוי צריך להיות נמוך ככל האפשר
- הפצות מוצלחות צריכות לעלות על הפצות כושלות
- שחרורים מהירים ואמינים צריכים להביא להחזר רווח משמעותי (ROI).
שיטות מיטב התרגום של DevOps Transformation
- קניין מנהיגה הוא קריטי
- כולל עלויות ראשוניות
- הקמת מרכזי מומחים לסייע לצוותים
- בחירת היישום והצוות הנכון
- התחל בקטן
- שיתוף ידע (ניוזלטרים, תקשורת, מרכזי מומחים)
- עידוד צוותים בידע ומודעות לאוטומציה
- הכרה בצוותי DevOps
Source:
https://dzone.com/articles/devops-tutorial-devops-with-docker-kubernetes-and