В настоящее время у меня есть 20 микросервисов для одного проекта. И каждый микросервис хранится в отдельном репозитории GIT. Впоследствии количество служб увеличится до 200 (или более).
Каждая служба имеет модульные тесты и интеграционные тесты. Каждая служба имеет встроенный сервер TeamCity (сервер непрерывной интеграции).
Вопрос: Как сохранить исходный код 200 микросервисов для одного проекта? В одном хранилище или в отдельных репозиториях?
Если эти микроуслуги тесно связаны (это означает, что было бы нецелесообразно загружать только некоторые из них, и вы будете работать только со всеми из них), поэтому их сохранение в отдельном репозитории Git рекомендуется.
Но вы все равно можете ссылаться на них как submodule в родительском репо, чтобы отслеживать их состояние в любой момент времени.
git Подмодули и поддеревья тоже имеют свои проблемы. Facebook и Google? имеют единый репозиторий для всех своих микросервисов. Нет четкого ответа на эту проблему, но такие вещи, как рефакторинг, управление зависимостями и проект, получают преимущества от монохранилища. Опять же, соединение сервисов и взаимодействие разных команд с репо - это ключ к выбору того или другого.
Мы не использовали подмодули; Мы сделали стратегию ветвления
У каждого микросервиса есть своя папка в папке base_folder.
Существует ветвь релиза → в настоящее время один мастер (у этого есть все) Существует интерфейсная ветвь → интерфейсы (у этого есть только интерфейсы, например, файлы protobuffer/grpc для всех сервисов). Эта ветка всегда объединяется с мастером
Каждая служба имеет ветвь → sprint_service_name, где код нажат (для проверки кода) и запрос слияния, созданный для мастер-ветки
Кодовый поток
Для нового компонента
git checkout interfaces
git checkout -b sprint_service_name
(create branch from interface branch)
Для существующего компонента
git checkout sprint_service_name
git fetch origin interfaces
git merge origin/interfaces (don't use git merge origin interfaces !!)
(или для двух шагов git для создания исходных интерфейсов)
Вот поток разработчика
Push to sprint_service_name branch and create merge request to master branch
git push origin sprint_service_name
Финишный поток
sprint_service_namexxx --> Merge Request --> master
sprint_interfaces --> Merge Request --> Interfaces -->master
interfaces --> sprint_service_namexxx (by all, every day)
Все общие части будут в интерфейсной ветке
(у вас может быть любое количество частных ветвей, но будьте осторожны, чтобы не объединить мастера в sprint_service_name или master на интерфейсы, иначе в вашей ветке останутся нежелательные файлы)
Pros Каждая микросервис будет иметь только свою папку кода и интерфейсов
против
Я видел, что нижний поток не всегда бывает идеально, например
sprint_interfaces --> Merge Request --> Interfaces -->master
Это больше похоже на
sprint_interfaces --> Merge Request --> master
Это означает, что кто-то должен вручную взять папку Interfaces из master и слить в ветку Interfaces. Но это всего лишь дисциплина и ничего не сломала.
У вас должен быть только один репо для всего проекта, большой или маленький.
Вы можете сослаться на 12 Factor Application для создания такого проекта, который обрабатывает большинство вещей отсюда.
Концепция приложения 12 Factor предназначена для крупных проектов, в которых много микросервисов.