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

Короткий ответ Однозначно правильного решения о переходе нет — миграцию стоит проводить постепенно, начиная с нескольких некритичных сервисов, сохраняя push-based путь как fallback до полного доверия к новой модели, и переход может быть не оправдан для небольшой организации с малым числом кластеров и сервисов, где операционная сложность внедрения и поддержки GitOps-контроллера превышает выгоды от улучшенной безопасности и аудита, которые он даёт. Как это работает подробнее при push-based модели CI-система имеет прямой доступ (учётные данные) к продакшен-кластерам для выполнения деплоя, что требует защиты этих учётных данных на стороне CI и создаёт более широкую поверхность атаки (компрометация CI-раннера = потенциальный доступ к проду). Pull-based GitOps убирает эту необходимость — контроллер внутри кластера сам забирает изменения из Git, и кластеру не нужно доверять внешней CI-системе напрямую; взамен добавляется новый компонент (сам GitOps-контроллер) с собственными требованиями к эксплуатации, обновлению и

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

Короткий ответ Нужно посмотреть тайминги отдельных стадий/джоб в интерфейсе CI, найти самую долгую и выяснить причину (рост числа тестов без параллелизации, отсутствие/поломка кэша зависимостей, нехватка раннеров и очередь ожидания, увеличившийся объём скачиваемых артефактов), а затем применить точечное решение — параллелизацию независимых джоб, шардирование тестов, восстановление кэширования или увеличение числа раннеров — вместо общего «ускорения всего». Как это работает подробнее большинство CI-систем показывают breakdown по времени каждой стадии и джобы, включая время ожидания в очереди (queue time) отдельно от времени выполнения (run time) — это ключевое различие: рост queue time говорит о нехватке раннеров/concurrency, а рост run time — о самой работе (больше тестов, больше зависимостей, медленный диск). Пример кода Что использовать на практике На практике. для долгих тестовых сьютов эффективно шардирование (разбиение тестов на N параллельных джоб по времени выполнения) и выделение быстрых smoke-тестов

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

Короткий ответ Скорее всего ключ кэша не включает хэш lock-файла (или использует слишком общий/статичный ключ), поэтому CI восстанавливает устаревший кэш `node_modules`, не замечая, что зависимости изменились; решение — построить ключ кэша на хэше актуального lock-файла (`package-lock.json`/`yarn.lock`) и проверить, что сборка действительно переустанавливает пакеты при изменении этого хэша. Как это работает подробнее системы кэширования CI (GitHub Actions cache, GitLab CI cache) сопоставляют текущий ключ с сохранёнными записями; если ключ совпадает — кэш восстанавливается целиком, без проверки его актуальности относительно реального состояния зависимостей. Если ключ не меняется при изменении `package-lock.json`, разработчик получает старые пакеты молча, без явной ошибки. Пример кода Что использовать на практике На практике. для диагностики полезно явно вывести в логе пайплайна хэш lock-файла и факт попадания/непопадания в кэш (`cache hit` / `cache miss`), а также версии реально установленных пакетов (`npm lis

Читать полностьюci-cache

Короткий ответ Тег `latest` мутабелен — он может указывать на разные образы в разное время, поэтому невозможно однозначно определить, какая именно версия кода запущена, и трудно гарантированно откатиться; вместо него нужно использовать неизменяемый тег, привязанный к конкретной версии или коммиту, например семантическую версию (`1.5.0`) или хэш коммита (`sha-abc1234`). Как это работает подробнее `latest` — это просто ещё один тег, который по соглашению Docker присваивается образу, если тег не указан явно; ничто не мешает каждому новому `docker build`/`push` перезаписывать его на другой образ. Kubernetes при этом может закэшировать старый образ на ноде и не подтянуть новый, если `imagePullPolicy` не настроена явно на `Always`, что приводит к непредсказуемому поведению подов. Пример кода Что использовать на практике На практике. с конкретным неизменяемым тегом или digest'ом (`image@sha256:...`) можно точно воспроизвести, какой код работал в момент инцидента, откатиться на конкретную прошлую версию и избежать си

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

Короткий ответ Нужно переходить на graceful cutover: сначала направлять на новое окружение только новые соединения, давая старым WebSocket-сессиям на «синем» окружении доработать и закрыться естественным образом (drain) в течение ограниченного окна, а клиентскую часть снабдить логикой автоматического переподключения с backoff, чтобы кратковременный разрыв не ощущался пользователем как сбой. Как это работает подробнее обычное мгновенное переключение балансировщика хорошо работает для коротких stateless HTTP-запросов, но долгоживущие соединения (WebSocket, gRPC streaming, SSE) обрываются принудительно, если старое окружение сразу выводится из ротации. Паттерн connection draining — балансировщик перестаёт направлять новые соединения на старое окружение, но позволяет уже установленным соединениям доработать до естественного завершения или истечения тайм-аута, прежде чем окружение останавливается. Пример кода Что использовать на практике На практике. для WebSocket-приложений стоит явно проектировать клиентскую лог

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

Короткий ответ `kubectl rollout history` показывает список предыдущих ревизий Deployment, а `kubectl rollout undo` откатывает Deployment к предыдущей (или указанной) ревизии, пересоздавая поды со старой версией образа. Как это работает подробнее Kubernetes Deployment хранит историю ревизий (ограниченную параметром `revisionHistoryLimit`). Каждая ревизия соответствует версии шаблона пода (образ, переменные окружения и т.д.). Команда `undo` запускает тот же механизм rolling update, но «в обратную сторону» — постепенно заменяет поды новой проблемной версии на поды из указанной ревизии. Пример кода Что использовать на практике На практике. откат через `kubectl rollout undo` быстрый и не требует пересборки образа, потому что использует уже существующий образ из реестра. Перед откатом полезно посмотреть `kubectl rollout history deployment/myapp` с `--revision=N`, чтобы убедиться, что откатываемся именно туда, куда нужно. Пример. Ожидаемое поведение: поды с `myapp:v1.5.0` постепенно заменяются на поды с `myapp:v1.4.

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

Короткий ответ Workflow запускается при push в любую ветку репозитория и при открытии/обновлении pull request в ветку `main`; при срабатывании он выполняет одну джобу `build`, которая скачивает код, устанавливает зависимости и запускает тесты на Ubuntu-раннере. Как это работает подробнее блок `on` определяет события-триггеры (`push`, `pull_request`), `jobs` описывает, какие задачи выполнять и на какой среде (`runs-on: ubuntu-latest`), а `steps` — последовательные шаги внутри джобы, включая готовые переиспользуемые actions (`actions/checkout`, `actions/setup-node`). Пример кода Что использовать на практике На практике. такой минимальный workflow — типичная отправная точка для CI: он не деплоит ничего, а только проверяет код. Для реального проекта к нему обычно добавляют кэширование зависимостей, линтер и отдельный workflow или джобу для деплоя, запускаемую по более узкому условию (например, только на `main`). Пример. Ожидаемое поведение: при любом push появляется новый workflow run на вкладке Actions; на вклад

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

Короткий ответ Судя по логу, упала стадия `test`: сборка (`build`) завершилась успешно, а тест `test_calculate_discount` завершился с ошибкой `AssertionError`, поэтому пайплайн остановился до стадии деплоя. Как это работает подробнее пайплайн состоит из последовательных стадий, и большинство CI-систем по умолчанию останавливают выполнение следующих стадий, если текущая завершилась с ненулевым кодом возврата. Код в логе (`exit code 1`) и явное сообщение об ошибке теста — главные подсказки для диагностики. Пример кода Что использовать на практике На практике. нужно читать лог снизу вверх или искать первое красное сообщение, а не последнюю строку — иногда после ошибки выводится ещё технический «cleanup»-вывод. Важно также смотреть, какая именно стадия помечена как failed в интерфейсе CI, а не полагаться только на текст. Пример. Правильный ответ: упала стадия `test` из-за неверного значения, возвращаемого функцией расчёта скидки; стадия `deploy` не запускалась, потому что пайплайн остановился раньше. Подводные ка

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

Короткий ответ Если миграция уже необратимо изменила данные (например, удалила колонку или данные), простой `kubectl rollout undo` вернёт старый код, но он несовместим с новой схемой и упадёт ещё сильнее — в этом случае обычно безопаснее forward-fix: быстро задеплоить исправление поверх новой схемы (а не откат кода), либо, если это возможно, восстановить совместимость схемы отдельной компенсирующей миграцией, и только потом разбираться с откатом кода при необходимости. Как это работает подробнее откат Deployment откатывает только код пода, а не состояние базы данных — если миграция уже выполнила `DROP COLUMN` или необратимо преобразовала данные, старый код, ожидающий прежнюю схему, не сможет работать ни с восстановленным, ни с текущим состоянием базы без дополнительных действий. Решение зависит от конкретной ситуации: иногда возможна компенсирующая миграция (воссоздать колонку и восстановить данные из бэкапа/лога), иногда единственный путь — быстро исправить баг в новом коде и задеплоить поверх новой схемы. П

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