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

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

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

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

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

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

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

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

[EDIT]

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

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

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

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

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

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

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

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

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

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

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

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

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

[Edit Jul 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();
  }
}

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