שבע הטעויות הנפוצות ביותר בעת מעבר ל-CI/CD

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

קבוצה פתרונות ענן של Mail.ru תרגם את המאמר הימנע מהמלכודות הנפוצות הללו בעת המעבר ל-CI/CD מאת יסמין צ'וקשי עם תוספות.

חוסר מוכנות לשינוי תרבות ותהליכים

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

תרשים מחזור אינסופי של DevOps

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

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

חוסר משוב

יעילות DevOps תלויה במשוב מתמיד. שיפור מתמיד הוא בלתי אפשרי אם אין מקום לשיתוף פעולה ותקשורת.

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

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

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

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

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

אי הבנה של השלמת שלב

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

Definition of Done (DoD) הוא כלי רב עוצמה בהקשר של CD DevOps/CI. זה עוזר להבין טוב יותר את תקני האיכות של מה ואיך הצוות בונה.

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

DoD הופך את התהליך לשקוף יותר ומקל על הטמעת CI/CD אם הוא מובן על ידי כל חברי הצוות ומסוכם הדדי.

היעדר יעדים ריאליים ומוגדרים בבירור

זו אחת העצות המצוטטות בתדירות הגבוהה ביותר, אך ראוי לחזור עליה. כדי להצליח בכל מאמץ גדול, כולל CI/CD או DevOps, עליך להגדיר יעדים ריאליים ולמדוד ביצועים מולם. מה אתה מנסה להשיג עם CI/CD? האם זה מאפשר שחרורים מהירים יותר עם איכות טובה יותר?

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

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

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

עבור ארגונים רבים, CI לבדו מספיק, ויש ליישם CD רק אם הוא מוסיף ערך.

היעדר לוחות מחוונים ומדדים מתאימים

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

דוחות ויישומים שונים שימושיים עבור חברי צוות שונים. ה-Scrum Master מתעניין יותר בסטטוס ובטווח הגעה. בעוד שההנהלה הבכירה עשויה להתעניין בשיעור השחיקה של מומחים.

חלק מהצוותים משתמשים גם בלוחות מחוונים עם מחוונים אדומים, צהובים וירוקים כדי להעריך את המצב של CI/CD כדי להבין אם הם עושים הכל נכון או אם יש שגיאה. אדום אומר שאתה צריך לשים לב למה שקורה.

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

אין בדיקות ידניות

אוטומציה של בדיקות מניחה את הבסיס לצינור CI/CD טוב. אבל בדיקה אוטומטית בכל השלבים לא אומרת שאסור לבצע בדיקות ידניות. 

כדי לבנות צינור CI/CD יעיל, אתה צריך גם בדיקות ידניות. תמיד יהיו כמה היבטים של בדיקה הדורשים ניתוח אנושי.

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

אל תנסה לשפר מבחנים

צינור CI/CD יעיל דורש גישה לכלים הנכונים, בין אם זה ניהול בדיקות או אינטגרציה וניטור שוטף.

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

הנה כמה טיפים מעשיים שתוכל ליישם בקלות:

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

נקודה חשובה אחרונה חביבה

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

מה עוד לקרוא בנושא:

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

מקור: www.habr.com