Каковы современные рекомендации по систематической нумерации сборок и управлению номерами версий в проектах Java? В частности:
Как систематически управлять номерами сборки в распределенной среде разработки
Как сохранить номера версий в исходном / доступном для приложения времени выполнения
Как правильно интегрироваться с исходным хранилищем
Как более автоматически управлять номерами версий по сравнению с тегами репозитория
Как интегрироваться с инфраструктурой непрерывной сборки
Существует довольно много доступных инструментов, и у ant (используемой нами системы сборки) есть задача, которая будет поддерживать номер сборки, но неясно, как управлять этим с несколькими параллельными разработчиками, использующими CVS, svn или аналогичные ,
[РЕДАКТИРОВАТЬ]
Ниже приведены несколько хороших и полезных частичных или конкретных ответов, поэтому я кратко изложу некоторые из них. Для меня это звучит так, будто на самом деле нет сильной «лучшей практики», скорее, это набор совпадающих идей. Ниже, найдите мои резюме и некоторые итоговые вопросы, на которые люди могут попытаться ответить как продолжение. [Новое в stackoverflow ... пожалуйста, предоставьте комментарии, если я делаю это неправильно.]
Если вы используете SVN, версия проверки конкретной проверки приходит вместе с поездкой. Нумерация сборок может использовать это для создания уникального номера сборки, который идентифицирует конкретную проверку / ревизию. [CVS, которую мы используем по устаревшим причинам, не обеспечивает такого уровня понимания ... ручное вмешательство с тегами поможет вам частично.]
Если вы используете maven в качестве своей системы сборки, имеется поддержка для создания номера версии из SCM, а также модуль выпуска для автоматического создания выпусков. [Мы не можем использовать Maven по разным причинам, но это помогает тем, кто может. [Благодаря Марсело-Моралесу ]]
Если вы используете ant в качестве своей системы сборки, следующее описание задачи может помочь создать файл Java .properties, содержащий информацию о сборке, которую затем можно добавить в вашу сборку несколькими способами. [Мы расширили эту идею, чтобы включить информацию, полученную из Хадсона, спасибо marty-lamb ].
Ant и maven (а также hudson и круиз-контроль) предоставляют простые средства для получения номеров сборки в файле .properties или в файле .txt / .html. Достаточно ли это «безопасно», чтобы предотвратить его умышленное или случайное вмешательство? Лучше ли скомпилировать его в класс управления версиями во время сборки?
Утверждение: нумерация сборки должна быть определена / принята в системе непрерывной интеграции, такой как Hudson . [Спасибо marcelo-morales ] Мы приняли это предложение, но оно решает вопрос инженерии релиза: как происходит релиз? Есть ли в релизе несколько сборочных номеров? Есть ли значимые отношения между номерами сборок разных версий?
Вопрос: Какая цель стоит за номером сборки? Это используется для QA? Как? Используется ли он в основном разработчиками для устранения неоднозначности между несколькими сборками во время разработки или для QA, чтобы определить, какую сборку получил конечный пользователь? Если целью является воспроизводимость, теоретически это то, что должен предоставить номер версии релиза - почему бы и нет? (ответьте, пожалуйста, как часть ваших ответов ниже, это поможет осветить выбор, который вы сделали / предложили ...)
Вопрос: есть ли место для номеров сборок в сборках вручную? Это настолько проблематично, что КАЖДЫЙ должен использовать решение CI?
Вопрос: Должны ли номера сборок регистрироваться в SCM? Если цель - надежно и однозначно идентифицировать конкретную сборку, как справиться с различными системами непрерывной или ручной сборки, которые могут давать сбой / перезапуск / и т. Д.
Вопрос: должен ли номер сборки быть коротким и понятным (т. Е. Монотонно увеличивающимся целым числом), чтобы его можно было легко вставить в имена файлов для архивирования, легко ссылаться при общении и т. Д., Или он должен быть длинным и полным имен пользователей, отметки даты, названия машин и т. д.?
Вопрос: Пожалуйста, предоставьте подробную информацию о том, как назначение номеров сборки вписывается в ваш более крупный процесс автоматического выпуска. Да, любители мавена, мы знаем, что это сделано и сделано, но не все из нас уже выпили kool-aid ...
Я действительно хотел бы изложить это в полном ответе, по крайней мере, для конкретного примера нашей установки cvs / ant / hudson, чтобы кто-то мог построить полную стратегию на основе этого вопроса. Я отмечу как «Ответ» любого, кто может дать подробное описание для этого конкретного случая (включая схему тегирования cvs, соответствующие элементы конфигурации CI и процедуру выпуска, которая сворачивает номер сборки в выпуск таким образом, чтобы он программно доступен.) Если вы хотите спросить / ответить для другой конкретной конфигурации (скажем, svn / maven / круиз-контроль), я сделаю ссылку на вопрос здесь. --JA
[РЕДАКТИРОВАТЬ 23 октября 2009 г.] Я принял получивший наибольшее количество голосов ответ, потому что считаю это разумным решением, хотя некоторые другие ответы также включают хорошие идеи. Если кто-то хочет попытаться синтезировать некоторые из них с marty-lamb '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();
}
}Оставьте комментарии, если это заслуживает того, чтобы стать вики-обсуждением.
gradleи / или git?