使用自动构建系统进行版本控制
我们最近转向了自动构建系统（内部的东西，还不是 Hudson 或 Teamcity）。
我们的版本存储在头文件中，并包含在一些 cpp 和资源文件中。安装程序也使用它。
其格式为 ABCD 其中：
- A 多年来未发生变化。
- B 很少更改（主要版本）。
- C 随着次要版本的变化而变化。
- 当新的次要版本（错误修复）交付给 QA 时，D 会发生变化。
到目前为止，负责构建新版本的人在开始构建之前手动递增 C/D（D 更常见），签入更改并然后开始构建。版本保持不变，直到该人成功构建应用程序。
当然，随着转向自动构建系统，我希望摆脱更改版本号的手动步骤。
应该如何处理这个问题？
- 每当进行新的构建时，无论是 QA 构建还是内部测试构建（即我正在开发某些功能并且我想测试我没有破坏的功能），我是否都会增加
D任何事物）？ - 增量步骤是自动构建系统中的任务吗？
- 增量后，我应该提交版本文件吗？
- 如何避免版本控制中出现大量噪音？我不想要大量的“版本增量”提交。
- 如果构建失败怎么办？仍然增加版本并提交吗？
We recently moved to an automatic build system (something internal, not Hudson or Teamcity, yet).
Our version is stored in a header file and is included by some cpp and resource files. It is also used by the installer.
Its format is A.B.C.D where:
- A didn't change in years.
- B changes rarely (major version).
- C changes with minor versions.
- D changes when a new minor version (bug fix) is delivered to QA.
Up until now, the one incharge of building a new version, incremented C/D by hand (D being the more common) before starting the build, checked in the change and then started the build. The version stayed the same until that person built the app successfully.
Naturally with the move to an automatic build system I'd like to get rid of the manual step of changing the version number.
How should this be approached?
- Do I increment
Dwhenever a new build is made, whether it's a QA build or an internal-test build (i.e. I'm working on some feature and I'd like to test I haven't broke anything)? - Is the increment step a task in the automatic build system?
- After incrementing, should I commit the version file?
- How do I avoid having a lot of noise in my version control? I don't want tons of "version incremented" commits.
- What do I do if the build failed? Still increment the version and commit?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
Eclipse Foundation 添加了一个 E 元素，即构建的日期和时间。我认为这对于内部测试构建来说是个好主意。如果您想使用 E 进行 QA 构建，则由您决定。
看起来很合乎逻辑，但你必须有某种方式告诉该任务你正在做什么样的构建。
提交带有源代码的版本控制文件。
基本上，您的开发构建过程应按以下顺序进行。
这会测试您的构建和构建过程。第二次构建不应失败，但如果失败，则说明该过程出现问题。
您的生产构建过程将从第二步开始，跳过第三步。
我的E是自动递增的。 :-) 我对其他元素 A、B、C 或 D 说不。
The Eclipse Foundation adds an E element, the date and time of the build. I think that's a good idea for the internal-test builds. It's up to you if you want to use E for the QA builds.
Seems logical, but you have to have some way of telling that task what kind of build you're doing.
Commit the version control file with the source code.
Basically, your development build process should proceed in the following order.
This tests your build and your build process. The second build should never fail, but if it does, there's a problem in the process.
Your production build process would start at the 2nd step, skipping the 3rd step.
My E is auto-incrementing. :-) I'd say no for the other elements A, B, C, or D.
是的，改变你的流程，让 D 随每次构建（成功与否）而增加，而不是每次交付给 QA 时增加。
进行多个构建可能会非常令人沮丧，有些构建可以工作，有些则不能，并且无法区分它们，因为失败的构建与好的构建具有相同的 id，最终还是如此。
那么您甚至不必考虑是否是在同一天或同一时间。
我会让构建系统仅自动递增构建号（D）。
版本控制存储的目的就是记录详细的噪音。
我将签入版本更新，这可以在 SVN 中显示一个合理的标记，其中包含之前的更改的构建内容，让构建系统忽略构建系统的签入，或者那些被标识为版本更新签入的签入。
然后，要查看版本历史记录，您应该有一个适当的工具，允许您过滤历史记录以显示您需要的视图，在某些情况下排除版本提交标记。
如果您选择不提交每个版本的版本号，那么最好将版本号维护在单独的文件中以避免意外更新。
仍然增加版本号，除非构建成功，否则我不会提交版本号。除了版本控制中的源代码更改之外，您还可能会遇到各种不需要记录的故障 - 构建服务器磁盘不足、服务器崩溃、编译器在构建 32 位和 64 位时出现问题、调试和发布 aix， linux和windows同时构建...
Yes, change your process so that D increments with every build (successful or not) rather than with every delivery to QA.
It can be quite frustrating having several builds, some working some not and not being able to tell them apart because the failed build is the same id as the good one, well eventually.
Then you don't even have to consider if it was on the same day or in the same hour.
I'd have the build system auto increment the build number (D) only.
The version control storage is all about recording the detailed noise.
I'd have the version update checked in, this can make a reasonable tag visible in SVN of what build the previous changes where included in, have the build system ignore checkins by the build system, or those identified as the version update checkin.
Then to view the version history you should have an appropriate tool that allows you to filter the history to show you the view you need, in some cases excluding the version commit tags.
If you choose not to commit the version number for each build, then it might be a good idea to maintain the version number in a separate file to avoid accidental updates.
Still increment the version number, I wouldn't commit the version number unless it was a successful build. You can have a variety of failures outside of source change in version control that don't need to be recorded - build server out of disk, server crash, compiler got all wobbly in the knees building 32 and 64 bit, debug and release aix, linux and windows builds at the same time...
您可以考虑使用 .NET 程序集的约定，如
类 System.Version。引用：You could consider to use the convention for .NET assemblies, as described in the documentation for
class System.Version. Quote:您将如何自动化此操作？我的意思是，什么系统会知道“这个版本是发布版本！”。在我看来，版本中的所有数字都是相关的。如果下一个版本 (D + 1) 需要两次构建，那么 ABCD+2 会是下一个版本吗？我听起来很可疑。如果确实有必要在 DLL 和 EXE 上包含此信息，我宁愿在版本之上添加内部版本号。
我不认为内部版本号是附加到二进制文件的相关信息，除非您从不同的版本分发 ABCD 版本的文件（无论如何您都不应该这样做！
）设置构建服务器以将工件（DLL、EXE、MSI、PDB 等）存储在一个目录中，该目录的名称包括构建号和版本，然后从那里刻录 DVD/任何内容。如果您需要从某个版本回溯到特定构建，则可以使用此信息，前提是您保留版本的存档（推荐！）。
How are you going to automate this? I mean, what system would know that "this build is the release build!". It would seem to me that all your digits in a version is relevant. If the next release (D + 1) requires two builds, then would A.B.C.D+2 be the next version? Sounds fishy to me. I would rather add the build number on top of the version instead, if it's really necessary to have this information on your DLLs and EXEs.
I don't think the build number is a relevant piece of information to have attached to the binary, unless you distribute files of version A.B.C.D from different builds (which you shouldn't do anyway!)
I would setup the build server to store the artifacts (DLLs, EXEs, MSIs, PDBs, etc) in a directory, whose name includes the build number and version, and then burn DVD/whatever from there. If you ever need to back track from a version to a specific build, you can use this information, provided that you keep an archive of your releases (recommended!).
我建议使用 autorevision。
您仍然可以保留标签的 ABCD 格式，并使用脚本创建在构建时生成的头文件，其中包含所需的信息。
I would recommend the use of autorevision.
You could still keep the A.B.C.D format for your tags and use the script to create header files that are generated at build time that have the needed info in them.