תרגום המאמר שהוכן לתלמידי הקורס "שיטות וכלים של DevOps" בפרויקט החינוכי OTUS.

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

למה אנחנו מדברים על זה?

מאט קליין כתב את המאמר "Monorepos: בבקשה אל!"  (הערת המתרגם: תרגום על Habré "מאגרים מונו: בבקשה אל"). אני אוהב את מאט, אני חושב שהוא מאוד חכם וכדאי לקרוא את נקודת המבט שלו. הוא פרסם את הסקר במקור בטוויטר:

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

התגובה שלי הייתה, "אני ממש שני האנשים האלה." במקום לדבר על איך שראסט הוא סם, בואו נסתכל למה אני חושב שהוא טועה לגבי מאגרים חד-פעמיים. קצת על עצמך. אני ה-CTO של Chef Software. יש לנו כ-100 מהנדסים, בסיס קוד שנמשך כ-11-12 שנים אחורה, ו-4 מוצרים עיקריים. חלק מהקוד הזה נמצא ב-polyrepository (עמדת ההתחלה שלי), חלק נמצא ב-mononerepository (המיקום הנוכחי שלי).

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

אני מסכים עם החלק הראשון של דבריו של מאט:

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

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

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

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

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

זה מעורר תקשורת ומראה בעיות

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

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

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

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

אף אחד לא באמת רוצה לעשות את זה. זה הרבה פחות כיף מסתם תיקון ה-API הארור. הכל אנושי ומבולגן. ב-polyrepository, אתה יכול פשוט לבצע שינויים, לתת אותו לאנשים שעובדים על הרכיב הזה (כנראה לא B, C או D) לבדיקה, ולהמשיך הלאה. צוותים B, C ו-D יכולים פשוט להישאר עם הגרסה הנוכחית שלהם לעת עתה. הם יתחדשו כשהם יבינו את הגאונות שלך!

במאגר מונו, האחריות מועברת כברירת מחדל. צוות A משנה את הרכיב שלהם, ואם לא זהיר, שובר מיד את B, C ו-D. זה מוביל ל-B, C ו-D מופיעים בדלת של A, תוהים מדוע צוות A שבר את המכלול. זה מלמד את א' שהם לא יכולים לדלג על הרשימה שלי למעלה. הם חייבים לדבר על מה שהם הולכים לעשות. האם B, C ו-D יכולים לזוז? מה אם B ו-C יכולים, אבל D היה קשור קשר הדוק לתופעת לוואי של התנהגות האלגוריתם הישן?

אז אנחנו צריכים לדבר על איך נצא מהמצב הזה:

1. תמיכה במספר ממשקי API פנימיים, ותסמן את האלגוריתם הישן כמוצא משימוש עד ש-D תוכל להפסיק להשתמש בו.
2. תמיכה במספר גרסאות מהדורה, אחת עם הממשק הישן, אחת עם החדשה.
3. דחו את שחרור השינויים של A עד ש-B, C ו-D יוכלו לקבל זאת בו-זמנית.

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

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

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

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

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

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

רק משתמשים רשומים יכולים להשתתף בסקר. להתחברבבקשה.

מי הם הפנאטים הכי גדולים? תומכים:

• מונורפו

• חלודה

• סקר לא נכון / שניהם

33 משתמשים הצביעו. 13 משתמשים נמנעו.

מקור: www.habr.com