Наша команда состоит из 30 человек, включая до 10 разработчиков.
Мы уже несколько месяцев используем ANSIBLE, но до сих пор не смогли прийти к единому мнению: какуправляйте «требованиями», чтобы включить наши различные роли (не в том же репо, что и книга воспроизведения) в зависимости от среды, чтобы избежать конфликтов, проблем слияния, умножения тегов и т. д.
Роли / книги воспроизведения размещаются начастный репозиторий gitlab. У каждой роли есть свой проект, и есть еще один для playbooks / инвентаря.
Мы используем Jenkins + ansible (playbook / galaxy) + бастион, созданный Дженкинсом (но у нас нет контроля над созданием.)
masterDeploy.git/
|__ playbook_A.yml
|__ requirements_for_A.yml
|__ inventory_per_environment/
|__ group_vars/
|__ inventory
role_1.git
role_2.git
role_3.git
Таким образом, любой может поделиться тем, что он считает наилучшей практикой, в соответствии со следующими ограничениями (список не является исчерпывающим):
- мы не хотим умножать теги(но мы можем очистить при необходимости)
- требования специфичны для среды: на этапе подготовки мы хотим протестировать новые текущие версии и / или новые роли, в то время как разработчики будут работать над входящими.
- из-за gitlab мы не можем предотвратить слияние определенных файлов (с использованием стратегии .gitattribues и merge.driver), таких как требования
- , некоторые разработчики - новички, и они не задержатся надолго. Таким образом, процесс должен быть для них достаточно простым (даже если это означает разработку какой-либо работы над сценариями / jenkins, чтобы помочь им)
- мы бы хотели, чтобы требования находились под контролем версий (но не были обязательными в том же репо) вЧтобы иметь возможность «выпускать» одновременно, мы выпускаем книги, источники, роли и т. д.
- каждый раз, когда разработчик начинает новую пользовательскую историю, он / она создаст 2 ветви (одну для masterdeployи один для роли), с определенным требованием, предназначенным для новой ветви для роли. Мы действительно не хотим, чтобы это специфичное для отрасли требование стерло dev / staging / production.
Спасибо за то, что поделились своим опытом, даже если они не отвечают всем вышеперечисленным требованиям.