Continuous Delivery (CD)

Continuous Delivery (CD) — это практика автоматизированной доставки проверенного кода в целевые среды: от тестовых (staging) до производственных (production). Если CI отвечает за сборку и проверку кода, то CD — за автоматический перенос этого кода в готовое к запуску состояние. Главная цель CD — сделать релиз предсказуемым, повторяемым и безболезненным.

---

Как работает Continuous Delivery

1. Разработчик делает коммит → запускается CI: сборка, тесты, линтинг.
2. При успешной валидации — CI передаёт артефакт в CD-систему.
3. CD автоматически:
   • разворачивает приложение в staging (или production),
   • применяет конфигурации и секреты,
   • выполняет smoke-тесты или health-check,
   • запускает оповещения или ручные approvals (если нужны).
4. Финальный этап: приложение доступно конечному пользователю — без ручного SSH или скриптов.

---

Преимущества CD:

• Быстрая доставка фич и фиксов — меньше задержек между “готово” и “в продакшене”;
• Меньше ошибок — процессы повторяемы и воспроизводимы;
• Откат без паники — rollback также автоматизируется;
• Тестирование в боевых условиях — через canary, blue-green, shadow traffic;
• Снижение ручного труда — меньше зависимости от людей в процессе деплоя;
• Гибкость бизнеса — релизы подстраиваются под продуктовую динамику, а не под расписание релиз-инженеров.

---

CD vs. CI: в чём разница?

Фаза	CI (Integration)	CD (Delivery)
Что делает	Сборка, тестирование, проверка качества	Развёртывание в окружение (staging/prod)
Цель	Найти ошибки как можно раньше	Доставить рабочий код безопасно и быстро
Автоматизация	Проверка изменений	Публикация и релиз без ручных шагов
Инструменты	Jenkins, GitHub Actions, GitLab CI	Argo CD, Spinnaker, Flux, GitOps, Helm

---

Где используется CD

• Облачные среды: AWS, GCP, Azure — через Terraform, Helm, Kubernetes manifests;
• Микросервисные платформы: с использованием Istio, Service Mesh, Ingress;
• GitOps-модели: Argo CD, Flux — Git становится «источником правды»;
• Классические CI/CD-системы: Jenkins X, Spinnaker, GitLab Auto DevOps.

---

Пример типичного CD-процесса

1. Копироватьmain
   → CI → Docker-образ загружен в registry;
2. CD получает webhook от CI;
3. GitOps-компонент (например, Argo CD) обновляет манифест;
4. Kubernetes автоматически применяет новый rollout;
5. Monitoring (Prometheus, Grafana) проверяет стабильность;
6. Alert при проблемах → откат или ручное вмешательство.

---

Continuous Delivery = Надёжность + Скорость

CD позволяет организациям делать деплой не “раз в неделю”, а десятки раз в день — безопасно и без простоя. Это краеугольный камень DevOps-практик, особенно в средах, где скорость вывода продукта на рынок критична.

---

Вот — реализация CD-процесса через GitOps и Argo CD, а также примеры для CI/CD-интеграции с Helm и staging/production-потоками.

1. GitOps-поток с Argo CD

Репозитории:

• Копироватьapp-code-repo
  — код + Dockerfile +
  Копировать.gitlab-ci.yml
• Копироватьinfra-repo
  — Helm-чарты или Kubernetes-манифесты

CD-логика:

1. CI пушит Docker-образ с тегом
   Копироватьv1.3.5
   .
2. CI коммитит изменение значения
   Копироватьimage.tag
   в Helm values в
   Копироватьinfra-repo
   :
   Копироватьimage: repository: ghcr.io/my-app tag: v1.3.5
3. Argo CD отслеживает
   Копироватьinfra-repo
   → обнаруживает изменения → применяет их в кластер.

📌 Всё работает без ручного деплоя — изменения происходят через Git-коммит → GitOps CD.

---

2. Пример

Копировать.gitlab-ci.yml

— CD-коммит в Helm values

Копироватьupdate-helm-values:
  stage: deploy
  image: alpine/git
  script:
    - git clone https://$CI_REPO_TOKEN@gitlab.com/org/infra-repo.git
    - cd infra-repo/helm/my-app
    - yq -i ".image.tag = \"$CI_COMMIT_SHORT_SHA\"" values.yaml
    - git config user.name "CI Bot"
    - git config user.email "ci@mycompany.com"
    - git commit -am "Update tag to $CI_COMMIT_SHORT_SHA"
    - git push origin main

📌 Это типичный GitOps update step — никаких kubectl apply, всё через Git.

---

3. Argo CD Application манифест

КопироватьapiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
spec:
  destination:
    namespace: production
    server: https://kubernetes.default.svc
  source:
    repoURL: https://gitlab.com/org/infra-repo.git
    targetRevision: main
    path: helm/my-app
    helm:
      valueFiles:
        - values.yaml
  project: default
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

📌 Argo CD проверяет

— если тег обновился, запускает rollout.

---

Дополнительно можно:

• Добавить manual approval через GitLab environments или Argo CD webhook;
• Интегрировать Slack notifications о промоушене;
• Реализовать CD-поток staging → production с Git branch promotion (
  Копироватьmain
  →
  Копироватьprod
  );
• Настроить fallback через Git revert и автоматический
  Копироватьsync
  .

---