Я пытаюсь понять, какие этапы используются для использования потока Git с конвейером CI / CD (доставка nb не развертывание)
Я подумал, что могу получить задание Jenkins, которое запускаетсяподталкивает к развитию ветки.И другой, который запускается, когда ветвь релиза объединяется с основной ветвью.Ниже приведен примерный набросок того, что я думаю.Это Java-проекты, использующие Gradle в качестве инструмента для сборки с несколькими подпроектами в составе репозитория.
разработчик вносит изменения в удаленную ветку dev подпроекта
конвейер ветки dev подпроекта Jenkins
- Подпроектное задание jenkins запущено
- запустить инкрементную сборку подпроекта
- , если передано, опубликовать jar снимков и исходные коды для репозитория артефактов снимков / еще отправить электронное письмо на адрес devs
- создать образ докерана основе снимка
- изображение push-докера
- запуск образа докера kubernetes на сервере dev
- запуск дополнительных тестов (например, не работает для производительности, сканирования veracode и т. д.)
- , если передана ветка разработки ветки в новую ветку выпуска для подпроекта (версия была определена во время создания) / иначе отправить электронное письмо на адрес devs
- удалить снимок из версии проекта, например.1.0-SNAPSHOT становится 1.0
- , объединяет изменения в мастер и помечает их версией и подпроектом, например.1.0-serviceX
- объединяет изменения в разработку и обновляет версию до нового снимка, например.1.1-SNAPSHOT
Главный ветвь ветки подпроекта Jenkins
- Запущено задание jenkins подпроекта
- запустить чистую сборку подпроекта
- , если прошло публикациювыпускать jar и исходники для релизов артефактного репозитория
- создавать образ докера на основе релиза
- образ push-докера
- иметь образ запуска докера kubernetes на сервере SIT
- запускать дополнительные тесты (например, не работает для производительности, сканировать veracode и т. д.)
- , если передано, есть образ запуска докера kubernetes на сервере UAT
- запускать дополнительные тесты (например, не работает для производительности,сканирование veracode и т. д.)
- Релиз готов для ручного развертывания в Prod
Таким образом, слияние с ведущим по конвейеру dev вызовет ведущий конвейер.У меня есть несколько вопросов.
- Я назвал это инкрементной сборкой для конвейера разработки, то есть не для очистки.Это хорошая идея для быстрой обратной связи?
- На аналогичной заметке для быстрой обратной связи следует пропустить интеграционные тесты?
- Если да, мне понадобится другой конвейер для ночной сборки ветки dev, котораявключает в себя интеграционные тесты.Или выполнение интеграционных тестов в основной ветке будет удовлетворительным?
- SNAPSHOTS!Я не уверен, как они вписываются в Gitflow?Они нужны мне?Если бы не на шаге 3 конвейера разработки, я бы вместо этого запустил ветку релиза, сделайте еще одну сборку с новой версией, опубликуйте ее в артефакте и т. Д. И т. Д.
Это пока подойдет!