Построение версий в непрерывной доставке

У меня есть некоторые конкретные вопросы об управлении версиями в Continuous Delivery. Я думаю, что я понимаю глобальный рабочий процесс, который более или менее таков:

1) Code
2) Push to version Control
3) Continuous Integration (unit, integration and end-to-end auto testing)
4) Artifacts deployment

Как насчет управления версиями? Как управлять версиями сборки?

Скажем, что мы работаем над проектом Maven с семантическим управлением версиями: major.minor.build.

Когда разработчик фиксирует изменения в VCS и CI-сервере, выполните сборку, должен ли сервер CI увеличивать версию сборки и создавать тег в VCS?

Эта версия сборки присутствует в исходном коде? Если это так, после каждого нажатия на VCS разработчик должен обновить проект, так как сервер CI зафиксировал изменения (увеличение версии) в проекте.

Я немного смущен, и я хотел бы понять практический процесс работы с CD.

Ответы

Ответ 1

В общем, вы должны иметь:

  1. Номер версии, управляемой вручную.
  2. Любое число "ссылочных" номеров.

Первый момент имеет решающее значение, если вы заботитесь о semver или в случае, если вам нужно предоставить информацию о совместимости для других инструментов /lib. Только вам, кто может сказать, что новый "релиз" что-то сломал - самая популярная система индикации следит за правилами управления версиями semver.

Второй пункт ("ссылочный" номер) может быть или не быть важен для вас. Обычно вам не нужно больше одного, номер версии сборки CI/CD (каждая популярная служба CI/CD имеет идентификатор номера версии сборки, который относится к этой конкретной "сборке"). Точка этого числа состоит в том, что вы можете быстро проверить связанные сборки/записи CI/CD артефакта, если вам это нужно.

Как объединить две (или более) части?

Это не редкость иметь отдельные "версии" и "строить" числа. Фактически, каждый проект iOS по умолчанию. В этом случае номер "версии" управляется вручную, а отдельный номер "сборки" управляется автоматически. Номер сборки может быть в имени артефакта или может быть напечатан, когда кто-то извлекает информацию --version в случае двоичного --version (например: $ brew info → 0.9.5 (git revision 18c48; last commit 2015-11-02)

В качестве альтернативы вы можете добавить новые компоненты в semver (xxxBUILDNUM), использовать последний компонент semver (xxBUILDNUM - я бы не рекомендовал это, если у вас есть строго инкрементный BUILDNUM) или просто BUILDNUM номер сборки в имя артефакта,

Это все возможности, вам нужно выбрать лучший вариант для вашего дела. Вы должны определить значение этих чисел и решить, где должен быть представлен номер (например, если он будет частью вызова --version или должен быть только частью имени файла).

edit: задуматься над вопросом о том, должен ли сервер CI наращивать версию сборки и создавать тег в VCS? " - Я бы никогда не рекомендовал это. Сервер CI также может иметь проблемы, вы никогда не должны изменять свой код из процесса CI. Случайное переписывание (например, принудительное нажатие) может быть действительно опасным. Поэтому лучше просто использовать номер сборки, открытый службой CI/CD.