Стадии и их зона ответственности

1. Pre-commit / pre-push (локально). Формат и быстрый lint. Формально не часть CI, но именно здесь бесплатно ловится большая часть тривиального шума.
2. lint / vet. Отвечает на вопрос «код вообще написан осмысленно?». go vet ловит настоящие баги (неправильный Printf, копирование мьютекса, недостижимый код), golangci-lint добавляет staticcheck, errcheck (проигнорированные ошибки), gosec. Секунды или минуты, поэтому первым.
3. Unit-тесты. Логика в изоляции. Обязательно с -race хотя бы на PR: гонка, найденная здесь, стоит минуту, а в проде обойдётся в ночь. -shuffle=on ловит тесты, которые зависят от порядка, -count=1 ловит те, что проходят только из кэша.
4. Интеграционные тесты. Настоящий Postgres и брокер (testcontainers). Здесь и только здесь проверяются миграции, реальный SQL и контракты. Дороже, значит после unit.
5. build. Собирается ли артефакт под целевую платформу; multi-stage Dockerfile; CGO_ENABLED=0 для статического бинаря в distroless; -trimpath и -ldflags для воспроизводимости и версии внутри бинаря.
6. scan. govulncheck (в отличие от простого аудита go.sum он смотрит, вызывается ли уязвимая функция вообще, и ложных срабатываний резко меньше), trivy по образу (уязвимости базового слоя), gitleaks по истории (утёкшие ключи), SBOM. После build, потому что сканируем тот самый образ.
7. publish. Пуш в registry под неизменяемым тегом (git SHA), подпись (cosign), аттестация SBOM. С этого момента артефакт заморожен.
8. deploy. helm upgrade --rollback-on-failure / Argo CD sync, затем обязательная проверка «поехало ли»: kubectl rollout status, smoke-тесты по критичным маршрутам, взгляд на метрики. Ненулевой код запускает автоматический откат.

Что можно распараллелить

lint, unit-тесты и сборка образа не зависят друг от друга, их запускают параллельно и экономят минуты на каждом прогоне. Последовательность обязательна только там, где есть настоящая зависимость: build → scan образа → publish → deploy. Сборку образа можно запускать одновременно с тестами, но публиковать только после их успеха, тогда время сборки прячется за временем тестов.

Гейты: блокирующее и информационное

Блокируют мерж: компиляция, unit-тесты, -race, критические уязвимости с патчем, найденные секреты. Только предупреждают: просадка покрытия, medium-уязвимости без исправления, дубликаты. Логика в том, что пайплайн, который падает по причинам, которые сегодня не починить, начинают обходить, и тогда обходят вообще всё. Отдельным гейтом стоит ручной approval на prod-деплой: для многих команд это единственное место, где человек ещё принимает решение.

Три кэша

Отдельно про restore-keys: точное совпадение ключа бывает редко (кроме хеша go.sum, в ключе коммит), но частичное восстановление кэша от предыдущей сборки той же ветки почти так же полезно - компилятору не придётся пересобирать неизменившиеся пакеты. Это схема GitHub Actions: кэш под существующим ключом там не перезаписывается. В GitLab кэш перезаливается после каждого успешного джоба.

Docker: порядок инструкций решает всё

# Плохо: любая правка .go инвалидирует всё, включая go mod download
COPY . .
RUN go mod download && go build -o /out/app ./cmd/app

# Хорошо: зависимости отдельным слоем, он переживает почти все коммиты
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN --mount=type=cache,target=/root/.cache/go-build \
    CGO_ENABLED=0 go build -trimpath -o /out/app ./cmd/app

--mount=type=cache из BuildKit держит отдельный от слоёв кэш: он не попадает в образ и не инвалидируется вместе со слоем. Но и в экспорт кэша он не входит, так что на эфемерном раннере он пуст. В registry выносят слои: --cache-from type=registry,ref=repo/app:cache --cache-to type=registry,ref=repo/app:cache,mode=max (mode=max сохраняет и промежуточные слои, а не одни финальные). Поэтому модули здесь качаются обычным слоем и уезжают в registry вместе с ним. Плюс не забыть .dockerignore: без него в контекст сборки уезжают .git, vendor и локальные артефакты, и сборка тратит время на их передачу.

Остальные рычаги, по убыванию эффекта

• Разделить быстрые и медленные тесты. Unit гоняются на каждый push, интеграционные на PR, а полный прогон с -race, длинными и нагрузочными уезжает в ночь по расписанию. Обычно это самая большая единичная экономия.
• Распараллелить тесты. t.Parallel() внутри пакета и параллельные пакеты по умолчанию (go test -p N). Ограничитель обычно не CPU, а разделяемый ресурс: одна тестовая БД на всех сериализует прогон. Лечится схемой на пакет или контейнером на пакет.
• Не отключать кэш тестов бездумно. -count=1 нужен там, где тесты трогают внешний мир; для чистых unit-ов кэш Go честный (он учитывает содержимое файлов, env и аргументы) и экономит минуты.
• Убрать лишнюю матрицу. Три версии Go × четыре ОС для внутреннего сервиса, который всегда едет в один distroless, жгут время впустую.
• Собирать один раз. Артефакт, прошедший тесты, едет в stage и prod по digest, без пересборки. Это и быстрее, и правильнее.
• Взять раннер помощнее. Иногда самое дешёвое ускорение даёт не тонкая настройка, а машина с большим числом ядер и SSD: Go отлично параллелит компиляцию.

Как работает каждая

• Rolling. Deployment заменяет поды пачками в пределах maxSurge/maxUnavailable. Некоторое время в проде обе версии вперемешку, и трафик распределяется между ними случайно. Работает из коробки, настраивать нечего. Откат идёт таким же rolling в обратную сторону, то есть минуты.
• Blue-green. Рядом с работающим стеком (blue) поднимается полный второй стек (green) той же ёмкости. Его прогревают, гоняют по нему smoke-тесты - живого трафика на нём нет. Потом одно переключение роутера (селектор Service, вес в Ingress, target group балансировщика), и весь трафик у green. Откат переключает обратно, те же секунды. Blue держат ещё какое-то время, потом гасят.
• Canary. Новая версия получает малую долю реального трафика (1 % → 5 % → 25 % → 50 % → 100 %) с паузами между шагами. На каждой паузе сравниваются метрики канарейки и стабильной версии; при отклонении срабатывает автоматический откат. Делается весами в Ingress/Gateway API, service mesh или просто соотношением числа подов, если балансировка равномерная.

Сравнение по тому, что действительно важно

Когда что выбирают

• Rolling остаётся дефолтом для подавляющего большинства stateless-сервисов. Если релизы частые, изменения небольшие, а тесты приличные - этого достаточно, и усложнять не надо.
• Blue-green берут, когда нужен предсказуемый мгновенный откат и когда две версии вперемешку недопустимы: монолит с состоянием в памяти, жёсткое релизное окно, регуляторные требования «одна версия в момент времени». Платить придётся двойным железом на время выкатки, а в облаке это часто дороже, чем кажется.
• Canary держат для высоконагруженных сервисов на критическом пути, где даже пять минут деградации у всех стоят денег. Осмыслен только при достаточном трафике: на 5 rps 1 % канарейки не наберёт статистики за разумное время, и решать придётся по шуму.
• Shadow / dark launch нужен, когда хочется реальную нагрузку без риска: копия трафика льётся на новую версию, ответы отбрасываются. Без изоляции побочных эффектов (своя база, заглушки внешних вызовов) годится только для чтений.

Что сравнивать

1. Доля ошибок. 5xx у канарейки против 5xx у stable. Отдельно смотрят рост 4xx: он часто означает сломанный контракт API, а не «пользователи стали ошибаться». Для gRPC считают по grpc_code, потому что там всё «200».
2. Latency. p99 и p95 канарейки к p99/p95 stable, как отношение: «не хуже, чем в 1.2 раза». Абсолютные миллисекунды в этой роли бесполезны.
3. Насыщение. CPU, память (не подросло ли потребление вдвое - привет, будущий OOMKill), CFS-троттлинг, число горутин, использование пула БД. Утечка горутин видна на канарейке за минуты и не видна нигде больше.
4. Ошибки исходящих вызовов. Новая версия может начать долбить зависимость в N раз чаще - по своим метрикам она при этом «зелёная».
5. Бизнес-метрика. Самая важная и самая забываемая: конверсия, число успешных оплат, доля пустых поисковых выдач. Технически безупречный релиз, обнуливший конверсию, остаётся провалом, которого не видно ни в одном 5xx.

Как принимается решение

strategy:
  canary:
    steps:
      - setWeight: 1
      - pause: { duration: 10m }      # долго: на 1 % статистика набирается медленно
      - analysis: { templates: [{templateName: error-rate}, {templateName: latency-ratio}] }
      - setWeight: 10
      - pause: { duration: 10m }
      - analysis: { templates: [{templateName: error-rate}, {templateName: latency-ratio}, {templateName: saturation}] }
      - setWeight: 50
      - pause: { duration: 15m }
      - setWeight: 100

• Несколько замеров подряд. Один плохой интервал даёт шум, три неудачи за анализ уже сигнал. Считают их не подряд, а в сумме: Flagger откатывает, когда неудач набралось threshold, Argo Rollouts - когда их больше failureLimit.
• Минимальный объём выборки. Пока по канарейке не прошло, скажем, 1000 запросов, любые доли ошибок недостоверны. Хорошие фреймворки умеют не выносить вердикт до набора выборки.
• Прогрев. Сразу после старта пода метрики обычно хуже: холодные пулы, холодный кэш процессора, первые циклы GC - обычные эффекты холодного старта. Этот интервал надо исключать, иначе будешь откатывать каждый релиз.
• Автоматический откат по провалу - и автоматическое продвижение по успеху. Канарейка, которую надо руками двигать дальше, в пятницу вечером застревает на 10 % до понедельника.

Что даёт разделение деплоя и релиза

• Мелкие мержи вместо длинных веток. Недоделанная фича живёт в main за выключенным флагом, так что feature branch на три недели и мучительный мерж в конце не нужны. Это, собственно, и есть trunk-based development.
• Включение в удобный момент. Релиз в 10 утра понедельника при полной команде, а не в момент, когда пайплайн закончил.
• Точечный откат. Сломалась одна фича - выключили её. Остальные пять изменений этого релиза остаются в проде, чего не даёт откат версии.
• Таргетинг. Включить сначала внутренним сотрудникам, потом одному тенанту, потом 5 % по хешу user_id, потом всем. Canary так не умеет: он не знает, кто пользователь.
• Kill switch. Необязательную функциональность под нагрузкой можно выключить, это часть механики управляемой деградации.

Canary против флага, по пунктам

Они не конкурируют: в зрелой команде работают оба. Canary страхует инфраструктурный риск релиза, флаг закрывает продуктовый.

// Флаг решается один раз на границе запроса,
// чтобы внутри одного запроса поведение не «мигало» между вызовами.
func (h *Handler) Price(w http.ResponseWriter, r *http.Request) {
    ctx := r.Context()
    u := UserFrom(ctx)

    if h.flags.Enabled(ctx, "new-pricing", flag.User(u.ID), flag.Tenant(u.TenantID)) {
        span := trace.SpanFromContext(ctx)
        span.SetAttributes(attribute.Bool("flag.new_pricing", true)) // видно в трейсе
        h.newPricing(w, r)
        return
    }
    h.oldPricing(w, r)
}

Что нужно для быстрого отката кода

• Неизменяемые теги. Откатываться надо на конкретный digest, а не на latest, содержимое которого поменялось.
• Сохранённая история. revisionHistoryLimit в Deployment, helm history, предыдущий коммит в GitOps-репозитории.
• Автоматика. helm upgrade --rollback-on-failure --timeout откатывает сам при неуспехе; Argo Rollouts откатывает по анализу метрик; в самом простом варианте хватает шага CI «если kubectl rollout status вернул ошибку, делай rollout undo».
• Репетиции. Процедура, которую никто не выполнял, в три часа ночи не работает. Откат надо проверять на stage регулярно и держать в runbook.
• Обратная совместимость API. Если N+1 начал возвращать поле, на которое уже полагается фронтенд, откат сервиса ломает фронтенд. Совместимость нужна и со схемой БД, и с потребителями, и с сообщениями в очереди, которые старая версия должна уметь прочитать.

Почему база - главная сложность

Три причины, и они разной природы:

1. Состояние необратимо. Код работает как функция, его можно подменить. Данные хранят состояние: DROP COLUMN уничтожил информацию, и «откат миграции» вернёт колонку, но не содержимое. Down-миграции создают опасную иллюзию симметрии.
2. Две версии кода работают одновременно. Не «в момент переключения», а минуты - весь rolling update. Значит, схема обязана быть совместима с обеими сразу; это не пожелание, а требование.
3. Миграции блокируют. ALTER TABLE в PostgreSQL берёт ACCESS EXCLUSIVE: если он встал за долгим запросом, за ним выстраивается очередь всех запросов к таблице - сервис ложится, хотя формально «просто мигрируем».

Expand / contract на примере

-- Релиз 1 (EXPAND): только добавляем. Откат кода безопасен.
ALTER TABLE users ADD COLUMN contact_email text;          -- NULL, без DEFAULT
CREATE INDEX CONCURRENTLY idx_users_contact_email ON users (contact_email);

-- Релиз 2: код пишет в обе колонки, читает старую. Схема не меняется.

-- Релиз 3 (BACKFILL): переносим данные пачками, не одним UPDATE на 50 млн строк
UPDATE users SET contact_email = email
 WHERE contact_email IS NULL AND id IN (
   SELECT id FROM users WHERE contact_email IS NULL AND email IS NOT NULL
    ORDER BY id LIMIT 5000
 );                                                       -- в цикле, с паузами

-- Релиз 4: код читает новую колонку, всё ещё пишет в обе.
-- Здесь живём несколько дней: окно, в котором откат ещё возможен.

-- Релиз 5 (CONTRACT): код перестаёт писать в email, и только после его выкатки
-- колонку удаляют. Точка невозврата
ALTER TABLE users DROP COLUMN email;

Пять релизов вместо одного ALTER TABLE ... RENAME выглядят бюрократией ровно до первого раза, когда переименование колонки положило прод на двадцать минут.

Зачем каждое окружение

• dev даёт быструю обратную связь: синтетические данные, всё можно ломать. Деплой на каждый push, никаких гейтов.
• stage / pre-prod повторяет прод настолько, насколько это по карману: те же версии Postgres и брокера, та же схема конфигурации, обезличенные данные сопоставимого объёма. Здесь гоняются интеграционные и нагрузочные тесты и репетируются миграции.
• prod обслуживает живых пользователей. Отдельный кластер или как минимум отдельный неймспейс с жёстким RBAC, отдельные креды, отдельный доступ.
• Эфемерные окружения на PR: неймспейс поднимается на время ревью и удаляется при мерже. Дороже, но снимает вечную очередь «кто занял stage».

Как это выглядит на практике

charts/api/
  values.yaml          # общее: пробы, порты, стратегия, лимиты по умолчанию
  values.dev.yaml      # 1 реплика, DEBUG, тестовая БД, HPA выключен
  values.stage.yaml    # 2 реплики, INFO, стейджевая БД, сниженные лимиты
  values.prod.yaml     # 12 реплик, INFO, prod-хосты, PDB, anti-affinity, HPA

helm upgrade api ./charts/api --install --rollback-on-failure \
  -f charts/api/values.yaml -f charts/api/values.prod.yaml \
  --set image.digest=sha256:9f3c2a1...     # тот же образ, что проверен на stage

Источники конфигурации выстраиваются от общего к частному: значения по умолчанию в коде (чтобы приложение стартовало без единой переменной) → общий values → per-env values → Secret из хранилища → переменные окружения пода. Приложение при старте обязано провалидировать конфигурацию и упасть с внятным сообщением, если чего-то нет: «нет DSN» на старте лучше, чем nil-паника через час на первом запросе к базе.

Semver

MAJOR.MINOR.PATCH: мажор ломает контракт, минор добавляет возможности, не ломая совместимости, патч чинит, не трогая контракт. Плюс пререлизы (1.5.0-rc.1) и метаданные сборки (+build.42). В Go это не соглашение, а часть системы модулей: начиная с v2 мажорная версия входит в путь импорта (example.com/lib/v2) - именно для того, чтобы v1 и v2 могли сосуществовать в одной сборке. Отсюда следствие: бампнуть мажор в Go-библиотеке значит переименовать модуль, и относиться к этому надо соответственно.

Оговорка про сервисы: semver придуман для библиотек с внешними потребителями. У внутреннего сервиса весь контракт упирается в его API, его и версионируют отдельно (/v1/, /v2/), а сам сервис часто маркируют датой и SHA: 2026.08.26-9f3c2a1. Это нормальный, зрелый ответ.

Теги и версия внутри бинаря

# Версия зашивается в бинарь при сборке
go build -trimpath \
  -ldflags "-s -w -X main.version=v1.4.2 -X main.commit=$(git rev-parse --short HEAD) \
            -X main.buildDate=$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  -o app ./cmd/app

# Образ тегируется неизменяемо: версией и git SHA
docker tag app repo/app:v1.4.2
docker tag app repo/app:9f3c2a1          # git SHA, по нему деплоим
# repo/app:latest в проде не используется

• Тег git и тег образа указывают на один коммит и никогда не переписываются. Перевыложить v1.4.2 с другим содержимым значит сломать всё, что построено на кэше и на доверии; в registry для этого есть immutable tags, и их стоит включить.
• Деплоить лучше по digest (@sha256:...), а не по тегу: digest нельзя подменить в принципе.
• latest в проде запрещён. Непонятно, что развёрнуто; невозможно откатиться; с imagePullPolicy: Always обычный перезапуск пода превращается в незапланированное обновление версии.
• Версия должна отдаваться наружу: эндпоинт /version, строка в логе при старте, лейбл в метрике build_info - и тогда «какая версия в проде» перестаёт быть вопросом с тремя противоречивыми ответами, а на дашборде можно рисовать аннотации деплоев.

Changelog и автоматизация

Conventional Commits (feat:, fix:, feat!:) дают машине достаточно информации, чтобы (1) вывести следующую semver-версию и (2) сгенерировать changelog по разделам. Из инструментов берут git-cliff, release-please, semantic-release. Сам файл пишут по Keep a Changelog: разделы Added / Changed / Deprecated / Removed / Fixed / Security и секция Unreleased сверху.

Смысл changelog не в красоте, а в скорости диагностики: в момент инцидента ты смотришь на диапазон версий между «работало» и «не работает» и сразу видишь, какие изменения туда попали. Отдельная строка, которая должна быть в каждом релизе с миграцией: «содержит миграцию БД, откат ограничен». Она спасает дежурного от попытки откатить то, что откатывать нельзя.