Короткий ответ
Используйте некоторую стратегию ветвления и в своей работе сделайте что-то вроде:
IF BRANCH == DEVELOPMENT
deploy to dev
IF BRANCH endsWith SNAPSHOT
deploy to dev
IF BRANCH == MASTER
deploy to production
ETC ...
Подробный ответ
Когда разработчик выполняет толчок git в Github,Bitbucket или Gitlab, эти платформы отправляют Json на ваш сервер непрерывной интеграции (jenkis, travis и т. Д.) С большим количеством информации, связанной с событием push.Наиболее важными являются:
- имя репозитория
- имя целевой ветви: ветвь, которая получает git push
- сообщение о коммите
- автор коммита

Затем на вашем сервере непрерывной интеграции вы должны проанализировать этот Json, чтобы получить важные значения.В jenkis есть несколько плагинов, таких как: общий webhook, плагин easy webhook , плагин github и т. Д.
После извлечения значений вы можете применить простую или сложную валидацию, используя имя ветви, сообщение коммита, коммитавтор и т. д. Например:
- только производная ветвь может быть развернута в производственной среде
- только ветвь, имя которой оканчивается на «снимок», может быть развернута в среде разработки: исправление проблемы-snapshot, feature-abc-snapshot и т. д.
- Если сообщение о фиксации содержит «WIP», это будет означать, что оно все еще находится в процессе разработки или разработки, тогда развертывание не будет.
- только pushруководителя группы будет развернут
- , если сборка, модульное тестирование и другие проверки пройдены в исходном коде feature-100- development ответвления, новой ветви с именемБудет создана feature-100- release , затем эта ветвь будет развернута в среде тестирования.Эта ветка * релиза является кандидатом для развертывания в рабочей среде, если группа Q & A не обнаружит никаких функциональных проблем.
- любой другой поток автоматизации от простого к сложному.
Ваше воображение - ваше единственное ограничение.
Полезные ссылки: