您的构建和发布步骤是什么？何时增加内部版本号？
尽管有简单的要求，但我在定义和自动化构建过程时遇到了困难：
- 每个构建都应该有一个唯一的构建号。
- 每个标记的版本都应该是可重现的
我拥有的：
- C++、Red Hat Enterprise Linux 5.x、Subversion 开发环境。
- 构建机器（实际上是虚拟机）
- version.h 文件，其中 #defines 表示主要、次要和构建编号。
- 用于增加 version.h 内部版本号的脚本。
- rpmbuild 规范文件，用于导出标记的 Subversion 源、构建并制作 rpm 安装程序包。
问题：
- 假设每个项目有多个开发人员，何时应该增加内部版本号并签入 version.h 文件？构建机器？某种 Subversion 挂钩？预构建还是后构建？
预先感谢那些愿意花时间分享构建流程经验的人。
-埃德 Linux新手。前 Windows C++/.NET 开发人员。
I am having trouble defining and automating my build process despite simple requirements:
- Every build should have a unique build number.
- Every tagged release should be reproducible
What I have:
- A C++, Red Hat Enterprise Linux 5.x, Subversion development environment.
- A build machine ( actually a virtual machine )
- A version.h file with #defines for major, minor, and buildnumber.
- A script for incrementing the version.h buildnumber.
- A rpmbuild spec file that exports the tagged Subversion source, builds, and makes the rpm installer packages.
Questions:
- Assuming multiple developers per project, when should the build number be incremented and version.h file be checked-in? The build machine? Some sort of Subversion hook? Pre-build or post-build?
Thanks in advance for those willing to take the time to share their experience with build processes.
-Ed
Linux newbie. Former Windows C++/.NET developer.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
为什么不修改您的构建过程，以便它从存储库中获取最新的修订号并将其用作构建号？
假设 svn 包含了产品构建中的所有元素，那么每个潜在的不同构建都应该有一个唯一的编号，并且可以轻松匹配构建时代码库的状态。如果还有其他元素可能随时间变化，您可以添加另一个与修订号连接的项目 - 可能是日期/时间值。
您永远不必担心手动增加它，因为每次开发人员提交时，他们都会自动增加修订号。
Why not modify your build process so that it grabs the latest revision number from the repository and uses that as the build number?
Assuming svn incorporates all of the elements that go into a build of your product, that should give you a unique number per potential differing build, and make it easy to match up what the state of the codebase was at the time of building. If there are other elements that can vary with time, you could add another item concatenated to the revision number - perhaps a date/time value.
You'll never have to worry about manually incrementing it, because each time a developer commits they'll increment the revision number automatically.
不要将构建号直接存储在文件中，而是使用 subversion 修订号（或其他一些单调递增的值，例如日期/时间）作为构建标识符。过去，我使用了
date -u +"%Y%m%d%H%M%S"的值，因为我们使用的是 CVS 而不是 SVN。Don't store the build number directly in your file, use the subversion revision number (or some other monotonically-increasing value, like the date/time) as your build identifier. In the past, I've used the value of
date -u +"%Y%m%d%H%M%S", as we were using CVS not SVN.我们的团队由多达 40 多名开发人员组成，为我们的产品添加代码。每个开发人员都将其更改提交到产品的中心位置。这形成了代码提交的有序列表。然后，脚本接受每次提交，并根据最后发布的配置和本轮中之前提交的任何更改将其集成到测试版本中。单元测试在每次代码提交编译后运行，并且也运行当前轮中添加的任何验收测试。每天结束时，都会针对不断发展的构建运行单元测试和回归测试。
每周两次，提交的代码更改列表会被打包，成为产品的新发布配置，并且代码库也会更新。
We have teams of upto 40+ developers adding code to our product. Each developer submits their change to a central location for the product. This forms an ordered list of code submissions. Scripts then take each submission and integrates it into a test build based on the last released configuration and any previous submitted changes in the current round. Unit tests are run after each code submission is compiled, also any acceptance tests added in the current round are also run. At the end of each day unit tests and regression tests are run against the evolving build.
Twice a week the list of submitted code changes is wrapped up and that becomes the a new released configuration of the product and the codebase is updated.