DevOps
 |
ערך מחפש מקורות
| |
| ערך מחפש מקורות |
| הנדסת תוכנה |
|---|
| ערך זה שייך לקטגוריית הנדסת תוכנה |
| פעילויות ושלבים |
| דרישות • ניתוח • אפיון • ארכיטקטורה • עיצוב • תכנות • ניפוי שגיאות • בדיקה • אימות • בנייה • פריסה • תפעול • תחזוקה |
| מתודולוגיות |
| זריזות • מפל המים • תכנת ותקן • Crystal Clear • Scrum • Unified Process • Extreme Programming • אינטגרציה רציפה • DevOps |
| תחומים תומכים |
| ניהול פרויקטים • ניהול תצורה • תיעוד • הבטחת איכות • Profiling |
| כלים |
| מהדר • מקשר • מפרש • IDE • ניהול גרסאות • אוטומציית בנייה |
בפיתוח תוכנה, DevOps היא תרבות ארגונית ומתודולוגיית עבודה אשר שמה דגש על שיתוף הפעולה והתקשורת בין מפתחי התוכנה לבין שאר אנשי ה-IT שבחברה. השיטה דוגלת בביצוע אוטומציה של תהליכי אספקת התוכנה (delivery) ושל שינויים בתשתיות. מקור המילה DevOps הוא מראשי התיבות של המילים האנגליות development (פיתוח) ו-operations (תפעול). מטרת השיטה לכונן תרבות וסביבה שבהן בנייה, בדיקות והוצאה לאור של גרסאות תוכנה יכולים להתבצע במהירות[1], לעיתים קרובות ובאופן אמין יותר. שיטות ה-DevOps המודרניות כוללות פיתוח מתמשך (continuous development), בדיקות מתמשכות, אינטגרציה מתמשכת, פריסה רציפה וניטור רציף של יישומי תוכנה לאורך כל מחזור חיי הפיתוח שלה. פרקטיקת ה-CI/CD או צינור ה- CI/CD (או Pipeline) מהווים את עמוד השדרה של פעולות DevOps המודרניות.
בארגונים מסורתיים, המורכבים מבעלי תפקידים המתמחים בביצוע פונקציות ספציפיות, שיתוף פעולה בין המחלקות שאחראיות על הפעולות שתוארו למעלה, לבין פעילויות התפעול של ה-IT הוא נדיר. גישת ה-DevOps מקדמת תהליכים ושיטות שמטרתם לחשוב על תקשורת ושיתוף פעולה בין צוותי הפיתוח, אבטחת המידע, ה-QA וה-IT.
כלים
מכיוון ש-DevOps מהווה שינוי תרבותי ודורש שיתוף פעולה בין הפיתוח, התפעול והבדיקות, לא קיים כלי יחיד של DevOps. במקום זאת קיימת "שרשרת כלי DevOps", המורכבת מכלים שונים רבים. באופן כללי, כלים ל-DevOps ניתנים לסיווג בין אחת או יותר מהקטגוריות הבאות של תהליכי פיתוח ופריסת תוכנה:
- תכנות (code) – פיתוח הקוד וסקירה שלו (code review), כלים לניהול ומיזוג גרסאות
- בנייה (build) – כלים ל-continuous integration ולקבלת סטטוס של בניית התוכנה
- בדיקות (test) – בדיקות תוכנה ומדידת הביצועים
- אריזה (package) – אחסון תוצרי בנייה בינאריים (artifact repository), הכנת היישום לפריסה
- הוצאה לאור (release) – ניהול שינויים, אישור הוצאה לאור של גרסאות, אוטומציה להוצאה לאור של גרסאות
- תצורה (configure) – הגדרה וניהול תצורה של תשתיות
- ניטור (monitor) – ניטור ביצועים של היישום בזמן ריצה, חוויית משתמש
אף על פי שקיימים כלים שונים רבים, ישנן כמה קטגוריות של כלים שהן חיוניות להקמת תשתית DevOps. כלים כמו Docker, Kubernetes, Ansible, Terraform, Jenkins, Puppet, JFrog ו-Vagrant, בשילוב עם שירותי ענן ציבורי כמו AWS, Microsoft Azure ו-GCP ותכנות בשפות כמו פייתון הם דוגמאות לכלים פופולריים המשמשים בשרשרת הכלים של DevOps.
DevOps בהשוואה ל-Agile ו-Continuous delivery
בארגונים אשר אימצו את גישת פיתוח תוכנה זריז (Agile) חלה עלייה בכמות גרסאות התוכנה היוצאות לאור. במקור, שיטת ה-DevOps נוצרה מהעלייה בפופולריות של פיתוח זריז. שיטות ה-Agile ו-DevOps דומות אך שונות במספר היבטים חשובים: Agile מהווה שינוי בצורת החשיבה, בעוד ש-DevOps מיישמת שינוי בתרבות הארגונית הלכה למעשה. אחת המטרות של DevOps היא לייסד סביבה בה יכולים להתקיים הוצאות לאור של גרסאות תוכנה אמינות יותר ובקצב גבוה יותר. מנהלים האחראים על הוצאות לאור של גרסאות מתחילים להשתמש בכלים כגון אוטומציה להוצאות לאור של גרסאות וכלים ל-continuous integration כדי לסייע בקידום מטרה זו. כל זה נעשה תוך יישום גישת ה-continuous delivery ("אספקת תוכנה מתמשכת").
למושגים Continuous delivery ו-DevOps משמעות דומה, ולעיתים קרובות מבלבלים ביניהם, אך עם זאת אלו הן שתי תפישות שונות. גישת ה-DevOps רחבה יותר, והיא מתמקדת בשינוי תרבותי, ובפרט בשיתוף הפעולה בין הצוותים השונים שלוקחים חלק באספקה (delivery) של התוכנה (פיתוח, IT ,QA, הנהלה וכולי), כמו גם האוטומציה של תהליכי אספקת התוכנה. בהשוואה לכך, continuous delivery היא גישה אשר מתמקדת באוטומציה של הוצאה לאור של גרסאות, חיבור בין התהליכים השונים, וביצוע מהיר ותכוף יותר שלהם. המטרות הסופיות של שתי הגישות הן זהות ולעיתים קרובות משלבים ביניהן להשגת מטרות אלו. גישות ה-DevOps וה-continuous delivery באות מאותו רקע של שיטות עבודה זריזות ו"חשיבה רזה": ביצוע של שינויים קטנים ומהירים עם התמקדות בתועלת עבור הלקוח הסופי. השיטות מתבססות על תקשורת ושיתופי פעולה פנימיים איכותיים, ובכך מסייעות להשיג זמנים קצרים להוצאה לאור של התוכנה לשוק (time to market), תוך הפחתת סיכונים.
אימוץ שיטת ה-DevOps והיחס לארכיטקטורת תוכנה
את אימוץ גישת ה-DevOps מקדמים פקטורים רבים, בהם:
- שימוש בשיטות פיתוח זריזות (agile) ומתודולוגיות נוספות של פיתוח תוכנה
- דרישה מבעלי העניין ביחידות העסקיות השונות להגברת קצב שחרור גרסאות מוכנות לייצור
- זמינות רחבה של תשתיות וירטואליזציה וענן מצדם של ספקים פנימיים וחיצוניים
- שימוש נרחב באוטומציה בחוות השרתים (data centers) וכלים לניהול תצורה
- דגש מיוחד על אוטומציה של בדיקות ושיטות של continuous integration
- מסה קריטית של שיטות עבודה מומלצות (best practices) ידועות היטב
- דגש על עבודה בצורת Infrastructure as Code, שבה התשתית מתוארת באמצעות קוד
ארכיטקטורה
אף על פי שתאורטית ניתן ליישם את גישת ה-DevOps יחד עם כל ארכיטקטורת תוכנה, ארכיטקטורת ה-microservices (מיקרו-שירותים) הופכת לתקן עבור מערכות המתוכננות ל"פריסה מתמשכת" (continuous deployment). מכיוון שכל שירות הוא קטן, הדבר מאפשר לארכיטקטורה של כל שירות להתפתח בתהליך של continuous refactoring (ארגון הקוד מחדש באופן מתמשך), ובכך להפחית את הצורך בתכנון נרחב מראש, ומאפשר הוצאה לאור מוקדמת ומתמשכת של התוכנה.
ראו גם
הערות שוליים
- ^ What is DevOps?, about.gitlab.com (באנגלית אמריקאית)
37697956DevOps