Java项目中系统构建编号和版本号管理的当前最佳实践是什么？特别:
如何在分布式开发环境中系统地管理构建号
如何在源/可用于运行时应用程序中维护版本号
如何与源存储库正确集成
如何更自动地管理版本号与存储库标签
如何与持续构建基础架构集成
有很多工具可用,而ant(我们正在使用的构建系统)有一个维护构建号的任务,但是不清楚如何使用CVS,svn或类似的多个并发开发人员来管理它.
[编辑]
下面出现了几个好的和有用的部分或具体的答案,所以我将总结其中的一些.听起来对我来说就像这里没有真正强大的"最佳实践",而是一系列重叠的想法.下面,找到我的摘要和一些人们可能会尝试回答的结果问题.[对stackoverflow来说是新的...如果我做错了,请提供评论.]
如果您使用的是SVN,则可以使用特定结帐的版本控制.构建编号可以利用它来创建标识特定结帐/修订的唯一构建号.[我们因遗留原因而使用的CVS并没有提供这种程度的洞察力......使用标签进行人工干预可以帮助您实现目标.]
如果您使用maven作为构建系统,则支持从SCM生成版本号,以及用于自动生成版本的发布模块.[出于各种原因,我们不能使用maven,但这有助于那些能够做到的人.[感谢marcelo-morales ]]
如果您使用ant作为构建系统,则以下任务描述可以帮助生成捕获构建信息的Java .properties文件,然后可以通过多种方式将其折叠到构建中.[我们扩展了这个想法,包括哈德逊派生的信息,感谢marty-lamb ].
Ant和maven(以及hudson和巡航控制)提供了将构建号放入.properties文件或.txt/.html文件的简便方法.这种"安全"是否足以防止它被故意或意外地篡改？在构建时将它编译成"版本化"类是否更好？
断言:应该在像哈德森这样的持续集成系统中定义/制定构建编号.[感谢marcelo-morales ]我们已经采纳了这个建议,但它确实破解了发布工程问题:发布是如何发生的？发布中是否有多个buildnumbers？来自不同版本的构建数量之间是否存在有意义的关系？
问题:内部版本编号背后的目标是什么？它用于QA吗？怎么样？它是否主要由开发人员用于在开发期间消除多个构建之间的歧义,或更多用于QA以确定最终用户构建的内容？如果目标是可重复性,理论上这就是发布版本号应该提供的 - 为什么不呢？(请在下面作为你的答案的一部分回答这个问题,它将有助于说明你做出的建议/建议...)
问题:手动构建中是否存在构建号码的位置？这是有问题的,以至于每个人都应该使用CI解决方案吗？
问题:是否应将建立号码签入SCM？如果目标是可靠且明确地识别特定构建,那么如何应对可能崩溃/重启等的各种连续或手动构建系统......
问题:构建号码是否应该简短且甜蜜(即单调增加整数),以便易于存档到文件名中,易于在通信中引用等等......或者它应该是多长的用户名,日期戳,机器名等？
问题:请提供有关构建号分配如何适合您的大型自动发布流程的详细信息.是的,maven爱好者,我们知道这已经完成了,但并非我们所有人都喝醉了kool-aid ......
我真的很喜欢将其充实成一个完整的答案,至少对于我们的cvs/ant/hudson设置的具体例子,所以有人可以基于这个问题构建一个完整的策略.我将标记为"答案"的任何人都可以对这个特定情况给出一个疯狂的描述(包括cvs标记方案,相关的CI配置项和释放过程,将构建号折叠到发行版中,以便以编程方式如果你想询问/回答另一个特定的配置(例如,svn/maven /巡航控制),我将链接到这里的问题.--JA
[编辑09年10月23日]我接受了最高投票的答案,因为我认为这是一个合理的解决方案,而其他几个答案也包括好主意.如果有人想要用marty-lamb 's 合成其中一些,我会考虑接受另一个.我对marty-lamb的唯一顾虑是它不会生成一个可靠的序列化构建号 - 它依赖于构建器系统的本地时钟来提供明确的构建号,这并不是很好.
[编辑7月10日]
我们现在包括如下所示的类.这允许将版本号编译成最终的可执行文件.在记录数据,长期归档输出产品中发出不同形式的版本信息,并用于跟踪我们(有时是数年以后)对特定构建的输出产品的分析.
public final class AppVersion
{
// SVN should fill this out with the latest tag when it's checked out.
private static final String APP_SVNURL_RAW =
"$HeadURL: svn+ssh://user@host/svnroot/app/trunk/src/AppVersion.java $";
private static final String APP_SVN_REVISION_RAW = "$Revision: …使用maven内部版本号插件时获得以下异常.是否可以在使用内部版本号插件时禁用SCM检查？我们可以使用此插件在非SCM构建上生成内部版本号吗？
[ERROR] Failed to execute goal org.codehaus.mojo:buildnumber-maven-plugin:1.0:create (default) on project projectname: Execution default of goal org.codehaus.mojo:buildnumber-maven-plugin:1.0:create failed: The scm url cannot be null. -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:buildnumber-maven-plugin:1.0:create (default) on project projectname: Execution default of goal org.codehaus.mojo:buildnumber-maven-plugin:1.0:create failed: The scm url cannot be null.
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:534)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) …关于持续交付中的版本控制,我有一些具体问题.我想我了解全球工作流程或多或少是这样的:
1) Code
2) Push to version Control
3) Continuous Integration (unit, integration and end-to-end auto testing)
4) Artifacts deployment
版本控制怎么样？如何管理构建版本？
假设我们正在开发一个基于Maven的语义版本项目:major.minor.build.
当开发人员提交对VCS的更改并且CI服务器执行构建时,CI服务器是否应增加构建版本并在VCS中创建标记？
这个构建版本是否存在于源代码中？如果是这样,在每次推送到VCS之后,开发人员应该更新项目,因为CI服务器在项目上提交了更改(版本增量).
我有点困惑,我想以实用的方式理解CD工作流程.