在发布之前和之后我应该如何分支和标记?
-
06-07-2019 - |
题
我一直在考虑我当前正在使用的部署过程,我想知道是否有一种好的方法来处理将要/已经发布到生产环境的代码的分支/标记。
在某些时候,我想创建一个分支作为发布分支,并对分支进行最后一刻的更改并发布它。然后在发布后我想将其保存为标签。
为了澄清这一点,我正在寻找命名、处理分支和处理标记的约定。我还想知道除了我所说的处理这种情况是否还有其他选择。
- 您是否命名发布分支或每次都使用带有新代码的相同发布分支?
- 一旦发布分支作为标签存在就删除它们吗?
- 你如何命名你的分支/标签?
解决方案
我建议阅读这个答案
基本上有一个名为 RELEASE 的分支,如果您愿意,您可以从那里进行标记。并将最前沿的代码版本保留在主干中
就发布命名而言:这取决于什么最适合您以及谁是看到版本号的人。
考虑使用 MajorRelease.MinorRelease,然后对于技术感兴趣的人来说,您甚至可以指定补丁版本号(例如应用程序自动更新和 Major.minor 保持不变)。
主要的:重大变化 - >新功能/中断兼容性次要:接口兼容(例如性能)补丁:bug修复
其他提示
即使您不使用 TFS,也可以使用此处的信息作为指导。
工作的方式有很多种。我使用的如下:
项目存储库 | |- 树干 //Where the current in support release is. | |- 分支机构 //Where new features/big fixes or refactors are made. | |- 标签 //Where all releases are tagged. | |- 发布 //where all release tags are located |- 日常的 //where all daily tags are located.
我们使用的命名如下:
- 对于分支,我们根据其中将要执行的主要任务来命名分支(例如:管理模块重构)。
- 对于标签,我们用版本号命名标签(mayor.minor.micro)。例如:1.0.2) 当它们对应于发布标签时。或者带有日常工作标签的日期(例如:年月日)。
为了遵循这种结构和命名约定,我们有一组工具和脚本来帮助以这种方式工作。此外,构建服务器整晚都会生成每日标签。
我使用 CruiseControl.Net 自动化了构建过程。我们的内部版本与内部版本号相对应,因此 dll 版本为 6.5.4.1234。当我们有主要和次要版本时,6 和 5 总是会手动更新。4 在构建后手动更新(并且 1234 也被重置为 0)。构建过程始终将 1234 更新为 1235。
当我们从主干发布时(版本始终为 6.0.0.x),我们将手动分支并将其称为 Branch_6_0。然后分支将构建为 6.0.1。Trunk 将移至 6.1 或 7.0。
CruiseControl 有两种模式(开发和测试)。测试始终是根据需要创建的,并将创建与构建版本相对应的分支。
在某个时候,我想将分支作为释放分支,并对分支进行任何最后一刻更改并释放
这是让我担心的一点。通常,您需要创建一个分支,在其上进行所有开发,然后将该分支与主干重新集成。从此时开始在树干上创建标签。如果您想进行更多更改,请创建新分支、编辑、重新集成并重新发布。
不要尝试对发布分支进行更改,因为您可能会丢失它们,或者在将它们合并回主干时遇到麻烦。
发布分支的另一种方法是对主干进行所有开发更改,当您准备好时,创建一个发布/标签分支。对于小型开发商店来说,这通常是最简单的方法。(当您对其他人也在进行更改的产品进行重大更改时,另一种方法效果很好)。