Ответ
Доступ был строго регламентирован и автоматизирован через CI/CD. Прямой SSH-доступ имели только DevOps-инженеры и тимлиды. Основной процесс деплоя в продакшен осуществлялся автоматически после прохождения code review и всех этапов тестирования в пайплайне.
Пример Jenkins pipeline для деплоя:
pipeline {
agent any
stages {
stage('Build & Test') {
steps {
sh 'mvn clean package'
sh 'mvn test'
}
}
stage('Deploy to Production') {
// Деплой только для ветки main после успешного ревью
when { branch 'main' }
steps {
// Безопасный деплой через инструменты оркестрации
sh 'kubectl apply -f k8s-manifests/production/'
}
}
}
}Почему такой подход? Он минимизирует человеческий фактор, обеспечивает воспроизводимость и аудит всех изменений, попадающих в прод.
Ответ 18+ 🔞
А, ну это классика, блядь! Слушай, как у них обычно бывает: сидит какой-нибудь сеньор-разработчик, выпил кофе, и ему в голову приходит гениальная идея — «а дай-ка я прямо сейчас, сходу, на проде конфиг поправлю через SSH». И понеслась, сука: пол-сервиса легло, потому что запятуху не там поставил. Пиздец, а не подход.
Так вот, чтобы такого пиздеца не было, у умных людей всё зарегулировано и автоматизировано через эти ваши CI/CD-пайплайны. Доступ к продакшену? Да хуй там, а не доступ! Прямой SSH — это как священный грааль, только у девопсов да тимлидов, и то они им пользуются, как скальпелем хирурга — только в крайних случаях, когда всё уже ебнулось и надо ковыряться в кишках.
Основной же деплой — это священный ритуал, блядь. Код написал? Отправил в ревью. Там тебе пять коллег напишут «ты чё, мудак, тут утечка памяти на ровном месте». Поправил. Запушил. Пайплайн, этот неутомимый раб, берёт твой код и начинает его мучать: собирает, тестирует, линтует. Всё прошёл? Только тогда, сука, и только если это ветка main (она же master, она же царь-ветка), он нехотя, с придыханием, задеплоит это добро в прод. Автоматически, ёпта! Без твоих кривых рук!
Вот, глянь, как это в Jenkins выглядит, простейший пример:
pipeline {
agent any
stages {
stage('Build & Test') {
steps {
sh 'mvn clean package'
sh 'mvn test'
}
}
stage('Deploy to Production') {
// Деплой только для ветки main после успешного ревью
when { branch 'main' }
steps {
// Безопасный деплой через инструменты оркестрации
sh 'kubectl apply -f k8s-manifests/production/'
}
}
}
}Видишь? Сначала этап «Собери и проверь, не насрал ли ты в код». Потом этап «Деплой в прод», который сработает ТОЛЬКО если ты в main. И деплоит он не вручную, а через kubectl — инструмент оркестрации, который сам знает, как аккуратно подменить старые поды на новые, чтобы сервис не лег.
А нахуй такой геморрой? Да всё просто, как три копейки, блядь!
- Человеческий фактор минимизируем. Никаких «ой, я забыл». Робот не забывает. Робот не устал. Роботу не надо срать.
- Воспроизводимость. Каждый деплой — один в один. Не получится так, что у Васьки на локальной машине работает, а на проде — хуйня, потому что он там какую-то либу из кэша подтянул.
- Аудит, ёпта! По пайплайну видно — кто, когда, какой коммит и с какими тестами прошел в прод. Накосячил? Всё, пиздец, браток, тебя уже вычислили. Бери мешок и молот — идешь чинить.
Короче, смысл в том, чтобы превратить деплой из адреналинового экшена «выживет/не выживет» в скучную, рутинную, предсказуемую процедуру. А всё, что скучно и предсказуемо — то и работает, как часы. Ну, почти как часы. Иногда всё равно ебнется, но виноват будет уже не твой кривой палец, а кривой код. А это уже совсем другая история, блядь.