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

בואו נדון מדוע כלי CI ו-CI הם דברים שונים לחלוטין.

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

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

אז, מה בדרך כלל עולה בראש כשאתה שומע את המילה CI? רוב האנשים יחשבו על Jenkins, Gitlab CI, Travis וכו'.

גם אם נחפש בגוגל, זה ייתן לנו את הכלים האלה.

אם אתם מכירים לשאול, אז מיד לאחר פירוט הכלים, הם יגידו לכם ש-CI הוא כאשר אתם בונים ומריצים בדיקות ב-Pull Request ל-commit.

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

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

והם פתרו את הכאב של עבודה משותפת כצוות!

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

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

אחד סיים את התכונה מהר יותר ומיזג אותו לתוך המאסטר.

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

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

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

הם יצרו זרד.

אחד מת, הכל היה בסדר, הוא עבר את המשימה.

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

במהלך הזמן הזה, המפתח השני עשה משהו אחר.

הראשון השלים את המשימה השלישית.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בואו נדמיין שמסיבה כלשהי אנחנו בשנת 2020 בלי האינטרנט. ואנחנו עובדים במקום. אין לנו את ג'נקינס. זה בסדר. אתה עדיין יכול להמשיך וליצור סניף מקומי. כתבת בו איזה קוד. סיימנו את המשימה תוך 3-4 שעות. עברנו למאסטר, עשינו git pull ומיזגנו שם את הסניף שלנו. מוּכָן. אם אתה עושה זאת לעתים קרובות, מזל טוב, יש לך אינטגרציה מתמשכת!

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

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

אבל האם יש לנו ראיות רלוונטיות כרגע שאומרות לנו שההשקעה בפרקטיקה הזו הגיונית?

הדבר הראשון שעלה לי בראש היה State of DevOps. זה מחקר שהחבר'ה עורכים כבר 7 שנים. עכשיו הם עושים את זה כארגון עצמאי, אבל תחת גוגל.

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

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

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

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

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

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

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

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

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

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

Jez Humble הוא המחבר של Handbook, Accelerate, אתר המסירה הרציפה והספר משלוח מתמשך. הוא מציע את המבחן הזה:

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

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

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

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

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

זהו מבוא קצר לשילוב מתמשך. זה כל מה שיש בתרגול הזה. אני מוכן לשאלות.

אני רק אסכם שוב בקצרה:

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

שאלות

מה לעשות עם משימות לא מפורקות?

לְפַרֵק. מה הבעיה? אתה יכול לתת דוגמה שיש משימה והיא לא מפורקת?

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

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

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

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

בסדר גמור. מה הטעם אז?

מה הטעם להרוג דברים קטנים כל יום?

כן.

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

תודה, הנושא סגור!

(אולג סורוקה) אפשר להוסיף? אמרת הכל נכון, אני רק רוצה להוסיף משפט אחד.

אז

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

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

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

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

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

הבסיס רק זז קדימה, כן.

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

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

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

האם נתת פיתוח טרנס-בסיסי כדוגמה שבה אתה יכול לראות שיטות עבודה או שאתה מציע לאנשים להתחיל להשתמש ב-transbase debelopment?

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

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

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

ישנה שאלה מהצ'אט: "אם סקירה היא חובה ונמשכת זמן רב, אולי יום או יותר?"

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

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

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

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

זה מסובך. אם אתה רוצה לקרוא את הסיפור על תכונת החלפת המצב בפירוט רב יותר, אני ממליץ עליו בחום https://trunkbaseddevelopment.com/. ויש מאמר נפלא מאת מרטין פאולר על תכונות החלפה: אילו סוגים יש, מחזורי חיים וכו'. תכונת החלפת המצב היא מסובכת.

ועדיין לא ענית על השאלה: "האם יש צורך בג'נקינס או לא?"

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

כלומר, אם יש לך שיטות, האם זה אומר שאתה לא צריך את זה?

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

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

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

עצור, עצור, תסריט bash הוא גם קוד. אל תיגע באהבה הישנה שלי.

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

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

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

אם למישהו יש עוד שאלות?

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

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

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

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

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

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

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

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

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

כן, הדברים האלה קשורים זה בזה.

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

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

(דמיטרי) אקרא הבהרה מהצ'אט: "אבל אנחנו צריכים הרבה סיקור מבחן ברמות שונות. כמה זמן מוקצה למבחנים? זה קצת יקר ולוקח הרבה זמן".

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

כאן, כמובן, קישטת.

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

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

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

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

בואו נחזור קצת אחורה לאינטגרציה מתמשכת. ברחנו לתוך תרגול מורכב קצת אחר.

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

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

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

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

כן, כן, אתה צודק.

ואז פתאום MVP בפרוד.

לנצח.

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

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

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

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

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

סרטון (מוכנס כרכיב מדיה, אך מסיבה כלשהי לא עובד):

https://youtu.be/zZ3qXVN3Oic

מקור: www.habr.com