我一直在考虑我目前正在使用的部署过程,我想知道是否有一种很好的方法来处理分支/标记将要/已经发布到生产环境的代码。
在某些时候,我想创建一个分支作为发布分支,并对分支进行最后一分钟的更改并发布它。然后在发布它之后,我想将它保存为标签。
为了澄清,我正在寻找命名、处理分支和处理标记的约定。我也想知道我所说的处理这种情况是否有其他选择。
- 您是否每次都命名发布分支或使用带有新代码的相同发布分支?
- 一旦发布分支作为标签存在就删除它们?
- 你如何命名你的分支/标签?
我一直在考虑我目前正在使用的部署过程,我想知道是否有一种很好的方法来处理分支/标记将要/已经发布到生产环境的代码。
在某些时候,我想创建一个分支作为发布分支,并对分支进行最后一分钟的更改并发布它。然后在发布它之后,我想将它保存为标签。
为了澄清,我正在寻找命名、处理分支和处理标记的约定。我也想知道我所说的处理这种情况是否有其他选择。
我建议阅读这个答案
基本上有一个名为 RELEASE 的分支,如果你愿意,你可以从那里标记。并将最前沿的代码版本保留在主干中
就发布命名而言:这取决于最适合您的内容以及看到发布编号的人。
考虑使用 MajorRelease.MinorRelease,那么对于技术上感兴趣的人,您甚至可以指定一个补丁版本号(例如,应用程序自动更新和 major.minor 保持不变)。
主要:重大变化->新功能/破坏兼容性次要:接口兼容(例如性能)补丁:错误修复
即使您不使用 TFS,也可以将此处的信息用作指导。
工作方式有很多种。我使用的是以下内容:
project_repository | |- trunk //当前支持版本在哪里。 | |-分支// 新特性/大修复或重构的地方。 | |- tags //所有版本都被标记的地方。 | |-发布//所有发布标签所在的位置 |- 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 有两种模式(开发和测试)。测试总是按需创建,并且会创建一个对应于构建版本的分支。
在某个时候,我想创建一个分支作为发布分支,并对分支进行最后一分钟的更改并发布它
这是我担心的一点。通常,您会想要创建一个分支,在其上进行所有开发,然后将该分支与主干重新集成。从这一点在主干上创建您的标签。如果您想进行更多更改,请创建一个新分支,编辑,重新集成并重新发布。
不要尝试对发布分支进行更改,因为您可能会丢失它们,或者将它们合并回主干时遇到麻烦。
发布分支的另一种方法是对主干进行所有开发更改,当您准备好时,创建一个发布/标记分支。对于小型开发商店,这通常是最简单的方法。(当您对其他人都在更改的产品进行重大更改时,另一种方法效果很好)。