git jenkins и методология построения сборки

Question

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

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

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

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

Любые другие идеи?

Answer 1

Вы можете найти это article by Martin Fowler полезным.

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

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

Answer 2

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

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

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