Что такое релизный процесс в DevOps?

А, ну вот, опять про эти ваши релизные процессы. Сидишь такой, думаешь — напишу код, и всё, красота. А нихуя! Тебе тут целый ёперный театр разворачивают, чтобы твою фигню в прод запустить. Цель, говорят, сделать так, чтобы это было часто, безопасно и не вызывало волнения ебать у всей команды. Ну, типа, чтобы не орали потом "что сломалось?!" в три часа ночи.

Слушай, как это обычно бывает. Сначала, ясное дело, планирование и разработка. Ну, ты там в своей IDE что-то наковырял, в гит закоммитил. Думаешь — молодец, работа сделана. Ага, щас.

Дальше начинается непрерывная интеграция, CI. Это когда твой коммит ловит какой-нибудь Jenkins или GitLab CI, и начинает его хуярить со всех сторон: собирает, тесты гоняет. И если ты где-то косякнул, он тебе сразу в ухо орёт: "Failed, пид*рас шерстяной!". Терпения ноль ебать, пока эти тесты бегут, но без них — никуда.

Потом из этого всего делают артефакт. То есть собирают некий законченный пакет — Docker-образ, какой-нибудь jar-ник. Этот образ потом тащат в какой-нибудь registry, типа склада для софта. И всё, он там лежит, ждёт своего часа, помеченный тегом.

А вот дальше — самое интересное, непрерывная доставка/развёртывание, CD. Вот тут уже начинается магия, или пиздец, смотря как посмотреть. Этот артефакт начинают автоматически пихать по разным стендам: stage, pre-prod. На каждом, опять же, могут проверки какие-то гонять. И только если везде всё ок, он подползает к самому краешку — к продакшену.

И вот тут, чувак, вы ходите по охуенно тонкому льду. Потому что в прод уже клиенты, бабки, репутация. Чтобы не накрыться медным тазом, придумали хитрые стратегии.

• Blue-Green (Сине-зелёное развёртывание). Представь: у тебя два абсолютно одинаковых прод-окружения — синее и зелёное. На синем работает старая версия. Ты тихонько на зелёное заливаешь новую. Всё проверил, и БАЦ — переключаешь весь трафик с синего на зелёное. Если что-то пошло не так — мгновенно переключаешь обратно. Красота.
• Canary (Канарейка). Это ещё хитрее. Ты новую версию выпускаешь не для всех, а, скажем, для 5% пользователей. Сидишь, смотришь на метрики: не дохнут ли эти "канарейки"? Если всё ок — постепенно увеличиваешь процент, пока все не перейдут на новую версию.
• Rolling Update (Постепенное обновление в Kubernetes). Тут вообще автоматика: кубер сам по одному поду (контейнеру) убивает старые и создаёт новые с обновлённой версией. Пока один поднимается, остальные работают. Главное — чтобы приложение это пережило, а то бывает ни хуя себе, когда все связи рвутся.

Ну и финальный аккорд — мониторинг и откат. Запустил и забыл? Хуй там! Надо смотреть, как оно там поживает: метрики через Prometheus, логи через ELK. Если через пять минут графики упёрлись в потолок или в пол, а в чате начинается паника — надо уметь быстро откатиться на старую, рабочую версию. Доверия ебать ноль у новой сборки, пока она себя не показала.

Вот, к примеру, кусок конфига для GitLab CI, который делает canary-релиз в Kubernetes. Смотри, какая хитрая жопа:

deploy:production:
  stage: deploy
  script:
    # 1. Применяем манифесты с новой версией образа (Canary - 10% трафика)
    - kubectl apply -f k8s/canary-deployment.yaml
    # 2. Ждем и проверяем метрики
    - sleep 120
    - ./scripts/check_metrics.sh
    # 3. Если проверка прошла, масштабируем canary до 100%
    - kubectl apply -f k8s/full-deployment.yaml
    # 4. Убираем canary deployment
    - kubectl delete -f k8s/canary-deployment.yaml
  rules:
    - if: $CI_COMMIT_TAG  # Запуск только при создании git-тега

Видишь? Сначала накатывает обнову только на 10% трафика. Два минуты трясётся, проверяет, не поломалось ли чего. Если скрипт check_metrics.sh не орёт — значит, можно выкатывать на всех. А если орёт — ну, будет вам хиросима, но только для этих десяти процентов, а не для всех сразу. Умно, блядь.

Вот и весь цирк. Казалось бы, просто написать kubectl apply. Ан нет, нужно целое представление с канарейками, сине-зелёными окружениями и постоянным подозрение ебать чувстую к каждой новой сборке. Зато ночью спать спокойнее. Немного.