具有共享代码库的多个产品的版本控制和发布管理

Dan*_*rth 5 versioning git release release-management git-flow

我目前正在试图找出,如何在一个场景中使用git flow进行发布管理,我有一个git存储库,其中包含两个解决方案中的大约15个项目以及数据库的脚本.

每个解决方案基本上包含一个项目,该项目将生成可执行文件,10个项目包含两个解决方案(如DAL,SAP访问包装器等)使用的基本功能.
解决方案一是具有用户UI的应用程序.
解决方案二是Windows服务.
两个解决方案和数据库的发布不同步.这意味着通常只有三分之二的矿石被释放.这导致不同的版本号.例如,UI很频繁地发布,服务很少发布.数据库介于两者之间.因此,UI可以具有2.1.15版本,服务2.1.1和数据库2.1.5.

现在,如何处理共享项目?他们应该使用UI的版本号还是服务的版本号?
我如何解释其中一个共享项目的更改不会自动触发两个解决方案的发布?这意味着同时,生产环境包含相同项目的两个不同版本.这在某种程度上需要反映在存储库中.

我有点迷失在这里,任何建议,经验等将不胜感激.
我可以自由地以任何方式构建存储库和代码库,如果有帮助,我可以创建其他存储库.

Sha*_*baz 3

首先,如果您有不同的(即使有些依赖)项目,这些项目的差异足以使它们具有不同的版本,那么请务必将它们放在不同的 git 存储库中。

如果您将所有产品都放在同一个存储库中,那么您的效率就会很低。例如,如果您正在开发 UI,而另一个正在开发服务并对 UI 进行了小修复,那么当您将您的工作与他们合并时,您也会得到他们对服务的更改(您不关心这一点)为了)。

在您的 15 个项目中,如果某些项目相关性太紧密,您可以将它们保留在同一个存储库中(例如 UI 的组件)。

现在您拥有不同的存储库,您可以轻松地管理它们的单独版本和单独的版本号。

不过,您需要注意的一件事是兼容性。例如,版本 2.4.5 的 UI 可能与版本 2.1.7-2.2.9 范围内的服务兼容,同样,版本 2.1.10 的服务可能与版本 2.4 范围内的 UI 兼容.3-2.4.8。然后,软件组件的每个版本都应该能够检查其他组件的版本的兼容性。