Monorepo לעומת multirepo

תוכן העניינים:

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

סיכום

בעיה

הפרויקט שלנו כולל פיתוח של שלוש קטגוריות עיקריות של תוכנה:

• ממשקי משתמש גרפיים בצד לקוח
• שירותי middleware
• שרתי צד שרת

כשאנו מפתחים, מערכת בקרת הגרסאות (VCS) של ניהול קוד המקור (SCM) שלנו היא git.

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

הבחירה ברמה העליונה היא לארגן כ-"monorepo" או "polyrepo" או "היברידי":

• Monorepo פירושו שאנו שמים את כל החלקים במאגר גדול אחד
• Polyrepo פירושו שאנו שמים כל חלק במאגר משלו
• היברידי פירושו שילוב כלשהו של monorepo ו-polyrepo

למידע נוסף ראו https://github.com/joelparkerhenderson/monorepo-vs-polyrepo

החלטה

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

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

מצב

הוחלט. פתוחים לשקול מחדש אם/כאשר יהיו זמינים כלים חדשים לניהול monorepos ו/או polyrepos.

פרטים

הנחות

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

אילוצים

האילוצים מתועדים היטב ב-https://github.com/joelparkerhenderson/monorepo-vs-polyrepo

עמדות

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

שקלנו polyrepos בסגנון של פרויקטי קוד פתוח טיפוסיים ב-Git, כמו Google Android, ‏Facebook React וכדומה. אנו חושבים שאלה הבחירה הטובה ביותר להשתתפות הציבור הרחב (למשל כל אחד בעולם יכול לעבוד על הקוד) ולזמינות עצמאית (למשל הפרויקט משמש לבדו, בלי חלקים אחרים).

טיעון

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

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

השלכות

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

CI+CD עשוי לקחת יותר זמן לבנייה מלאה של monorepo, כי CI+CD עשוי לבנות את כל הפרויקטים ב-monorepo.

אם ארגון/צוות/פרויקט גדל, ל-monorepo יהיו בעיות הרחבה.

בעיות הרחבה של monorepo עשויות להפוך מעבר ל-polyrepo לבעל ערך גובר.

מעבר מ-monorepo ל-polyrepo הוא משימת devops משמעותית, וצריך לתכנן אותה, לנהל אותה ולתכנת אותה.

נושאים קשורים

החלטות קשורות

ניצור החלטות לכלים קשורים לניהול monorepos (למשל Google Bazel) ו-polyrepos (למשל Lyft Refactorator).

דרישות קשורות

עלינו לפתח את צינור ה-CI+CD כך שיעבוד היטב עם git.

תוצרים קשורים

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

עקרונות קשורים

הפיך בקלות. אם ה-monorepo לא עובד בפועל, או שההנהגה לא רוצה בו, פשוט לעבור ל-polyrepo.

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

לחשוב בגדול. Google ו-Facebook הן תומכות חזקות מאוד של monorepos על פני polyrepos, כי כל ההצעות המרכזיות אפשר לפתח/לבדוק/לפרוס בהרמוניה.

הערות

הוסיפו כאן הערות.