构建和版本编号为Java项目（蚂蚁，CVS，哈德森） [英] Build and Version Numbering for Java Projects (ant, cvs, hudson)

问题描述

什么是Java中的项目进行系统构建的编号和版本号管理的当前最佳做法？具体做法是：

What are current best-practices for systematic build numbering and version number management in Java projects? Specifically:

• 如何系统地管理分布式开发环境，内部版本号

• How to manage build numbers systematically in a distributed development environment

如何保持源代码版本号/可用于运行应用程序

How to maintain version numbers in source / available to the runtime application

如何正确地与源库集成

如何更自动管理的版本号与库中代码

How to more automatically manage version numbers vs. repository tags

如何通过持续构建基础设施集成

How to integrate with continuous build infrastructure

有相当多的可用，蚁工具（我们使用的是构建系统）具有将保持build号的任务，但目前还不清楚如何使用CVS来管理这个多，同时开发商，SVN或类似的。

There are quite a number of tools available, and ant (the build system we're using) has a task that will maintain a build number, but it's not clear how to manage this with multiple, concurrent developers using CVS, svn, or similar.

若干良好的和有益的部分或特定的答案已经出现了下面，所以我总结了其中的几个。这听起来好像确实没有强烈的最佳实践这一点，而是一个重叠的想法集合。下面，找到我的总结和人可能试图回答，因为后续的一些问题导致。 [新来的StackOverflow ......请提供意见，如果我这样做是错误的。]

Several good and helpful partial or specific answers have appeared below, so I'll summarize a few of them. It sounds to me like there is not really a strong "best practice" on this, rather a collection of overlapping ideas. Below, find my summaries and some resulting questions that folks might try to answer as follow-ups. [New to stackoverflow... please provide comments if I'm doing this wrong.]

• 如果您正在使用SVN，具体结账版本凑凑热闹来。构建编号可以利用它创建标识特定的收银台/修订独特的版本号。 [CVS，这是我们正在使用的遗留原因，不提供相当这个水平的洞察力......人工干预的标签让你一部分的方式存在。]

• If you are using SVN, versioning of a specific checkout comes along for the ride. Build numbering can exploit this to create a unique build number that identifies the specific checkout/revision. [CVS, which we are using for legacy reasons, doesn't provide quite this level of insight... manual intervention with tags gets you part way there.]

如果你正在使用Maven作为构建系统，有生产从SCM版本号，以及用于自动生成的版本释放模块的支持。 [我们不能用maven，对于各种各样的原因，但这种帮助那些谁可以。 [感谢马塞洛，莫拉莱斯]

If you are using maven as your build system, there is support for producing a version number from the SCM, as well as a release module for automatically producing releases. [We can't use maven, for a variety of reasons, but this helps those who can. [Thanks to marcelo-morales]]

如果您使用的是蚂蚁作为构建的系统，下面的任务描述可以帮助产生一个Java属性文件捕获构建信息，然后可以以多种方式进行折叠成构建。 [我们扩大了这个主意，包括哈德森获​​得的信息，感谢马蒂 - 羊肉]。

If you are using ant as your build system, the following task description can help produce a Java .properties file capturing build information, which can then be folded into your build in a number of ways. [We expanded on this idea to include hudson-derived information, thanks marty-lamb].

Ant和Maven（以及Hudson和巡航控制系统），获取内部版本号为一个属性文件，或入.txt / .html文件提供了方便的手段。这是安全，足以让它与有意或无意地被篡改？难道最好将其编译成一个版本级在编译的时候？

Ant and maven (and hudson and cruise control) provide easy means for getting build numbers into a .properties file, or into a .txt/.html file. Is this "safe" enough to keep it from being tampered with intentionally or accidentally? Is it better to compile it into a "versioning" class at build time?

断言：建立编号应定义/颁布持续集成系统如哈德森。 [感谢马塞洛，莫拉莱斯]我们已经采取了这项建议，但它裂开释放的工程问题：如何不释放发生？在一个版本有多个buildnumbers？有来自不同版本之间buildnumbers有意义的关系？

Assertion: Build numbering should be defined/enacted in a continuous integration system like hudson. [Thanks to marcelo-morales] We have taken this suggestion, but it does crack open the release engineering question: How does a release happen? Are there multiple buildnumbers in a release? Is there a meaningful relationship between buildnumbers from differing releases?

问：什么是后面的版本号的目的是什么？它的作用是QA？怎么样？它是主要由开发商之间的歧义开发过程中的多个版本，或更多QA，以确定哪些构建一个最终用户得到了什么？如果目标是复制性，在理论上这是一个多么发行版本号应该提供 - 为什么不呢？ （请回答下面的答案的一部分，它会帮助你照亮做出的选择/建议...）

Question: What is the objective behind a build number? Is it used for QA? How? Is it used primarily by developers to disambiguate between multiple builds during development, or more for QA to determine what build an end-user got? If the goal is reproducibility, in theory this is what a release version number should provide -- why doesn't it? (please answer this as a part of your answers below, it will help illuminate the choices you have made/suggested...)

问：是否有在手动建立内部版本号的地方吗？这是如此困难，每个人都应该使用CI的解决方案？

Question: Is there a place for build numbers in manual builds? Is this so problematic that EVERYONE should be using a CI solution?

问：应该建立在数字被检查到SCM？如果目标是可靠且明确地识别特定的构建，如何应付各种连续或手工打造系统，这可能会崩溃/重启/等...

Question: Should build numbers be checked in to the SCM? If the goal is reliably and unambiguously identifying a particular build, how to cope with a variety of continuous or manual build systems that may crash/restart/etc...

问：如果一个内部版本号是短暂的甜蜜（即单调递增的整数），这样很容易粘成用于存档文件名，便于参考通讯等..还是应长期和充分的用户名，日戳，计算机名称等？

Question: Should a build number be short and sweet (i.e., monotonically increasing integer) so that it's easy to stick into file names for archival, easy to refer to in communication, etc... or should it be long and full of usernames, datestamps, machine names, etc?

问：请提供版本号的分配如何适合你的更大的自动释放过程的细节。是的，Maven的爱好者，我们知道这是做，做，但不是我们所有的人都喝醉了库尔急救相当，但...

Question: Please provide details about how the assignment of build numbers fits into your larger automated release process. Yes, maven lovers, we know this is done and done, but not all of us have drunk the kool-aid quite yet...

我真的很想充实了这一点，成为一个完整的答案，至少我们的CVS / ANT /哈德森设置的具体的例子，所以有人可能会建立一个基于这个问题，一个完整的战略。我会标记为答案的人谁可以给汤到坚果说明对这一特定情况下（包括CVS标记方案，相关的CI配置项目，并释放过程，折叠的内部版本号为释放，使得它的编程访问。）如果你要问/应答另一个特定的配置（比如SVN /行家/巡航控制）我会从这里链接到的问题。 --JA

I'd really like to flesh this out into a complete answer, at least for the concrete example of our cvs/ant/hudson setup, so someone could build a complete strategy based on this question. I'll mark as "The Answer" anyone who can give a soup-to-nuts description for this particular case (including cvs tagging scheme, relevant CI config items, and release procedure that folds the build number into the release such that it's programmatically accessible.) If you want to ask/answer for another particular configuration (say, svn/maven/cruise control) I'll link to the question from here. --JA

我接受了得票最多的答案，因为我认为这是一个合理的解决方案，而一些其他的答案中还包括好主意。如果有人想采取裂缝在一些合成这些物质与马蒂 - 羊肉的，我会考虑接受的不同的一个。我有马蒂 - 羊肉的唯一担心的是，它不会产生一个可靠的序列化版本号 - 这取决于本地时钟在建筑工地系统，提供明确的版本号，这是不是很大。

I accepted the top-voted answer because I think it's a reasonable solution, while several of the other answers also include good ideas. If someone wants to take a crack at synthesizing some of these with marty-lamb's, I'll consider accepting a different one. The only concern I have with marty-lamb's is that it doesn't produce a reliably serialized build number -- it depends on a local clock at the builder's system to provide unambiguous build numbers, which isn't great.

我们现在包括像下面的类。这允许版本号被编译成最终的可执行文件。不同形式的版本信息的发射在测井数据，长期归档的输出产品，并用于跟踪输出产品，我们的（甚至几年-更高版本）分析，以一个特定的版本。

We now include a class like the below. This allows the version numbers to be compiled into the final executable. Different forms of the version info are emitted in logging data, long-term archived output products, and used to trace our (sometimes years-later) analysis of output products to a specific build.

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: 325 $";  

   private static final Pattern SVNBRANCH_PAT = 
     Pattern.compile("(branches|trunk|releases)\\/([\\w\\.\\-]+)\\/.*");
   private static final String APP_SVNTAIL = 
     APP_SVNURL_RAW.replaceFirst(".*\\/svnroot\\/app\\/", "");

  private static final String APP_BRANCHTAG;
  private static final String APP_BRANCHTAG_NAME;
  private static final String APP_SVNREVISION = 
    APP_SVN_REVISION_RAW.replaceAll("\\$Revision:\\s*","").replaceAll("\\s*\\$", "");


  static {
    Matcher m = SVNBRANCH_PAT.matcher(APP_SVNTAIL);
    if (!m.matches()) {
      APP_BRANCHTAG = "[Broken SVN Info]";
      APP_BRANCHTAG_NAME = "[Broken SVN Info]";
    } else {
      APP_BRANCHTAG = m.group(1);
      if (APP_BRANCHTAG.equals("trunk")) {
        // this isn't necessary in this SO example, but it 
        // is since we don't call it trunk in the real case
        APP_BRANCHTAG_NAME = "trunk";
      } else {
        APP_BRANCHTAG_NAME = m.group(2);
      }
    }
  }

  public static String tagOrBranchName()
  { return APP_BRANCHTAG_NAME; }

  /** Answers a formatter String descriptor for the app version.
   * @return version string */
  public static String longStringVersion()
  { return "app "+tagOrBranchName()+" ("+
    tagOrBranchName()+", svn revision="+svnRevision()+")"; }

  public static String shortStringVersion()
  { return tagOrBranchName(); }

  public static String svnVersion()
  { return APP_SVNURL_RAW; }

  public static String svnRevision()
  { return APP_SVNREVISION; }

  public static String svnBranchId()
  { return APP_BRANCHTAG + "/" + APP_BRANCHTAG_NAME; } 

  public static final String banner()
  {
    StringBuilder sb = new StringBuilder();
    sb.append("\n----------------------------------------------------------------");
    sb.append("\nApplication -- ");
    sb.append(longStringVersion());
    sb.append("\n----------------------------------------------------------------\n");
    return sb.toString();
  }
}

发表评论，如果这值得成为一个维基的讨论。

Leave comments if this deserves to become a wiki discussion.

推荐答案

有关我的几个项目，我捕捉到颠覆版本号，时间，用户谁跑的构建，以及一些系统信息，将它们塞进一个.properties文件被包含在应用程序JAR，并阅读该JAR在运行时。

For several of my projects I capture the subversion revision number, time, user who ran the build, and some system information, stuff them into a .properties file that gets included in the application jar, and read that jar at runtime.

蚂蚁code是这样的：

The ant code looks like this:

<!-- software revision number -->
<property name="version" value="1.23"/>

<target name="buildinfo">
    <tstamp>
        <format property="builtat" pattern="MM/dd/yyyy hh:mm aa" timezone="America/New_York"/>
    </tstamp>        
    <exec executable="svnversion" outputproperty="svnversion"/>
    <exec executable="whoami" outputproperty="whoami"/>
    <exec executable="uname" outputproperty="buildsystem"><arg value="-a"/></exec>

    <propertyfile file="path/to/project.properties"
        comment="This file is automatically generated - DO NOT EDIT">        
        <entry key="buildtime" value="${builtat}"/>
        <entry key="build" value="${svnversion}"/>
        <entry key="builder" value="${whoami}"/>
        <entry key="version" value="${version}"/>
        <entry key="system" value="${buildsystem}"/>
    </propertyfile>
</target>

这很简单扩展这个包含的任何信息，你可能需要添加。

It's simple to extend this to include whatever information you might want to add.

这篇关于构建和版本编号为Java项目（蚂蚁，CVS，哈德森）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！