🚀 CI/CD и управление релизами

Короткий ответ Нет универсально «самой дешёвой» стратегии — rolling дешевле по ресурсам (не требует дублирования всей ёмкости), blue-green обычно требует кратковременного удвоения инфраструктуры на время релиза, а canary занимает промежуточное положение (небольшой избыточный набор подов на время анализа); решение о стратегии по умолчанию должно опираться на профиль риска и критичность большинства сервисов, оставляя явные исключения (canary/blue-green) для сервисов с высокой ценой ошибки, а не применяя самую дорогую стратегию ко всем 200+ сервисам без разбора. Как это работает подробнее стоимость стратегии складывается не только из compute-ресурсов на время релиза, но и из операционной сложности — canary требует зрелой системы метрик и, как правило, выделенного progressive-delivery контроллера (Argo Rollouts/Flagger), blue-green требует инфраструктуры, способной держать два полных окружения (включая стоимость лицензий, if any, и сетевой конфигурации), rolling почти не добавляет накладных расходов сверх небольш

Читать полностьюblue-green-deployment

Короткий ответ Сначала быстро проверить логи и события пода (`kubectl logs --previous`, `kubectl describe pod`), чтобы понять причину (ошибка конфигурации, недоступная зависимость, паника приложения при старте); если причина не устраняется мгновенно и очевидно (например, опечатка в переменной окружения), безопаснее сразу выполнить `kubectl rollout undo`, а разбираться с первопричиной уже на спокойном окружении (staging/локально). Как это работает подробнее CrashLoopBackOff означает, что контейнер завершается с ошибкой и Kubernetes с нарастающей задержкой пытается его перезапустить. `kubectl logs --previous` показывает вывод именно упавшего контейнера (текущий лог может быть пустым, если контейнер уже перезапустился), а `kubectl describe pod` — события вроде `OOMKilled`, `Error`, `BackOff`. Пример кода Что использовать на практике На практике. при наличии rolling update в проде часть старых подов обычно ещё жива, поэтому сервис может продолжать частично работать — но решение об откате нужно принимать быстро, н

Читать полностьюcicd-and-release-management

Короткий ответ Нужно искать источники недетерминированности, которые отличают CI от локальной машины: параллельное выполнение тестов, общие ресурсы между тестами, зависимость от времени/таймзоны, сетевые тайм-ауты до внешних сервисов, недетерминированный порядок выполнения и различия версий зависимостей/окружения (ОС, версия языка, часовой пояс раннера). Как это работает подробнее локальная машина обычно запускает тесты последовательно и с «тёплым» состоянием (прогретый кэш, запущенные сервисы), а CI-раннер — чистое окружение, часто с параллельными джобами и ограниченными ресурсами (CPU/память), что обнажает гонки состояний (race conditions), неправильные допущения о порядке тестов или неосвобождённые ресурсы (открытые порты, файлы, тестовые данные в общей БД). Пример кода Что использовать на практике На практике. диагностику начинают с повторного прогона упавшего теста изолированно много раз (`--repeat` или аналог), включения подробных логов и таймингов, проверки использования shared-состояния (глобальные пе

Читать полностьюcicd-and-release-management

Короткий ответ Стадия `build` превращает исходный код в исполняемый артефакт (образ, бинарник, пакет), а стадия `deploy` доставляет уже готовый артефакт в целевое окружение и запускает его там; без собранного артефакта стадии деплоя либо нечего разворачивать, либо она ошибочно соберёт код «на лету», теряя воспроизводимость. Как это работает подробнее `build` отвечает за компиляцию, установку зависимостей и упаковку; `deploy` отвечает за обновление инфраструктуры — например, применение Kubernetes-манифеста, обновление образа в Deployment или копирование файлов на сервер. Это разделение ответственности позволяет повторно использовать один артефакт для разных окружений. Пример кода Что использовать на практике На практике. если смешать сборку и деплой в одной команде/скрипте, сложнее тестировать стадии по отдельности и труднее гарантировать, что в staging и в production попал один и тот же код. Разделение также ускоряет повторные деплои — не нужно пересобирать, если нужно просто откатиться на предыдущую версию.

Читать полностьюartifacts

Короткий ответ Staging — это окружение, максимально похожее на production по конфигурации и инфраструктуре, но изолированное от реальных пользователей, где можно безопасно проверить изменения перед релизом; production обслуживает реальный трафик, и ошибки там напрямую влияют на пользователей и бизнес. Как это работает подробнее типичный pipeline разворачивает артефакт сначала на staging, где автоматические и иногда ручные тесты проверяют его поведение на данных и конфигурации, близких к боевым, и только после успешной проверки тот же артефакт промотируется в production. Пример кода Что использовать на практике На практике. staging не всегда идентичен production на 100% (объём данных, количество реплик, внешние интеграции), и это важно учитывать — некоторые проблемы (под нагрузкой, с редкими данными) staging не воспроизводит. Поэтому staging снижает риск, но не заменяет мониторинг и осторожные стратегии выкладки (canary, feature flags) в самом проде. Пример. Ожидаемое поведение: деплой в production возможен то

Читать полностьюcicd-and-release-management

Короткий ответ Автоматическая джоба деплоя запускается сама сразу после успешного прохождения предыдущих стадий; ручная (`when: manual` в GitLab CI или approval-джоба в GitHub Actions/Environments) ждёт, пока человек явно нажмёт кнопку запуска — это полезно для production, когда нужен контроль момента выкладки или дополнительное подтверждение. Как это работает подробнее ручной шаг не убирает автоматизацию самого процесса деплоя — скрипт выполняется так же, как при автоматическом запуске, разница только в триггере: ожидание действия человека вместо автоматического продолжения пайплайна. Пример кода Что использовать на практике На практике. ручной approve для прода часто сочетают с выбором времени релиза (не в пятницу вечером, не во время пиковой нагрузки), с дополнительной проверкой чеклиста перед выкладкой или с требованиями комплаенса (например, подтверждение от уполномоченного сотрудника). Для dev/staging обычно автоматический деплой, чтобы быстрее получать обратную связь. Пример. Ожидаемое поведение: после

Читать полностьюcicd-and-release-management

Короткий ответ ArgoCD продолжает считать Git источником истины: если включена автоматическая синхронизация (`automated sync`) с `selfHeal: true`, он автоматически откатит ручное изменение обратно к тому, что описано в репозитории; правильный способ внести изменение — сначала поправить манифест в Git и дождаться синхронизации, а не менять ресурс напрямую в кластере. Как это работает подробнее ArgoCD периодически (и по webhook) сравнивает фактическое состояние ресурсов в кластере с desired state из Git. Статус `OutOfSync` означает обнаруженное расхождение. С `selfHeal: true` расхождение исправляется автоматически в течение следующего цикла сверки; без `selfHeal` ресурс просто помечается как рассинхронизированный, пока кто-то не нажмёт Sync вручную или не исправит разницу. Пример кода Что использовать на практике На практике. ручные изменения прямо в кластере («kubectl edit в проде») — частая причина путаницы в GitOps-командах: инженер решает проблему «здесь и сейчас», а через несколько минут ArgoCD незаметно от

Читать полностьюargocd

Короткий ответ Required status checks не дают смёржить pull request, пока указанные проверки (тесты, линтер, сборка) не завершатся успешно; это защищает основную ветку от попадания заведомо сломанного кода. Отключение таких проверок позволит мёрджить код даже при падающих тестах, повышая риск сломать main и, как следствие, пайплайны и деплои для всей команды. Как это работает подробнее в настройках защиты ветки (branch protection rules) указывается список статус-чеков, которые GitHub/GitLab должны получить от CI как «success», прежде чем кнопка мерджа станет активной. Это работает независимо от решения ревьюера — даже одобренный PR нельзя слить, если чек не прошёл. Пример кода Что использовать на практике На практике. required checks — один из самых дешёвых и эффективных способов поддерживать `main` в рабочем состоянии, особенно в командах с частыми мерджами от разных разработчиков. Их обычно дополняют требованием хотя бы одного одобрения код-ревью. Пример. Ожидаемое поведение: кнопка merge в интерфейсе остаё

Читать полностьюartifacts

Короткий ответ Скорее всего новый под не проходит readinessProbe и поэтому никогда не становится Ready, из-за чего Kubernetes не продолжает заменять оставшиеся старые поды — нужно посмотреть `kubectl describe pod` на новый под, проверить `Events` (например, `Readiness probe failed: HTTP probe failed with statuscode: 500`) и логи приложения, чтобы понять, что именно не проходит проверку, затем либо исправить код/конфигурацию, либо явно откатить обновление. Как это работает подробнее rolling update продолжает заменять старые поды новыми только после того, как ранее созданные новые поды подтвердят готовность через readinessProbe; если новый под навсегда остаётся NotReady (например, из-за недоступной зависимости при старте, неверного пути health check endpoint или слишком строгого таймаута пробы), Deployment «застревает», не превышая настроенный `maxUnavailable`, и старые поды продолжают обслуживать трафик — это защитный механизм, не баг. Пример кода Что использовать на практике На практике. диагностику начинают

Читать полностьюartifacts