Шеф-повар выпускает кулинарную книгу из предыдущей ветки git

У меня есть несколько кулинарных книг CHEF, которые я развертываю. Каждый из них версионируется в соответствии с семантическим версионированием.

В моей производственной среде используется кулинарная книга 0.1.1
В рабочей среде используется кулинарная книга 0.2.0.

В версии 2.0 есть большое изменение, которое я пока не могу развернуть в рабочей среде. Обнаружена ошибка, которую необходимо исправить в версии 0.1.x. Как мне создать и развернуть поваренную книгу 0.1.2 в рабочей среде, не внося большие изменения в поваренную книгу 2.0 в рабочую среду?

Использование git-flow. Новые выпуски создаются вне ветки разработки. Затем снова слился с разработкой и тестированием. После тестов он затем объединяется с мастером, получает тег git и автоматически развертывается на сервере шеф-повара.

    0.1.1              0.2.0
   /      \           /      \
o-o--------o-o---X---o--------o-o-------- develop
 \            \                  \
  o------------o------------------o------ master

При выпуске поваренной книги ветвь выпуска удаляется.

Я предполагаю, что мне нужно проверить X, а затем создать поваренную книгу 0.1.2. Однако, когда я пытаюсь объединить поваренную книгу 0.1.2 в ветку разработки, я обнаруживаю, что metadata.rb и CHANGELOG.md имеют конфликты слияния (Y). Хотя я мог перебазировать до выпуска кулинарной книги 0.2.0, это изменило бы всю мою историю.

                         _________________
                        /                 \
     0.1.1         0.1.2     0.2.0         \
   /      \       /         /      \        \
o-o--------o-o---X---------o--------o-o------Y-- develop
 \            \                        \
  o------------o------------------------o------- master

Как лучше всего развернуть старую кулинарную книгу?

Я знаю, что подобные вопросы о переносе коммитов git задавались на SO, но ни один из них не описывает, как справляться с неизбежными конфликтами слияния. Должен ли я просто смириться с тем, что конфликты будут, и решать их вручную?

Обновить

Чтобы уточнить, у меня уже есть стратегия использования разных кулинарных книг в разных средах с использованием файла environments.json и закрепления версий. .


git merge git-flow chef-infra
person spuder    schedule 16.11.2015    source источник

Ответы (2)


arrow_upward
4
arrow_downward

Итак, два несвязанных между собой вопроса:

Во-первых, как управлять ветками обслуживания в git-flow. Мне не нравится их структура, но я думаю, что самый официальный способ — создать новую ветку из существующего тега, внести изменения, пометить отладочный выпуск, а затем объединить эту ветку с мастером.

Во-вторых, как управлять релизами в Chef. Обычно это делается в средах Chef. Каждая среда может иметь набор ограничений относительно того, какие версии каждой кулинарной книги разрешены в этой среде. Вы должны установить ограничение на производство равным ~> 0.1.0, чтобы разрешить отладочную версию, но не новую дополнительную версию. Тем не менее, в соответствии с SemVer (и связанными с ним), вы должны использовать основные версии для обозначения перерывов в совместимости.

person coderanger    schedule 16.11.2015
comment
Иметь лишь ограниченные знания о git-flow, но есть концепция поддержки филиалы. Но, похоже, это не совсем понятно. - person StephenKing; 17.11.2015
comment
ветки поддержки git прекрасно описывают мою проблему. Поскольку поваренные книги шеф-повара автоматически развертываются из основной ветки с помощью jenkins, похоже, что ветку поддержки необходимо будет объединить с основной (с конфликтами). Если я не хочу вручную загружать поваренную книгу. - person spuder; 17.11.2015

arrow_upward
1
arrow_downward

Поток Git "ветки поддержки", предложенные @StephenKing, являются ответ на проблему git и часть решения проблемы развертывания повара.

Что я в итоге сделал:

Создание новой ветки git под названием «support/1.0»

Примените мое исправление к этой ветке, затем измените metadata.rb и CHANGELOG.md на v0.1.2 и добавьте тег git.

Затем я объединил эту ветку с мастером, пропустив разработку (Z). В файлахmeadata.rb и CHANGELOG.md были конфликты, которые я разрешил вручную. Затем Дженкинс загрузил кулинарную книгу версии 0.1.2 на сервер шеф-повара.

Удалите ветку "support/1.0".

                       v0.1.2_________________
                      /                       \
     0.1.1       support/1.0      0.2.0        \
   /      \     /                /     \        \
o-o--------o---X----------------o-------o--------\-- develop
 \          \                            \        \
  o----------o----------------------------o--------Z- master

Плюсы этого подхода:

  • Нет долгоживущей ветки поддержки
  • Все еще есть поваренная книга в системе контроля версий с тегом git
  • Не нужно было перебазировать историю

Минусы

  • Основная ветка будет продолжать показывать старую версию до следующего выпуска.

Разработать metadata.rb = "0.2.0"
Мастер metadata.rb = "0.1.2"

Когда будет выпущена версия 0.2.1, файл metadata.rb в обеих ветках будет показывать правильную последнюю версию. До тех пор это потенциально может сбить людей с толку, думая, что 0.1.2 — это последняя кулинарная книга.

person spuder    schedule 17.11.2015