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

לאחר שכתבת את הקוד שלך, עליך לוודא שהוא:

1. זה עובד.
2. זה לא שובר שום דבר, כולל הקוד שכתבו עמיתיך.

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

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

• אנשים יקרים. שעת עבודה של כל מתכנת יקרה יותר משעת עבודה של כל שרת.
• אנשים עושים טעויות. לכן, עלולים להיווצר מצבים שבהם בוצעו בדיקות בסניף הלא נכון או הידור שגוי לבודקים.
• אנשים עצלנים. מדי פעם, כשאני מסיים משימה, עולה המחשבה: “מה יש לבדוק? כתבתי שתי שורות - הכל עובד! אני חושב שגם לחלקכם יש לפעמים מחשבות כאלה. אבל תמיד כדאי לבדוק.

כיצד הוטמע ופותח אינטגרציה מתמשכת בצוות הפיתוח לנייד של Avito, כיצד הם עברו מ-0 ל-450 בנייה ביום, וכי מכונות לבנות מרכיבות 200 שעות ביום, אומר ניקולאי נסטרוב (נסטרוב) משתתף בכל השינויים האבולוציוניים של אפליקציית CI/CD Android.

הסיפור מבוסס על דוגמה של פקודת אנדרואיד, אבל רוב הגישות ישימות גם ב-iOS.

פעם, אדם אחד עבד בצוות Avito Android. בהגדרה, הוא לא היה זקוק לשום דבר משילוב מתמשך: לא היה עם מי להשתלב.

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

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

בדיקות

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

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

כדי להבין כיצד יש להפעיל את הבדיקות הללו, בואו נסתכל על תהליך הפיתוח ב-Avito.

זה יכול להיות מיוצג בצורה סכמטית כך:

• מפתח כותב קוד במחשב הנייד שלו. אתה יכול להריץ בדיקות אינטגרציה ממש כאן - או עם commit hook, או פשוט להריץ בדיקות ברקע.
• לאחר שהמפתח דחף את הקוד, הוא פותח בקשת משיכה. על מנת שהקוד שלו ייכלל בסניף develop יש צורך לעבור סקירת קוד ולאסוף את מספר האישורים הנדרש. אתה יכול להפעיל בדיקות ובנייה כאן: עד שכל הבנייה יצליחו, לא ניתן למזג את בקשת המשיכה.
• לאחר מיזוג בקשת ה-pull והקוד כלול ב-Develop, תוכלו לבחור זמן נוח: למשל בלילה, כשכל השרתים פנויים, ולהריץ כמה צ'קים שתרצו.

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

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

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

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

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

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

לאחר מכן התחלנו לחשוב יותר - האם אנחנו בכלל בודקים נכון? האם אנו מריצים בקשות משיכה בצורה נכונה?

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

לשם כך, כתבנו תסריט bash פשוט premerge.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

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

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

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

דוגמה לאיך זה קורה:

שני מפתחים בו זמנית מתחילים לעבוד על תכונות A ו-B. מפתח פיצ'ר A מגלה פיצ'ר לא בשימוש בפרויקט answer() וכמו ילד טוב, מסיר אותו. במקביל, מפתח פיצ'ר ב' מוסיף קריאה חדשה לפונקציה הזו בסניף שלו.

מפתחים מסיימים את עבודתם ופותחים בקשת משיכה בו-זמנית. ה-builds מושקים, premerge.sh בודק את שתי בקשות המשיכה לגבי מצב הפיתוח האחרון - כל הצ'קים ירוקים. לאחר מכן, בקשת המשיכה של תכונה A מתמזגת, בקשת המשיכה של תכונה B מתמזגת... בום! פתח הפסקות מכיוון שקוד הפיתוח מכיל קריאה לפונקציה לא קיימת.

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

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

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

איך לא לשבור להתפתח

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

כדי להבין כמה זמן זה ייקח, שקול דוגמה עם שני יחסי ציבור. אנחנו פותחים שני יח"צ: שני בונים, שני הרצאות של צ'קים. לאחר מיזוג ה-PR הראשון לתוך פיתוח, השני צריך להיבנות מחדש. בסך הכל, שני יחסי ציבור דורשים שלוש ריצות של בדיקות: 2 + 1 = 3.

בעקרון זה בסדר. אבל הסתכלנו על הסטטיסטיקה, והמצב האופייני בצוות שלנו היה 10 יחסי ציבור פתוחים, ואז מספר הצ'קים הוא סכום ההתקדמות: 10 + 9 +... + 1 = 55. כלומר, לקבל 10 אנשי יחסי ציבור, אתה צריך לבנות מחדש 55 פעמים. וזה במצב אידיאלי, כשכל הצ'קים עוברים בפעם הראשונה, כשאף אחד לא פותח בקשת משיכה נוספת בזמן שתריסר אלו מעובדים.

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

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

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

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

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

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

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

לקח לנו שבועיים לכתוב את הגרסה הראשונה של התוסף Bitbucket.

צ'קים חדשים

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

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

כדי לעשות זאת, היינו צריכים לעשות הרבה סטייה: לקחת את Android Studio, לארוז אותו ב-Docker ולהפעיל אותו על CI עם צג וירטואלי, כך שהוא יחשוב שהוא פועל על מחשב נייד אמיתי. אבל זה עבד.

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

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

Firebase Test Lab

זה נבחר בגלל ש-Firebase הוא מוצר של גוגל, כלומר הוא צריך להיות אמין ולא סביר שהוא ימות אי פעם. המחירים סבירים: 5$ לשעת הפעלה של מכשיר אמיתי, 1$ לשעת הפעלה של אמולטור.

לקח כשלושה שבועות ליישם את Firebase Test Lab ב-CI שלנו.

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

Docker + Python + bash

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

לקח חמישה שבועות ליצור סביבת בדיקה משלנו.

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

• הרכבת ARK;
• בדיקות ג'וניט;
• מוֹך;
• בדיקות אנדרואיד סטודיו;
• מבחני מכשור;
• בדיקות צילום מסך.

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

כמה זמן זה ארוך מדי? העלינו נתונים מ-Bitbucket ו-TeamCity למערכת הניתוח והבנו את זה זמן המתנה ממוצע 45 דקות. כלומר, מפתח, כאשר פותח בקשת משיכה, ממתין בממוצע 45 דקות לתוצאות הבנייה. לדעתי, זה הרבה, ואתה לא יכול לעבוד ככה.

כמובן, החלטנו להאיץ את כל הבנייה שלנו.

בואו נזרז

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

הסרת צ'קים שלוקחים יותר מדי זמן

השילוב הרציף שלנו יכול לתפוס שגיאות ובעיות מסוג זה.

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

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

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

כתוצאה מכך, נשארנו עם:

• הרכבת ARK;
• בדיקות ג'וניט;
• מבחני מכשור.

מטמון מרוחק של Gradle

בלי צ'קים כבדים הכל השתפר. אבל אין גבול לשלמות!

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

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

הפעלת המטמון המרוחק של Gradle קל מכיוון ש- Gradle מספק תמונת Docker. הצלחנו לעשות זאת בשלוש שעות.

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

להלן גרף החמצות של המטמון.

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

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

ניתוח השפעה

בבקשת משיכה, אנו אוספים git diff ומוצאים את המודולים של Gradle שהשתנו.

הגיוני להריץ רק בדיקות מכשור שבודקות את המודולים שהשתנו ואת כל המודולים התלויים בהם. אין טעם להריץ בדיקות עבור מודולים שכנים: הקוד שם לא השתנה ושום דבר לא יכול להישבר.

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

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

האמצעים להאצת הבדיקות עבדו בהצלחה. מ-45 דקות עלינו לכ-15. זה כבר נורמלי לחכות רבע שעה לבנייה.

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

בעיות במשוב מאטות את הפיתוח, ולכן ניסינו לספק מידע ברור ומפורט על כל יחסי ציבור ובנייה ככל האפשר. התחלנו עם הערות ב-Bitbucket ל-PR, שציינו איזה בנייה נכשלה ומדוע, וכתבנו הודעות ממוקדות ב-Slack. בסופו של דבר, יצרנו עבור הדף דשבורד PR עם רשימה של כל ה-builds שפועלים כעת והסטטוס שלהם: בתור, פועל, קרס או הושלם. אתה יכול ללחוץ על ה-build ולהגיע ליומן שלו.

שישה שבועות הוקדשו למשוב מפורט.

תוכניות

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

בנוסף, ישנן תוכניות נוספות.

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

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

Советы

אם הייתי יכול לתת עצה אחת בלבד זו תהיה זו:

אנא היזהר עם סקריפטים של מעטפת!

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

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

#!/usr/bin/env bash
./gradlew assembleDebug

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

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

מה ניתן להחליף?

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

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

טיפ מס' 2: אחסן תשתית בקוד.

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

ניתן לאחסן סקריפטים בפרויקט. מה לעשות עם הסביבה?

טיפ מס' 3: Docker יכול לעזור עם הסביבה.

זה בהחלט יעזור למפתחי אנדרואיד; ל- iOS אין עדיין אחד, למרבה הצער.

זוהי דוגמה לקובץ docker פשוט המכיל jdk ו-android-sdk:

FROM openjdk:8

ENV SDK_URL="https://dl.google.com/android/repository/sdk-tools-linux-3859397.zip" 
    ANDROID_HOME="/usr/local/android-sdk" 
    ANDROID_VERSION=26 
    ANDROID_BUILD_TOOLS_VERSION=26.0.2

# Download Android SDK
RUN mkdir "$ANDROID_HOME" .android 
    && cd "$ANDROID_HOME" 
    && curl -o sdk.zip $SDK_URL 
    && unzip sdk.zip 
    && rm sdk.zip 
    && yes | $ANDROID_HOME/tools/bin/sdkmanager --licenses

# Install Android Build Tool and Libraries
RUN $ANDROID_HOME/tools/bin/sdkmanager --update
RUN $ANDROID_HOME/tools/bin/sdkmanager "build-tools;${ANDROID_BUILD_TOOLS_VERSION}" 
    "platforms;android-${ANDROID_VERSION}" 
    "platform-tools"

RUN mkdir /application
WORKDIR /application

לאחר שכתבתי את קובץ ה-Docker הזה (אני אגלה לך סוד, אתה לא צריך לכתוב אותו, אלא פשוט למשוך אותו מוכן מ-GitHub) והרכבת את התמונה, אתה מקבל מכונה וירטואלית עליה תוכל לבנות את האפליקציה ולהריץ בדיקות Junit.

שתי הסיבות העיקריות לכך שזה הגיוני הן מדרגיות וחזרתיות. באמצעות docker, אתה יכול לגייס במהירות תריסר סוכני בנייה שתהיה בדיוק אותה סביבה כמו הקודמת. זה הופך את החיים של מהנדסי CI לקלים הרבה יותר. זה די קל לדחוף את android-sdk לתוך docker, אבל עם אמולטורים זה קצת יותר קשה: תצטרך לעבוד קצת יותר קשה (או להוריד את המוגמר מ-GitHub שוב).

טיפ מס' 4: אל תשכח שבדיקות לא נעשות למען בדיקות, אלא למען אנשים.

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

טיפ מס' 5: היו פרגמטיים בעת פיתוח אינטגרציה מתמשכת.

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

טיפ מס' 6: השתמש בכלים מוכנים.

ישנן חברות רבות שמספקות CI בענן.

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

טיפ מס' 7: בצוות גדול, פתרונות פנימיים רווחיים יותר.

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

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

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

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

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

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

תרגול אינטגרציה רציפה. אבל במידה.

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

מקור: www.habr.com