streamalism.org

1. סקירה כללית

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

2. הקשר היסטורי

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

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

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

זה הוליד עולם חדש לגמרי של מתודולוגיות פיתוח תוכנה שנראות בחופשיות מתחת למטריית Agile. המניפסט הזריז קובע מערך עקרונות שיש לעקוב אחריו אספקת תוכנה במרווחים קטנים עם לולאת משוב מהירה יותר. ישנן מספר מסגרות זריזות כמו Scrum ו- Kanban בפועל.

3. מה זה DevOps?

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

מתודולוגיות זריזות ממשיכות לזקק את עצמן כאשר הן שואפות ללא הרף לשבור ממגורות.

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

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

התרשים הבא מסביר זרימת עבודה אפשרית לתרגול DevOps:

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

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

4. איך להתחיל את המסע?

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

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

4.1. מוֹטִיבָצִיָה

רק בגלל שיש פרקטיקה פופולרית שם לא בהכרח הופכת אותו למתאים לנו. עלינו להבין את המוטיבציה שלנו לכל שינוי - יותר מכך אם אנו מבצעים שינוי לכיוון זריז. שֶׁלָה שימושי להצגה על ידי הגדרת המטרות שאנו רוצים להשיג.

היעדים של DevOps בכל ארגון תלויים בשאיפה, התרבות והבגרות של אותו ארגון. להלן כמה מהיעדים הנפוצים יותר של DevOps:

• חוויה טובה יותר למשתמשי הקצה
• זמן מהיר יותר לשוק
• זמן ממוצע משופר להחלמה

4.2. אימוץ

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

• להבין היטב את מצב הרעיון הנוכחי למחזור הייצור
• אספו חלק מצווארי הבקבוק הברורים והשתמשו במדדים לקבלת החלטות עובדתיות
• עדיפות על צווארי הבקבוק שיוסיפו את הערך הרב ביותר בעת הסרתם
• הגדר תוכנית איטרטיבית למסירת ערך באופן הדרגתי עבור פריטים בעדיפות
• עקוב אחר המחזורים הקצרים של Develop-Deploy-Measure כדי להשיג את המטרות

5. תרגולי DevOps

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

5.1. תכנון זריז

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

לאחר מכן, יש לשבור אותו באיטרציה של תוספות קצרות אך מתפקדות.

5.2. תשתית כקוד (IaC)

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

5.3. בדיקת אוטומציה

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

5.4. שילוב מתמשך (CI)

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

5.5. אספקה ​​/ פריסה רציפה (CD)

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

5.6. ניטור רציף

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

רשימה זו רחוקה מלהיות שלמה ומתפתחת כל העת. צוותים המתאמנים ב- DevOps מגלים ברציפות דרכים טובות יותר להשיג את יעדיהם. כמה מהנוהגים האחרים שכדאי להזכיר הם Containerization, Cloud-Native Development ו- Microservices, עד כמה שם.

6. כלי המסחר

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

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

6.1. תִכנוּן

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

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

6.2. התפתחות

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

בואו נסתכל על כמה מהכלים בכל מקום בתחום זה.

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

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

Slack היא פלטפורמת מסרים מיידיים שפותחה על ידי Slack Technologies. כפי שדנו, זריז צוותים צריכים להיות מסוגלים לשתף פעולה ולתקשר, רצוי בזמן אמת. מלבד הודעות מיידיות, Slack מציע דרכים רבות לתקשר עם משתמש יחיד או קבוצת משתמשים - והוא משתלב היטב עם כלים אחרים כמו Jira ו- GitHub!

6.3. שילוב

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

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

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

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

6.4. מְסִירָה

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

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

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

שף / בובה / Ansible הם כלי ניהול תצורה. כידוע, מופע פועל בפועל של יישום תוכנה הוא שילוב של בניית קוד הבסיס ותצורותיו. ולמרות שבניית קוד הבסיס לעיתים אינה ניתנת לשינוי בין סביבות, תצורות אינן משתנות. זה איפה אנו זקוקים לכלי ניהול תצורה כדי לפרוס את היישום שלנו במהירות ובמהירות. ישנם כמה כלים פופולריים במרחב זה, שלכל אחד מהם יש את המוזרויות שלהם, אך השף, הבובה וה- Ansible די מכסים את הבסיסים.

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

6.5. ניטור

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

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

Elastic-Logstash-Kibana (ELK) היא ערימה של שלושה פרויקטים של קוד פתוח - חיפוש אלסטיקה, לוגסטאש וקיבנה. Elasticsearch הוא מנוע חיפוש וניתוח הניתנים להרחבה. Logstash מספק לנו צינור לעיבוד נתונים בצד השרת המסוגל לצרוך נתונים ממגוון רחב של מקורות. לבסוף, קיבאנה עוזר לנו להמחיש נתונים אלה. יחד, הערימה הזו יכולה להיות משמש לצבירת נתונים כמו יומני כל היישומים ולנתח אותם בזמן אמת.

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

7. הרחבות DevOps (או שהן באמת!)

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

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

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

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

7.1. DevTestOps

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

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

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

7.2. DevSecOps

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

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

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

8. מסקנה

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

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

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