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

Короткий ответ Нужно использовать паттерн expand-contract (expand/migrate/contract): сначала добавить новую схему, оставаясь совместимой со старым кодом (expand), задеплоить код, который умеет работать с обеими схемами, затем перевести весь трафик на новую версию и только потом, отдельным релизом, убрать старые колонки/таблицы (contract) — так старая и новая версия приложения могут одновременно безопасно работать с одной базой. Как это работает подробнее во время rolling update или canary какое-то время одновременно работают поды со старым и новым кодом, обращаясь к одной и той же базе. Если миграция ломает совместимость со старым кодом (например, переименование или удаление колонки, NOT NULL без default), старые поды начнут падать с ошибками ещё до того, как обновление завершится. Пример кода Что использовать на практике На практике. безопасные миграции — это аддитивные изменения (новая nullable-колонка, новая таблица), которые не ломают запросы старой версии; удаляющие или переименовывающие изменения всегда

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

Короткий ответ CI — автоматическая сборка и тестирование кода при каждом изменении; Continuous Delivery — пайплайн доводит изменение до состояния «готово к выкладке», но выпуск в прод подтверждает человек; Continuous Deployment — выпуск в прод происходит автоматически без ручного шага. Как это работает подробнее при CI каждый коммит или pull request запускает сборку и тесты, чтобы быстро находить поломки. Continuous Delivery добавляет к этому автоматическую подготовку релизного артефакта и деплой на staging, но перед продакшеном стоит ручной approve. Continuous Deployment убирает этот ручной шаг — если все автоматические проверки прошли, изменение само попадает к пользователям. Пример кода Что использовать на практике На практике. многие команды, особенно в регулируемых отраслях (банки, медицина) или с высокой ценой ошибки, останавливаются на Continuous Delivery — им важен контроль момента релиза (например, не выкатывать в пятницу вечером). SaaS-продукты с хорошим покрытием тестами чаще выбирают полный Contin

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

Короткий ответ MAJOR увеличивается при несовместимых изменениях API, MINOR — при добавлении новой функциональности с сохранением обратной совместимости, PATCH — при исправлении багов без изменения публичного интерфейса. Как это работает подробнее semver (semver.org) задаёт соглашение, по которому номер версии сам по себе сообщает потребителям библиотеки или сервиса, насколько рискованно обновляться. Например, переход с `2.3.1` на `2.4.0` должен быть безопасен, а переход на `3.0.0` может сломать существующий код. Пример кода Что использовать на практике На практике. semver особенно важен для библиотек, SDK и публичных API, от которых зависят другие команды или внешние клиенты; для внутренних монолитных приложений без внешних потребителей строгая семантика иногда менее критична, но дисциплина версионирования всё равно помогает в коммуникации между командами. Пример. Ожидаемое поведение: клиент, зависящий от `^1.4.2` в package.json, безопасно получит `1.5.0`, но не получит `2.0.0` без явного изменения ограничени

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

Короткий ответ Canary-деплой выкатывает новую версию только на небольшую часть трафика или пользователей (например, 5%), пока основная часть продолжает работать на старой версии; название — отсылка к канарейкам, которых шахтёры брали под землю для раннего обнаружения опасного газа: если «канарейка» (небольшая группа пользователей) не пострадала, версию раскатывают дальше. Как это работает подробнее трафик делится между старой и новой версией по весу (например, через Ingress-аннотации, service mesh или API Gateway), и метрики новой версии (ошибки, задержка) сравниваются со старой; при отсутствии проблем доля трафика на новую версию постепенно увеличивается до 100%. Пример кода Что использовать на практике На практике. canary отличается от rolling update тем, что при rolling update нет контролируемого сравнения старой и новой версии по метрикам — просто происходит последовательная замена подов; canary же осознанно ограничивает воздействие новой версии и даёт время и данные для принятия решения «раскатывать даль

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

Короткий ответ Обычная переменная в `.gitlab-ci.yml` или workflow-файле хранится в открытом виде в Git-истории и видна всем, у кого есть доступ к репозиторию; секреты нужно хранить в защищённом хранилище секретов CI-системы (CI/CD Variables, GitHub Actions Secrets) или во внешнем менеджере секретов (Vault, AWS Secrets Manager), откуда они подставляются в пайплайн во время выполнения, не попадая в код. Как это работает подробнее защищённые переменные CI-системы хранятся отдельно от репозитория, маскируются в логах и доступны только во время выполнения джобы через переменные окружения. Внешние менеджеры секретов дополнительно позволяют централизованно управлять доступом, ротацией и аудитом. Пример кода Что использовать на практике На практике. даже защищённые CI-переменные не абсолютная гарантия — нужно ограничивать, какие ветки/окружения могут их использовать (protected variables/environments), и быть аккуратным с выводом переменных в лог (`echo $DB_PASSWORD` выведет секрет, даже если он хранится правильно). П

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

Короткий ответ В GitOps единственным источником истины для желаемого состояния окружения является Git-репозиторий с декларативными манифестами; специальный контроллер (например, ArgoCD или Flux) постоянно сверяет реальное состояние кластера с репозиторием и автоматически приводит его в соответствие. Как это работает подробнее инженер меняет YAML-манифест (например, версию образа) в Git и открывает pull request; после мерджа GitOps-контроллер, работающий внутри кластера, замечает изменение и сам применяет его через Kubernetes API — не требуется, чтобы внешняя CI-система «пушила» изменения в кластер. Пример кода Что использовать на практике На практике. такой pull-based подход снижает поверхность атаки (кластеру не нужно давать доступ внешним CI-раннерам) и даёт встроенный аудит через историю коммитов и автоматическое обнаружение дрифта — если кто-то вручную поменял ресурс через `kubectl edit`, контроллер со временем вернёт состояние к тому, что описано в Git. Пример. Ожидаемое поведение: после изменения тега н

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

Короткий ответ Нет единственно верного полного решения — типичный поэтапный путь: сначала обеспечить базовую гигиену (сканирование зависимостей и образов, иммутабельные теги, ограничение, кто может пушить в registry), затем добавить генерацию SBOM при сборке, подпись артефактов (например, cosign/Sigstore) и верификацию подписи перед деплоем, и только на зрелом уровне — полную provenance-аттестацию по модели SLSA с привязкой к конкретному билд-пайплайну; выбор глубины инвестиций зависит от требований комплаенса, модели угроз и реальной стоимости инцидента компрометации цепочки поставок. Как это работает подробнее SBOM (Software Bill of Materials, например в формате CycloneDX или SPDX) описывает все зависимости, вошедшие в артефакт, что позволяет быстро определить затронутость при появлении новой уязвимости (zero-day) в популярной библиотеке. Подпись артефакта криптографически связывает образ с конкретным сборочным процессом, а verification policy (например, через admission-контроллер Kubernetes) может блокиров

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

Короткий ответ Нужен один пайплайн сборки, который собирает и помечает артефакт уникальным неизменяемым тегом (например, по git-sha), публикует его в registry один раз, а дальше отдельные стадии/пайплайны деплоя последовательно разворачивают именно этот тег в dev, затем staging, затем prod, не пересобирая код и подставляя только конфигурацию, специфичную для окружения. Как это работает подробнее стадия `build` производит один артефакт и его метаданные (например, файл `image-tag.txt` с конкретным digest/тегом), который сохраняется как pipeline-артефакт или просто публикуется в registry с уникальным тегом. Стадии деплоя в разные окружения читают этот же тег и применяют его с окружение-специфичными values/ConfigMap, не трогая сам образ. Пример кода Что использовать на практике На практике. такой подход даёт гарантию, что в prod работает именно то, что было протестировано на staging, упрощает откат (можно вернуть предыдущий известный тег) и ускоряет повторные деплои. Обычно между стадиями ставят gate — автоматиче

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

Короткий ответ Каждый собранный образ должен получать неизменяемый уникальный тег, построенный на git-коммите (например, `sha-` или семантическую версию для релизных тегов), и в манифестах деплоя использовать именно этот тег (а ещё надёжнее — immutable digest `@sha256:...`), не полагаясь на плавающие теги вроде `latest`, `dev`, `stable`. Как это работает подробнее неизменяемый тег однозначно привязан к конкретному содержимому образа — его нельзя перезаписать, не изменив имя. Digest (sha256-хэш содержимого манифеста образа) даёт ещё более сильную гарантию, чем тег: даже если кто-то случайно перепушит тег с тем же именем (что multiple registries позволяют запретить через immutability settings), digest всё равно укажет на исходное содержимое. Пример кода Что использовать на практике На практике. плавающие теги (`dev`, `latest`, `stable`) удобны для человекочитаемой навигации, но не должны использоваться как единственный способ деплоя в GitOps-манифестах, иначе невозможно точно сказать, какая версия сейчас работа

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