git - 如何使用 Flyway 为 multirepo 项目确定架构版本号

Question

我们正在开发 n 层应用程序，其中frontend、backend、database-migrator 和docker-compose 环境组件存储和开发在他们自己的存储库中。它们由 CI/CD 管道独立构建、单元测试和容器化。目前，语义版本用于标记后端组件主构建。Docker-compose 项目应该使用正确的组件版本设置开发环境。

使用分解的存储库全面跟踪 n 层应用程序组件开发和发布版本之间的兼容性的最佳方法是什么？由于存在安全问题，Git 子模块无法使用。我们应该利用 docker 注册表和标签进行版本管理。Git 标签用于标记 docker 镜像。

我特别不确定如何为数据库迁移指定版本。架构级别和迁移器映像级别的版本碰撞（主要/次要）规则是什么？架构版本应如何与映像版本相关（不同的映像版本可能具有不同的“未版本化”可重复脚本，即视图和过程 => 可能的重大更改）。

另外，我不确定如何对前端进行版本控制，因为没有依赖项。最终，我想维护版本历史记录，如果需要，可以在其中部署以前版本的系统。

TLDR：如何在多存储库项目中使用语义版本控制进行前端、后端、数据库迁移和 docker-compose-environment 以及 CI/CD 管道和容器注册表？

标签： gitversion-controldependenciesmicroservicesversioning

Answer 1

Flyway 的常见设置是将其集成到您的微服务中（在这种情况下可能在您的后端）。这样，您的迁移将与您的代码一起进行。如果您有多个使用数据库的微服务，那么每个微服务都会有自己的迁移。将迁移与后端代码分离到单独的存储库中通常不是最佳实践。

关于混合不同版本的微服务 - 有关更多上下文，请参阅我的文章 - https://worklifenotes.com/2020/03/04/microservices-combinatorial-explosion-of-versions/。我目前正在开发一种工具来解决这个问题 - https://relizahub.com。本质上，我们会自动将项目的不同可能状态记录为“捆绑包”，然后您将这些捆绑包作为整个堆栈版本控制的单一事实点。还有一些特定的工具可以将您的 CI/CD 路由到正确的捆绑包，包括手动和自动门的业务规则。