我一直在考虑目前正在使用的部署流程,想知道是否有良好的方法来处理已发布或即将发布的代码分支/标记。
我希望将一个分支作为发布分支,并对该分支进行任何最后一刻的更改并发布它。然后,在发布之后,我希望将其保存为标记。
为了澄清,我正在寻找命名、处理分支和标记的约定。我还想知道是否有其他处理情况的替代方法。
- 您是给发布的分支命名,还是每次都使用相同的发布分支添加新代码?
- 在成为标记后,是否删除发布分支?
- 您如何命名您的分支/标记?
我一直在考虑目前正在使用的部署流程,想知道是否有良好的方法来处理已发布或即将发布的代码分支/标记。
我希望将一个分支作为发布分支,并对该分支进行任何最后一刻的更改并发布它。然后,在发布之后,我希望将其保存为标记。
为了澄清,我正在寻找命名、处理分支和标记的约定。我还想知道是否有其他处理情况的替代方法。
有很多种工作方式,我使用的方式如下:
project_repository | |- trunk // 当前支持发布的位置。 | |- branches // 新功能/大修复或重构所在的位置。 | |- tags // 所有发布都标记的位置。 | |- releases // 所有发布标记所在的位置 |- daily // 所有日常工作标记所在的位置。
我们使用以下命名方法:
为了遵循这个结构和命名规范,我们有一套工具和脚本来帮助按照这种方式工作。此外,每晚一个构建服务器会生成每日标记。
我使用CruiseControl.Net自动化了构建过程。我们将构建与构建号对应,以便dll版本为6.5.4.1234。当我们进行重大和次要发布时,总是手动更新6和5。在构建后手动更新4(然后将1234重置为0)。构建过程总是将1234更新为1235。
当我们从主干发布(版本始终为6.0.0.x)时,我们会手动分支并称其为Branch_6_0。该分支将构建为6.0.1。主干将移动到6.1或7.0。
CruiseControl有两种模式(dev和test)。测试总是按需创建,并创建与构建版本相对应的分支。