Comments 12
Ключевые моменты нашего подхода:
1. Номер версии — уникальный идентификатор. Если создается ветка, то это отражается в компоненте версии в виде уникального значения (например, «1.0.0.github»).
2. Источник номера версии находится в файле «version.txt», который может быть легко прочитан скриптом автоматической сборки/дистрибуции и не зависит от системы сборки.
3. Основанием для сборки является выпуск новой версии, при этом в Git-репозиторий добавляется метка (tag) со значением версии. Т.е. триггером сборки является появление метки. Метка является привычным маркером релиза для сервисов хостинга git-репозиториев.
4. Для автоматизации переключения версии написана небольшая кросс-платформенная утилита «verctl» (см. https://github.com/gelsrc/verctl/). По ссылке есть и описание утилиты, если это интересно.
Исходный код упомянутой утилиты является примером описанного подхода.
Исходя из этого, нам не нужно предоставлять информацию о хэше коммита, ветке и т.п., т.к. по нашим правилам версия однозначно соответствует исходному коду. И сам подход, собственно, не привязан конкретно к Git и Maven.
Это все разумно и понятно, но как быть с дев-билдами? Как отличить билд с фиксом от билда без фикса?
Это все разумно и понятно, но как быть с дев-билдами?
Можно предложить разные варианты.
1. Префикс метки Git: («v» — release, «d» — dev).
2. Суффикс метки/версии (например, «1.0.0» — release, «1.0.0.dev» — dev).
3. По количеству компонент версии (например, «1.0.0» — release, «1.0.0.0.0» — dev).
Как отличить билд с фиксом от билда без фикса?
Если делается ответвление от ранее выпущенной версии (накладывается на нее фикс), то это можно выделить увеличением числа компонент.
Т.е. если базовая версия был «1.2.3», то на ее основе создается ветка «1.2.3.0», «1.2.3.1» и т.д.
Да нет, это понятно. Вопрос в том, что придется каждый коммит меткой снабжать или творить для каждого коммита ветки, а это лишняя работа в случае веток (которые в 95% случаев сливаются без проблем, а в 5 — оказываются причиной головной боли) или сомнительная польза в случае меток. Ну вот, например, dev-бранча, за неделю на нее пополо 2-3 новых фичи и 5-10 фиксов/мелких улучшений, каждый билд деплоится для тестирования. Практически каждый день — новый билд или два. Велика ли польза от меток на всех соответствующих коммитах, если можно вытащить автоматически хэш коммита и подтянуть в ui список изменений из git-лога автоматически?
Вопрос в том, что придется каждый коммит меткой снабжать или творить для каждого коммита ветки, а это лишняя работа в случае веток
Операции увеличения версии и проставления метки производятся автоматически скриптом релиза, который запускается ответственным за релиз. Сборка и деплой делаются полностью автоматически. Поэтому лишней работы здесь не видно.
Польза от меток — в из читаемости и последовательности.
Если есть метка, то по ней можно однозначно вычислить хэш коммита. Поэтому отдельная информация о хэше вроде как и лишняя.
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
иначе application.property останется не процеснут и значения не будут подставленны
Использую в качестве идентификатора билда строку, аналогичную полученной командами
`git describe --tags || git log -n1 --pretty=%h || echo unknown`Команды вызываются через sbt, формируются ресурсы для программы и системы упаковки.
Идентификатор билда не сформируется, если в PATH нет git, но у меня обычно есть.
git-commit-id-plugin?
Логирование Git revision в Java с помощью Maven