В продолжении расскажу не много про CI / CD. Расшифровывается это довольно очевидно: CI === Continuous Integration, а в свою очередь CD === Continuous Deployment.

Принципиальная разница процессов заключается только в том, что в CI команда разработчиков проверяет состоятельность своих изменений в проекте.

Что это значит?

Первым этапом идет проверка Unit Tests, что бы покрытие не упало, что бы код был «правильный». Возможность билда как такового. Потому как фразы «у меня работает/билдится/запускается, это у вас проблемы» не должны возникать.

Если команда умеет билдить артефакт, умеет писать качественный код (это проверяется тестами), то в таком случае можно сказать, что этап именно CI пройден.

Но не совсем.

Этот этап обязан был автоматизированным. С Master ветки и/или feature веток при каждом камите/изменениях должен запускаться процесс сборки, проверки кода, проверки тестами и т.п. Инструментов масса, и все их перечислять особо нет смысла.

Сам процесс CI запускается с snapshot git репозитория и обязан никогда влиять на код в git из скриптов внутри CI.

Когда мы автоматически научились подготавливать артефакт, мы можем приступить к CD.

И тут я придерживаюсь по умолчанию относительно обыденной схемы.

Dev - Test - Stage - Prod

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

Dev

Это больше для разработчиков и лидов, где они смотрят, колупают, и оценивают изменения, миграции и т.п. самостоятельно внутри команды. Мы автоматически деплоим артефакт на Dev стенд, после CI процесса.

Test

Стенд предназначенный для e2e тестирования, для нагрузочного тестирования, для тестирования проникновений, безопасности и т.п. На данный стенд попадает тот самый артефакт, что был на Dev стенде.

Stage

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

Prod

Это уже продакшен стенд, самый защищенный из всех, без лишнего доступа из вне. Полноценный релиз версии артефакта, пропущенный через процесс подготовки и верификации целостности и качества.

Самое важное это процесс. Нельзя пропускать этапы. Если команда будет пропускать этапы в связи с неким волшебным «20-летним опытом где-нибудь в подвале», то будет страдать не команда, а организация.

Почему организация? Потому, что команда будет тратить ресурсы, время просто так, а проблем и концов найти не смогут. Таким образом такие «разработчики» делают себя «полезными».