Еще одна увлекательная тема для вас — сборка версий! Хорошо, забавно, что это не так, но это важно и в основном неизбежно. В одном из предыдущих блогов я изложил стратегию управления версиями сборки, которую предлагал использовать с нашими сборками Java. С тех пор требования изменились, как и обычно, и поэтому мне пришлось изменить соглашение о версиях.
По сути, мне нужен способ использовать номера версий артефактов, чтобы рассказать мне некоторую полезную на первый взгляд информацию об артефакте, который я создал. Кроме того, клиенты хотят, чтобы номер версии соответствовал их ожиданиям, то есть, когда они получают новую сборку, они хотят видеть легко различимую разницу в номере версии между новой сборкой и ее старой. Чего они не хотят, так это длинного сложного списка чисел, которые трудно различить. Например, гораздо проще определить, какая из следующих двух версий является последней:
- 5.0.1
- 5.0.4
но не так просто понять, какой из них самый последний:
- 5.0.1.13573
- 5.0.1.13753
Поскольку мы практикуем непрерывную доставку, любая регистрация может привести к выпуску сборки. Итак, я хотел бы каким-то образом точно определить, какая регистрация произвела мои сборки, или, по крайней мере, иметь способ выяснить, какие биты исходного кода вошли в мой выпущенный пакет. Есть несколько способов сделать это:
Пометить исходный код — мы можем сделать, чтобы сборки помечали исходный код в нашей системе SCM (Perforce) при каждой сборке. Это относительно легко сделать с помощью Ant и Maven. В Ant существует множество различных способов сделать это в зависимости от вашей системы SCM, например, с помощью subversion вам необходимо использовать задачи SvnAnt из subclipse (http://subclipse.tigris.org/svnant/svn.html) и в основном выполнять копия вашего исходного URL:
<copy srcUrl=”${src.url}” destUrl=”${dest.url}” message=”${version.num}”/>
(это потому, что теги в SVN — это просто дешевые копии с меткой).
С Maven вам просто нужно использовать плагин релиза — он автоматически обрабатывает теги для вас.
Пометить исходный код — это здорово — он позволяет сохранять номера версий настолько простыми, насколько мне хотелось бы, и хорошо отслеживается. Однако это отнимает много времени и может привести к большому количеству тегов. Другая проблема в том, что я не могу сказать, какая регистрация вызвала сборку, просто посмотрев на номер версии артефакта.
Используйте номер коммита в версии сборки — Мы используем версию сборки Major.Release.Patch-Build в наших артефактах. Раньше номер сборки был автоматически увеличивающимся числом — это работало нормально, но не давало нам ссылку на то, какой коммит вызвал сборку. Поэтому я решил использовать идентификатор списка изменений Perforce (т. Е. Версию фиксации) в качестве номера сборки в версии, чтобы сборки выглядели примерно так: 1.0.0-11531.
Проблема здесь в том, что номер версии неудобен для клиентов, поэтому я убираю номер сборки в качестве последнего шага, прежде чем сборки будут выпущены для клиентов. Чтобы отследить, какую версию получили клиенты, я по-прежнему сохраняю запись полного номера сборки (включая номер фиксации) в примечаниях к выпуску, и я также мог бы легко вставить его в информацию о сборке или в файл свойств / конфигурации, если бы пожелал , чтобы клиенты могли очень легко прочитать полный номер версии, просто заглянув куда-нибудь в меню.
Было несколько препятствий, которые мне пришлось преодолеть, чтобы заставить это работать. Первое препятствие, и действительно это было тем, что помешало мне пометить исходный код, было то, что плагин релиза maven ужасен, когда дело доходит до непрерывной доставки. Мне нужно было использовать плагин релиза, чтобы пометить исходный код, но одна из других вещей, которые делает плагин релиза maven, — это удалить слово SNAPSHOT, увеличить номер версии и вернуть pom обратно в систему контроля версий. Это приведет к запуску другой сборки в системе CI, что, в свою очередь, приведет к увеличению номера сборки и т. Д., А также к запуску другой сборки — и так далее, и так далее. В основном это создаст проект непрерывного строительства.
Поэтому я решил вообще не использовать плагин релиза maven — он не подходит для Continuous Delivery. Чтобы создать потенциальных кандидатов на выпуск при каждой успешной сборке, я удалил слово SNAPSHOT из всех poms, поэтому мы больше не делаем никаких сборок моментальных снимков (кроме случаев, когда вы собираете локально — подробнее об этом позже). Версия в poms теперь принимает номер коммита P4, который вводится через систему непрерывной интеграции, которая в моем случае называется Go. Jenkins также поддерживает это, используя плагин subversion (если вы используете subversion), который устанавливает переменную окружения с номером ревизии svn (более подробно здесь ). Плагин Jenkins Perforce делает то же самое, устанавливая переменную среды P4_CHANGELIST — так, чтобы ее можно было легко использовать (подробнее здесь).
Go берет номер списка изменений P4 и помещает его в переменную окружения под названием «GO_PIPELINE_LABEL». Я прочитал эту переменную в и назначил ее свойству p4.revision. Я делаю это в команде, которая запускает сборку, так что она перезаписывает значение по умолчанию, которое я могу сохранить в моем pom — это полезно, потому что это означает, что мои коллеги и мне не нужно вносить какие-либо изменения в pom, если мы хотите запустить сборку локально (имейте в виду, что если мы запустим ее локально, эта переменная окружения не будет существовать на наших ПК, поэтому сборка в противном случае потерпит неудачу). Вот базовый пример образца pom с более подробной информацией:
<modelVersion>4.0.0</modelVersion>
<groupId>etc.so.forth</groupId>
<artifactId>MyArtifact</artifactId>
<packaging>jar</packaging>
<version>${main.version}-${build.number}</version>
<description>Description about this application</description>
<properties>
<p4.revision>SNAP</p4.revision>
<build.number>${p4.revision}</build.number>
<main.version>5.0.2</main.version>
</properties>
<scm>
…
</scm>
<repositories>
<repository>
<snapshots>
<enabled>false</enabled>
</snapshots>
<id>release-candidate-repo</id>
<url>http://artifactory.me.com/my-rc</url>
</repository>
</repositories>
<build>
…
</build>
</project>
По умолчанию p4.revision имеет значение «SNAP», что означает, что если я сделаю локальную сборку, я получу артефакт с версией 5.0.2-SNAP. Я знаю, что эти сборки никогда не должны продвигаться в производство или передаваться клиентам, потому что слово SNAP выдает их. Однако, когда сборка создается системой CI, передается следующая команда:
clean deploy sonar:sonar -Dp4.revision=${env.GO_PIPELINE_LABEL}
Это перезаписывает значение для p4.revision, передавая номер коммита Perforce, и сборка создаст что-то вроде 5.0.2-1234 (где 1234 — мое воображаемое число коммитов p4).
Я добавил свойство main.version, которое совпадает с полной версией, но без номера сборки. Я сделал это так, чтобы я мог упаковать свои клиентские сборки (ina zip) и пометить их версией 5.0.2. В конце концов, клиенты не заботятся о номере сборки.
Важная политика, которой следует придерживаться, заключается в том, что после выпуска сборки для клиента один из других номеров версий ДОЛЖЕН быть увеличен, а это означает, что все последующие сборки будут, по крайней мере,5.0.3. Решение о том, какой номер версии увеличивать, зависит от различных бизнес-факторов — мне нравится увеличивать 3-е число, если я выпускаю патч для ранее выпущенной сборки. Если я выпускаю новую функциональность, я увеличиваю второе число. Первое число увеличивается для основных релизов. Весь вопрос с номерами версий становится намного менее сложным, если вы занимаетесь выпуском программного обеспечения для веб-серверов и вам фактически не нужно передавать программное обеспечение клиентам. В этом случае я просто сохраняю полный номер версии с номером сборки в конце, так как обычно это кто-то вроде меня, должен все равно присматривать за производственной системой!
От http://jamesbetteley.wordpress.com/2011/07/07/what-is-in-a-name-usually-a-version-number-actually/