Релиз (версия) коммит в транковой разработке - PullRequest
Новая
       92

Релиз (версия) коммит в транковой разработке

0 голосов
/ 05 января 2019

Недавно я изучал основанную на соединительных линиях разработку (https://trunkbaseddevelopment.com) и то, что мы делаем, прекрасно подходит для этого подхода (небольшая команда, частые выпуски, некоторые прямые коммиты или кратковременные ветки и т. Д.).

Единственная моя борьба - помечать релизы. Мы выполняем CI, но не все приходят в производство, и мы хотим увеличить (изменить) версию, как только код будет отправлен в среду заказчика.

Каким образом при разработке базовых линий (в идиоматическом смысле) я должен делать релиз? Как вы себя чувствуете с релизом коммитов на master? Я вижу два подхода (я использую бит Java + Maven, который просто мешает).

Подход № 1

  1. // информация о версии в транке: 'SNAPSHOT'
  2. git checkout -b release / 1.11
  3. // обновить версию в ветке релиза и зафиксировать
  4. // построить полный проект и выпустить
  5. мастер проверки git
  6. // продолжить с функциями

Подход № 2

  1. // информация о версии в транке: '1.11-SNAPSHOT'
  2. Git Branch Release / 1.11
  3. // обновить версию в основной ветке до 1.12-SNAPSHOT '
  4. git checkout release / 1.11
  5. // обновить версию в ветке релиза до '1.11' и зафиксировать
  6. // построить полный проект и выпустить
  7. мастер проверки git
  8. // продолжить с функциями

Второй подход оставляет один коммит в истории репозитория, о котором я не уверен, как к нему относиться. Последний подход делает код немного более прослеживаемым, а процесс выпуска - немного проще.

Кстати, я не особо беспокоюсь об ошибках и т. Д. Мы выпускаем новую версию. Но если требуется исправление, мы планируем выбрать вишню

1 Ответ

0 голосов
/ 05 января 2019

Вместо создания веток релиза просто для обновления версий, обрабатывает каждый коммит как освобождаемый в истинном режиме CI / CD.

  1. // Информация о версии в транке: "SNAPSHOT", никогда не редактировалось разработчиками, она используется только при локальной сборке
  2. При каждом подключении к стволу ваш инструмент CI собирает и запускает все тесты и создает повторно выпускаемый пакет. Прежде чем что-либо делать, инструмент CI заменяет версию SNAPSHOT на уникальный номер версии (см. Ниже). Это изменение версии никогда не фиксируется, оно просто используется для сборки. Для удобства отслеживания инструмент CI может добавить уникальную версию в качестве тега git, указывающего на коммит (это не обязательно, если уникальный номер версии может быть получен из информации git, как описано ниже)

Таким образом, все, что вы фиксируете в транке, это потенциальные выпуски , и никакой дополнительный процесс, кроме записи уникальной версии, отправленной клиенту, не должен выполняться как часть выпуска.

Относительно уникальных номеров версий Я обычно позволяю инструменту CI заменять версию SNAPSHOT на что-то вроде <git commit date>-<short git commit hash>, что имеет преимущества

  • Быть по-настоящему уникальным (благодаря хэшу)
  • Быть легко интерпретируемым и сравниваемым человеком (благодаря дате)
  • Воспроизводимый (благодаря использованию информации git)
...