Monorepo чи multirepo

Зміст:

• Підсумок
  • Проблема
  • Рішення
  • Статус
• Подробиці
  • Припущення
  • Обмеження
  • Позиції
  • Аргумент
  • Наслідки
• Пов’язане
  • Пов’язані рішення
  • Пов’язані вимоги
  • Пов’язані артефакти
  • Пов’язані принципи
• Примітки

Підсумок

Проблема

Наш проєкт передбачає розробку трьох основних категорій програмного забезпечення:

• Клієнтські GUI
• Сервіси проміжного шару (middleware)
• Серверні системи

Під час розробки нашою системою контролю версій (VCS) для управління вихідним кодом (SCM) є git.

Нам потрібно обрати, як ми використовуватимемо git для організації нашого коду.

Вибір найвищого рівня — організувати як «monorepo», «polyrepo» або «гібрид»:

• Monorepo означає, що ми кладемо всі частини в один великий репозиторій
• Polyrepo означає, що ми кладемо кожну частину в окремий репозиторій
• Гібрид означає певне поєднання monorepo та polyrepo

Докладніше дивіться https://github.com/joelparkerhenderson/monorepo-vs-polyrepo

Рішення

Monorepo — коли організація/команда/проєкт відносно невеликі, а швидка ітерація має вищий пріоритет, ніж підтримання стабільності.

Polyrepo — коли організація/команда/проєкт відносно великі, а підтримання стабільності має вищий пріоритет, ніж швидка ітерація.

Статус

Ухвалено. Відкриті до перегляду, якщо/коли з’являться нові інструменти для керування monorepo та/або polyrepo.

Подробиці

Припущення

Увесь код, який ми розробляємо, призначений для пропозицій однієї організації, а не для широкої публіки. Тобто брокер-дилер не прагне мати щось на кшталт добровольців-розробників із широкої публіки.

Обмеження

Обмеження добре задокументовано на https://github.com/joelparkerhenderson/monorepo-vs-polyrepo

Позиції

Ми розглядали monorepo в стилі Google, Facebook тощо. Ми вважаємо, що будь-які проблеми масштабування monorepo настільки віддалені в майбутньому, що на той час, коли вони нам знадобляться, ми зможемо скористатися тими самими практиками, що й Google та Facebook.

Ми розглядали polyrepo в стилі типових проєктів Git з відкритим кодом, як-от Google Android, Facebook React тощо. Ми вважаємо, що це найкращий вибір для участі широкої публіки (напр., будь-хто у світі може працювати над кодом) та індивідуальної доступності (напр., проєкт використовується сам по собі, без жодних інших частин).

Аргумент

Коли організація/команда/проєкт відносно невеликі, ми обираємо monorepo, бо швидка ітерація має значно вищий пріоритет, ніж підтримання стабільності

Коли організація/команда/проєкт відносно великі, ми обираємо polyrepo, бо підтримання стабільності має значно вищий пріоритет, ніж швидка ітерація.

Наслідки

Якщо вже є конвеєр CI+CD, нам, можливо, доведеться налаштувати його для тестування кількох проєктів в одному репозиторії.

CI+CD може потребувати більше часу для повної збірки monorepo, бо CI+CD може збирати всі проєкти в monorepo.

Якщо організація/команда/проєкт зростає, monorepo матиме проблеми масштабування.

Проблеми масштабування monorepo можуть зробити перехід на polyrepo дедалі вигіднішим.

Перехід від monorepo до polyrepo — суттєве завдання DevOps, і його потрібно буде спланувати, організувати та запрограмувати.

Пов’язане

Пов’язані рішення

Ми створимо рішення щодо пов’язаних інструментів для керування monorepo (напр., Google Bazel) та polyrepo (напр., Lyft Refactorator).

Пов’язані вимоги

Нам потрібно розробити конвеєр CI+CD, щоб він добре працював з git.

Пов’язані артефакти

Ми очікуємо, що організація репозиторіїв матиме пов’язані артефакти для провізування, керування конфігурацією, тестування та подібних галузей DevOps.

Пов’язані принципи

Легко скасовувати. Якщо monorepo не працює на практиці або його не хоче керівництво, перейти на polyrepo просто.

Одержимість клієнтом. Ми цінуємо донесення проєкту до рук клієнтів і вважаємо, що monorepo може привести нас до цього швидше, ніж polyrepo, а також допоможе швидше ітерувати.

Мислити масштабно. Google і Facebook — дуже сильні прихильники monorepo порівняно з polyrepo, бо всі основні пропозиції можна розробляти/тестувати/розгортати узгоджено.

Примітки

Додайте будь-які примітки тут.