Кто занимается деплоем сервисов: разработчики или отдельная команда

Что проверяют

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

Как отвечать

Честный ответ: зависит от модели. Назовите свою и объясните, почему она такая.

• разработчики сами: принцип «you build it, you run it». Команда пишет Dockerfile и Helm-чарт, выкатывает и дежурит;
• платформенная команда: даёт кластер Kubernetes, шаблоны пайплайнов, GitOps через Argo CD, а продуктовые команды деплоят самообслуживанием;
• отдельная команда эксплуатации: разработчик отдаёт артефакт и инструкцию, выкатывают другие. Встречается в банках и там, где доступ к проду регламентирован.

При любой модели Java-разработчик отвечает за то, чтобы сервис был готов к деплою:

• образ: сборка через Maven или Gradle, образ через Jib или spring-boot:build-image, на JRE, а не на полном JDK;
• пробы: Spring Boot Actuator отдаёт /actuator/health/liveness и /actuator/health/readiness, их и указывают в пробах Kubernetes;
• остановка: server.shutdown=graceful, чтобы при rolling update не обрывались запросы;
• миграции: Flyway или Liquibase, причём обратно совместимые. Во время rolling update старая и новая версии работают с одной схемой одновременно.

Приведите пример из своей практики: как откатывали релиз, кто принимал решение, сколько это заняло.

Где спотыкаются

Говорят «деплоем занимаются девопсы» и не могут объяснить, что происходит с их сервисом после мержа. Для мидла и выше это минус.

Не знают про обратную совместимость миграций: переименовывают колонку одним релизом, и старые поды падают до конца выкатки.

Путают liveness и readiness. Если повесить проверку базы на liveness, при сбое базы Kubernetes начнёт перезапускать все поды по кругу, хотя их достаточно вывести из балансировки.