Поділ частин монорепо


12

В даний час у нас є складна і неефективна система побудови, що складається з безлічі SVN і Git repos (близько 50% кожен), включаючи таку, яка є субмодулями git repo. У нас також є домашні сценарії, які більш-менш добре керують цілою справою.
Основним моментом нашої кодової бази із закритим кодом є те, що вона щільно з'єднана, і кожен проект випускається одночасно під тією ж версією.

Ми хочемо перенести це на більш просту систему та єдиний VCS, і ми розглядаємо кілька варіантів, серед яких: підмодулі git, google Repo та monorepos. Остаточний VCS ще не визначений (за винятком варіантів, що його мандат), і може бути svn, git або навіть щось інше, якби це краще відповідало нашій ситуації.

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

Чи існує така система управління привілеями у системі VCS?
Або є спосіб пом'якшити це питання?


Чи могли б ви розглянути сервер або сервіс Team Foundation? Він підтримує Git та включає в себе приємний робочий процес та можливості постійної інтеграції
hanzolo

Яку саме реалізацію монорепо ви розглядаєте?
Дан Корнілеску

Відповіді:


3

З вашого опису, я думаю, у вас тут є кілька варіантів:

  1. Використовуйте підмодулі git - за допомогою такої служби, як GitHub (або будь-що інше), ви можете керувати дозволами на проект і деакулювати процес розгортання. Однак я чув, що підмодулі git з часом сильно болять. Тут можуть допомогти автоматизовані сценарії для чистої реініціалізації / повторної завантаження підмодулів git.
  2. Розбийте репо на незалежні сервіси. Це дозволяє одночасно розвиватися, але також вводить велику кількість болю, оскільки потрібно починати думати про відкриття сервісу, розгортання декількох сервісів, середовищ розробки, постійну інтеграцію / розгортання та всі інші невеликі радощі, що виникають в результаті управління архітектура мікросервісу.
  3. Використовуйте офіційну систему управління пакунками, наприклад pip для Python, npm для Node.js, Maven для Java тощо. Розгортайте потрібні вам фрагменти коду у сховище та використовуйте їх у вашому головному репо-рене, якщо це необхідно, що має надати вам можливість для їх версії. Залежно від зв'язку між вашими модулями та вашим основним репо, ви, можливо, не зможете самостійно витягнути, запустити або протестувати модулі нижчого рівня. Якщо ви можете , однак, це досить непоганий спосіб досягти відмінних можливостей для отримання декількох сховищ, в той час як ви все ще можете інтегрувати ваші пакунки під час створення, встановивши їх із віддаленого сховища.

На жаль, жоден із цих варіантів не є ідеальним, але всі вони дійсні залежно від стану вашої кодової бази. Ваш опис здається, що варіант 3 може працювати найкраще тут.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.