СемВер и Микросервис
Есть ли лучшие практики / шаблоны для применения SemVer в микросервисном продукте? Должен ли быть SemVer для каждого микросервиса и SemVer для всего продукта?
Пример - у меня есть продукт под названием SuperDatabase с 3 микросервисами называется SuperDatabaseCore, SuperDatabaseReports, а также SuperDatabaseSearch,
Первый выпуск:SuperDatabase v1.0.0SuperDatabaseCore v1.0.0SuperDatabaseReports v1.0.0SuperDatabaseSearch v1.0.0
Незначительное обновление для отчета:SuperDatabaseReport v1.1.0
Должен ли продукт быть SuperDatabase v1.1.0 сейчас?
Что если позже появится патч для поиска:SuperDatabaseSearch v1.0.1
Следует ли снова изменить версию продукта? Должна ли версия продукта быть полностью независимой от микросервиса? Должен ли он использовать SemVer вообще? Или он не должен иметь никаких версий?
2 ответа
Я знаю, что это поздний ответ, но я думал, что поделюсь им.
У нас есть несколько микросервисов, и у каждого есть свой семвер. Мы используем Docker-контейнер для развертывания и даже для передачи клиенту (мы выпускаем образ Docker). Для докера существует манифест, указывающий, какая версия микросервиса включена... это работа для человека, потому что нам нужно выбрать совместимые версии. Наши разработчики планируют использовать https://kubernetes.io/, и я думаю, что у него хорошее управление зависимостями.
Версия продукта (маркетинговая версия) совершенно другая. Разработчик не заботится о маркетинговой версии... они увеличивают свою версию в зависимости от основных / незначительных изменений. На самом деле это версия образа докера, которую мы выпускаем.
Возвращаясь к микросервисам, мы используем автоматическое управление версиями... поэтому разработчики должны добавить журнал изменений в файл журнала изменений, указав тип их изменения и основываясь на том, что процесс сборки увеличивает версию (независимо от того, является ли она незначительной, мажор или патч). И как только изменения объединяются с основной веткой, ветка автоматически помечается этой версией. Так что в основном мы выпускаем постоянно.
Что касается разделяемых библиотек, мы также следуем за semver. Мы пользуемся преимуществами версий диапазона maven для получения последней совместимой версии, и, если есть основная версия, для обновления зависимых приложений требуется разработчик.
Есть также эти две статьи, которые я нашел:
использование ядра для подключения микроуслуг и наличие нескольких одновременных экземпляров
Вам следует создавать версии своих служб независимо, одно из преимуществ архитектур микросервисов заключается в том, что вы можете обновлять и развертывать небольшие части системы без каких-либо простоев для других компонентов (теоретически). Если вы обновите компоненты A и B при обновлении компонента C, вам придется развернуть все компоненты, когда изменился только один.