Git Jenkins и методология построения производства

Question

В настоящее время я использую git и jenkins с maven для выполнения сборок. Мне было интересно, каковы ваши лучшие практики с точки зрения «строительства для производства».

У меня была одна идея - создать новую ветвь (назовем ее производственной) и построить ее, когда бы мы не закончили функции на мастере.

Другая идея заключается в том, что после выпуска версии (используя maven: release) и построения этого тега.

Мне бы очень хотелось услышать некоторый реальный опыт в этой области

Есть еще идеи?

Answer 1

Мы используем описанную здесь модель ветвления http://nvie.com/posts/a-successful-git-branching-model/

Все разработки, включая исправления, выполняются в ветвях.Затем, когда одна или несколько веток объединяются в master, мы переходим к производственной сборке и развертыванию.Большая часть разработки выполняется в функциональных ветках за пределами ветви разработки.Когда работа объединяется с разработкой, она создается и развертывается в среде dev, где она используется другими проектами, т. Е. Dev является зеркалом разработки всей нашей производственной среды.Затем, когда работа сливается с веткой релиза, которая развертывается в нашей среде QA.Там он подлежит дальнейшему тестированию нашей командой QA, и когда они подписывают контракт, мы сливаемся с мастером.

Я думал о том, чтобы сделать одно изменение в этом, которое заключается в том, чтобы создать ночное автоматическое объединение всех функций и разработок в отдельную ночную ветвь, которая используется только для того, чтобы построить ее и убедиться, что у нас нет проблем слияния илиновые ошибки интеграции.Новый ночной филиал будет создаваться каждый день.

Answer 2

Вы можете найти эту статью Мартина Фаулера полезной.

Одна из основных идей CI заключается в том, что вы выпускаете код в производство из своей основной магистрали разработки. Теперь на практике при таком подходе могут быть морщины, но, по крайней мере, к этому следует стремиться.

У нас есть отдельные филиалы для разных клиентов, но не для разработки и производства. Когда мы думаем, что конкретная ревизия готова к производству (то есть проходит все автоматизированные тесты и субъективно имеет округленный набор функций), она переходит к КК, который затем «благословляет» или «проклинает» ее. Когда он проходит QC, версия помечается полу-вручную. Теоретически он может быть перестроен по требованию, но нам обычно не нужно его собирать заново, поскольку основными артефактами сборки являются установщики Release и Debug.