我们最近转向了一个自动构建系统(内部的东西,而不是Hudson或Teamcity).

我们的版本存储在头文件中,并包含在某些cpp和资源文件中.它也被安装人员使用.

其格式为A.B.C.D,其中：

> A多年来没有变化.
> B很少变化(主要版本).
> C更改次要版本.
>当新的次要版本(错误修复)传递给QA时,D会更改.

到目前为止,在开始构建之前,建立新版本,手动递增C / D(D是更常见的)的一个支持者,检查了更改然后开始构建.版本保持不变,直到该人成功构建应用程序.

随着转向自动构建系统,我想摆脱更改版本号的手动步骤.

该如何处理？

>无论何时进行新的构建,无论是QA构建还是内部测试构建,我都会增加D(即我正在研究某些功能,我想测试我没有破坏任何东西)？
>增量步骤是自动构建系统中的任务吗？
>递增后,我应该提交版本文件吗？
>如何避免版本控制中出现大量噪音？我不想要大量的“版本增加”提交.
>如果构建失败,我该怎么办？仍然增加版本并提交？

最佳答案

Do I increment D whenever 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)?

Eclipse Foundation添加了一个E元素,即构建的日期和时间.我认为这对于内部测试构建来说是一个好主意.如果您想将Q用于QA版本,则由您决定.

Is the increment step a task in the automatic build system?

似乎是合乎逻辑的,但你必须有一些方法告诉那个任务你正在做什么样的构建.

How do I avoid having a lot of noise in my version control? I don’t want tons of “version incremented” commits.

使用源代码提交版本控制文件.

基本上,您的开发构建过程应按以下顺序进行.

>从开发源代码构建产品.
>如果构建成功,请增加版本号.
>提交源代码和版本控制文件.
>从版本控制系统再次构建产品.
>如果构建失败,请退出源代码和版本控制文件提交.

这将测试您的构建和构建过程.第二个构建应该永远不会失败,但如果确实如此,那么这个过程就会出现问题.

您的生产构建过程将从第2步开始,跳过第3步.

What do I do if the build failed? Still increment the version and commit?

我的E是自动递增的. :-)我会对其他元素A,B,C或D说不.