DevOps

Jenkins и продвинутый CI/CD

Amazon деплоит каждые 11,7 секунды. Netflix выкатывает изменения без единой минуты downtime. Они используют комбинацию из Jenkins-подобных pipeline, Canary releases и feature flags - и никогда не нажимают 'СТОП сервер' для деплоя. Изучим, как именно устроена эта машина.

**Netflix** использует Canary releases для каждого изменения рекомендательного алгоритма - следит за retention метриками на 1% аудитории перед полным rollout
**Facebook** запустил Instant Articles через feature flags - включали постепенно для издателей, не касаясь основного продукта
**Jenkins** используется в Toyota, NASA, крупных банках - там где самостоятельный контроль over CI/CD инфраструктуры критичен

Jenkins Pipeline: Declarative vs Scripted

Jenkins - старейший CI-сервер, появившийся в 2011 году. Несмотря на возраст, он остаётся стандартом в enterprise: тысячи плагинов, гибкость, on-premise. Сердце современного Jenkins - **Pipeline as Code**: описание CI/CD в Groovy-файле `Jenkinsfile`, который хранится в репозитории вместе с кодом.

Два синтаксиса pipeline: **Declarative** - структурированный, читаемый, покрывает 90% случаев; **Scripted** - полный Groovy, максимальная гибкость, сложнее читать. Рекомендуется начинать с Declarative и переходить на Scripted только при необходимости.

**Shared Libraries** - механизм Jenkins для переиспользования Groovy-кода между Jenkinsfile разных проектов. Хранятся в отдельном Git-репозитории, подключаются через `@Library('my-shared-lib')`. Позволяют вынести общую логику (сборка Docker, деплой, уведомления) в одно место.

В чём главное преимущество хранения Jenkinsfile в репозитории проекта?

Blue-Green Deployment

Традиционный деплой: останавливаем старую версию, запускаем новую. В этот момент сервис недоступен - downtime. **Blue-Green deployment** решает это элегантно: держим две идентичные production-среды (Blue = текущая версия, Green = новая), переключаем трафик мгновенно через load balancer.

Стоимость: Blue-Green требует двойной инфраструктуры. В облаке это решается через автоскейлинг - Green-среда поднимается только на время деплоя и уничтожается через ~30 минут (после подтверждения стабильности). Kubernetes реализует Blue-Green через смену селектора Service между двумя Deployment.

Что происходит со старой (Blue) средой после успешного переключения трафика на Green?

Canary Releases

Название - от шахтёрской традиции: канарейку брали в шахту для обнаружения газа. Если канарейка умирала - шахтёры спасались. **Canary release** работает аналогично: новую версию сначала получают 1-5% пользователей. Если метрики в норме - постепенно увеличиваем процент. Проблема обнаруживается на малой аудитории, а не на всех.

Canary в Kubernetes реализуется через два Deployment с разным числом реплик и общим Service. Более продвинутый вариант - Istio или Argo Rollouts, где трафик распределяется по весам независимо от числа реплик. Argo Rollouts поддерживает автоматическое продвижение/откат на основе Prometheus-метрик.

**Отличие от Blue-Green:** Blue-Green переключает трафик сразу (0% / 100%), Canary делает это постепенно (1% -> 10% -> 50% -> 100%). Canary подходит для изменений с неопределённым влиянием на производительность или UX. Blue-Green - для быстрых деплоев с уверенностью в качестве.

Чем Canary deployment отличается от Blue-Green?

Feature Flags

Canary разделяет пользователей случайно: 1% получает новую версию. **Feature flags** дают контроль точнее: конкретный пользователь, организация, страна или A/B-группа видит новый функционал - остальные нет. При этом код новой фичи уже задеплоен на 100% серверов, просто скрыт за флагом.

Паттерн позволяет **разделить деплой и релиз**: код деплоится часто (даже несколько раз в день), а фича включается для пользователей отдельным решением. Это снижает риск и позволяет делать trunk-based development без long-lived feature branches.

**Уборка флагов:** feature flags - временная конструкция. Включённый на 100% флаг должен быть удалён из кода в течение 1-2 недель. Накопление 'мёртвых' флагов - одна из причин технического долга. LaunchDarkly, Unleash, Flagsmith - популярные платформы для управления флагами с UI и аналитикой.

Feature flags - это то же самое, что Canary deployment, только с другим названием

Feature flags управляют видимостью функционала для конкретных пользователей. Canary управляет версией деплоя для случайного процента трафика.

Можно использовать оба одновременно: задеплоить новый код через Canary на 10% серверов, и внутри него включить фичу только для beta-пользователей через feature flag.

Команда хочет показать новый интерфейс только корпоративным клиентам, не создавая отдельный деплой. Что использовать?