使用共享代码库的多个产品进行版本控制和发布管理 [英] Versioning and release management with multiple products with shared code base

问题描述

$目前我试图弄清楚，如何在git流中执行发布管理，在这种情况下，我有两个解决方案中的大约15个项目以及数据库脚本。 b $ b

每个解决方案基本上都包含一个项目，这将导致一个可执行文件和超过10个项目包含由DAL，SAP访问包装等两种解决方案使用的基本功能。

解决方案一是应用程序为用户提供UI。

解决方案二是Windows服务。

两种解决方案和数据库的发布不同步。这意味着通常只有三个中的一个或两个被释放。这会导致不同的版本号。例如，UI发布频率很高，该服务很少发布。数据库介于两者之间。所以，UI可以有版本2.1.15，服务2.1.1和数据库2.1.5。

现在，如何处理共享项目？他们应该使用UI的版本号还是服务的版本号？

如何解释一个共享项目的更改不会自动触发这两种解决方案的发布？这意味着在同一时间，生产环境包含相同项目的两个不同版本。这不知何故需要反映在存储库中。

我有点失落，任何建议，经验等将不胜感激。

我可以自由地以任何方式构建资源库和代码库，如果有帮助，我可以创建额外的资源库。

首先关闭，如果你有不同的（即使有些依赖）项目，但它们有不同的版本，那么通过所有的方式将它们放在不同的git仓库中。

如果您将所有产品都放在同一个存储库中，则只是效率低下。例如，如果您正在使用用户界面，而另一个人正在使用该服务并对用户界面进行了一些小修补，那么当您将工作与他们合并时，他们也会更改服务（您不关心）从你的15个项目中，如果有些项目的关系太紧密，你可以将它们保存在同一个仓库中（例如UI的组件）。

p>

既然您拥有不同的存储库，您可以轻松管理它们的单独版本和单独的版本号。

你要小心，虽然，是兼容性。例如，2.4.5版本的用户界面可能与2.1.7-2.2.9版本的服务兼容，同样，2.1.10版本的服务可能与2.4版本的用户界面兼容.3-2.4.8。然后，每个版本的软件组件都应该能够检查其他组件的版本是否兼容。

I am currently trying to figure out, how to do release management with git flow in a scenario where I have one git repository with about 15 projects in two solutions plus scripts for the database.

Each solution basically contains one project that will result in an executable and more than 10 projects containing base functionality used by both solutions like DAL, SAP access wrapper etc.
Solution one is an application with UI for the users.
Solution two is a Windows service.
The release of the two solutions and the database are not in sync. This means that frequently only one ore two of the three are being released. This results in different version numbers. For example, the UI is released quite frequently, the service is released seldomly. The database somewhere in between. So, the UI could have version 2.1.15, the service 2.1.1 and the database 2.1.5.

Now, what to do with the shared projects? Should they use the version number of the UI or that of the service?
How would I account for the fact that a change in one of the shared projects wouldn't automatically trigger a release of both solutions? This means that at the same time, the production environment contains two different versions of the same projects. This somehow needs to be reflected in the repository.

I am a little bit lost here, any advice, experience etc. would be appreciated.
I am free to structure the repository and code base in any way and I can create additional repositories if that helps.

解决方案

First off, if you have different (even though somewhat dependent) projects, that are different enough for them to have different versions, then by all means put them in different git repositories.

If you have all your products under the same repository you are just being inefficient. For example, if you are working on the UI and another is working on the service and made a small fix to the UI, then when you merge your work with them, you get their change of the service too (which you didn't care for).

From your 15 projects, if some are too tightly related, you could keep them in the same repository (for example the components of the UI).

Now that you have different repositories, you can easily manage separate releases for them and separate version numbers.

One thing you want to be careful with though, is compatibility. For example, your UI with version 2.4.5 may be compatible with the service with version in the range 2.1.7-2.2.9, and likewise, the service with version 2.1.10 may be compatible with UI with version in the range 2.4.3-2.4.8. Each version of your software components should then be able to check the version of the other components for compatibility.

这篇关于使用共享代码库的多个产品进行版本控制和发布管理的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！