Сборка и нумерация версий для проектов Java (ant, cvs, hudson)

каковы текущие рекомендации по систематической нумерации сборок и управлению номерами версий в проектах Java? В частности:

• как систематически управлять номерами сборки в распределенной среде разработки

• Как поддерживать номера версий в исходном / доступном для приложения среды выполнения

• Как правильно интегрировать с исходным репозиторием

• как более автоматическое управление номерами версий и тегами репозитория

• как интегрировать с инфраструктурой непрерывной сборки

существует довольно много доступных инструментов, и ant (система сборки, которую мы используем) имеет задачу, которая будет поддерживать номер сборки, но неясно, как управлять этим с несколькими параллельными разработчиками, использующими CVS, svn или аналогичные.

[EDIT]

несколько хороших и полезных частичных или конкретных ответы появились ниже, поэтому я подытожу некоторые из них. Мне кажется, что на самом деле нет сильной "лучшей практики" по этому вопросу, а скорее набор перекрывающихся идей. Ниже найдите мои резюме и некоторые возникающие вопросы, на которые люди могут попытаться ответить в качестве последующих действий. [Новое в stackoverflow... пожалуйста, дайте комментарии, если я делаю это неправильно.]

• Если вы используете SVN, управление версиями определенной проверки приходит для поездки. Построить нумерацию можно используйте это, чтобы создать уникальный номер сборки, который идентифицирует конкретную проверку / ревизию. [CVS, которые мы используем по устаревшим причинам, не обеспечивает такого уровня понимания... ручное вмешательство с тегами отчасти помогает.]

• Если вы используете maven в качестве системы сборки, существует поддержка создания номера версии из SCM, а также модуля выпуска для автоматического создания выпусков. [Мы не можем использовать maven по разным причинам, но это помогает тем, кто может. [Спасибо Марсело Моралес]]

• Если вы используете АНТ в качестве вашей системы сборки следующее описание задачи может помочь создать Java .файл свойств захватывает информацию о сборке, которую затем можно сложить в сборку несколькими способами. [Мы расширили эту идею, чтобы включить информацию, полученную от Хадсона, спасибо Марти-агнец].

• Ant и maven (и Хадсон и круиз-контроль) обеспечивают легкие средства для получения номеров сборки в a .свойства файла, или .формат txt./HTML-файл. Достаточно ли это "безопасно", чтобы предотвратить преднамеренное или случайное вмешательство? Лучше ли компилировать его в класс "управление версиями" во время сборки?

• утверждение: нумерация сборки должна быть определена/введена в систему непрерывной интеграции, например Гудзон. [Спасибо Марсело Моралес] мы сделали это предложение, но оно действительно открывает инженерный вопрос выпуска: Как происходит выпуск? Есть ли несколько buildnumbers в выпуске? Есть ли серьезные отношения между buildnumbers с разных релизов?

• вопрос: Какова цель сборки? Он используется для QA? Как? Используется ли он в основном разработчиками для устранения неоднозначности между несколькими сборками во время разработки или больше для QA, чтобы определить, какую сборку получил конечный пользователь? Если цель-воспроизводимость, теоретически это то, что должен обеспечить номер версии выпуска-почему это не так? (ответьте, пожалуйста, это как часть ваших ответов ниже, это поможет осветить выбор, который вы сделали/предложили...)

• вопрос: есть ли место для номеров сборки в ручных сборках? Это настолько проблематично, что все должны использовать решение CI?

• вопрос: Должны ли номера сборки регистрироваться в SCM? Если цель надежно и однозначно идентифицируя конкретную сборку, как справиться с различными системами непрерывной или ручной сборки, которые могут аварийно завершить работу/перезапустить/и т. д...

• вопрос: Должен ли номер сборки быть коротким и сладким (т. е. монотонно увеличивающимся целым числом), чтобы его было легко вставить в имена файлов для архивирования, легко ссылаться в общении и т. д... или он должен быть длинным и полным имен пользователей, меток данных, имен машин и т. д.?

• вопрос: Пожалуйста, предоставьте подробную информацию о том, как назначение номеров сборки вписывается в ваш более крупный автоматизированный процесс выпуска. Да, возлюбленные мавены, мы знаем, что это сделано и сделано, но не все из нас уже выпили kool-aid...

Я бы очень хотел конкретизировать это в полный ответ, по крайней мере, для конкретного примера нашей установки cvs/ant/hudson, чтобы кто-то мог построить полную стратегию, основанную на этом вопросе. Я отмечу как "ответ" любого, кто может дать описание супа к орехам для этого конкретного случая (включая схему тегов cvs, соответствующие элементы конфигурации CI и процедуру выпуска, которая складывает номер сборки в выпуск так, чтобы он был программно доступен.) Если вы хотите задать / ответить на другую конкретную конфигурацию (скажем, svn/maven/cruise control), я свяжусь с вопросом отсюда. -- JA

[править 23 окт 09] Я принял ответ с высшим голосованием, потому что я думаю, что это разумное решение, в то время как несколько других ответы также включают хорошие идеи. Если кто-то хочет попробовать синтезировать некоторые из них с помощью Марти-агнецs, Я подумаю о принятии другого. Единственное, что меня беспокоит в marty-lamb, это то, что он не производит надежно сериализованный номер сборки-это зависит от локальных часов в системе строителя, чтобы обеспечить однозначные номера сборки, что не здорово.

[Править 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: 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();
  }
}

оставьте комментарии, если это заслуживает того, чтобы стать обсуждением wiki.