Continuous deployment

1) What is CD and how is it different from CI/CD

Continuous Deployment (CD) is the practice of automatically rolling out each verified change to the prod, without manual "release trains." CD differs from CI (automatic assemblies and tests at commits) in that it completes the chain: code → artifact → verification → production. In regulated industries, CDs are often combined with progressive delivery.

• Reduce Time-to-Market and change costs.
• Reduce the risk of large releases: small batches → easier to find the reason and roll back.
• To bring quality discipline: "each commit is potentially for sale."

2) Basic principles

Small increments. Short fiche branches, quick reviews, aggressive merjing.
Assembly determinacy. Repeatable build environments, lock files, hermetic builds.
Shift-left-quality. Linters, static analysis, unit/contract tests prior to integration.
Production-like environments. Identical configs, secrets via vault, data - synthetic/impersonal.
Automate the entire journey. From commit to traffic routing and rollback.
Default observability. Metrics, logs, traces, alerts - as part of Definition of Done.
Security-by-design. SAST/DAST, SCA, signed artifacts, policy validation.

3) Reference architecture of the CD pipeline

1. Trigger - event in VCS (push/merge) marked "prod-eligible."

2. Build: build artifact (image, package), SBOM, signature (Sigstore/Cosign).
3. Test Fast: lint/unit/contract; fast feedback (<5-10 min).
4. Test Deep (in parallel): integration, E2E, load "on the profile," chaos samples in the stage.
5. Security Gate: SAST/DAST/SCA, checking secrets, checking policies (OPA/Conftest/Kyverno).
6. Compliance Gate: SoD/4-eyes if necessary, traceability of requirements, checklists.
7. Promote: promotion of the artifact as one and the same build through environments (dev → stage → prod).
8. Deploy Strategy: blue-green / canary / progressive + feature flags.
9. Post-Deploy Verification: auto-health, SLO/SLA, alerts, auto-rollback during degradation.
10. Audit & Evidence: artifacts, logs, verification protocols - in unchanging storage.

4) Release strategies

Blue-Green: two production stands (Blue = current, Green = new), atomic routing switching. Plus - instant rollback. The downside is dual infrastructure.
Canary: batch start of traffic (1% → 5% → 25% → 100%) with automatic SLO-gates.
Progressive Delivery: target cohorts (region, provider, VIP segment), damage radius limit.
Feature Flags: supply code "off," enable by users/cohorts. Mandatory: "flag lifecycle" policy.

5) Testing and quality

Contract tests and consumer-driven contracts for independent microservice releases.
Load profiles by real patterns (RPS, p95/p99, open/closed models).
Tests of database migrations: direct/reversible, compatibility of two versions (expand → contract).
Chaos/Resilience samples: disabling dependencies, network delays, resource limits.
Post-release verification (smoke + synthetic) from points close to the user.

6) Security and compliance in CD

Artifact signature, provenance, SBOM. We track the origin, exclude the "supply chain" risks.
Policy-as-Code: we only allow images from the trusted registry, with scan passing.
Secrets: short-lived tokens, rotating keys, KMS; banning secrets in the gita.
Segregation of duties (SoD): development ≠ production access; all operations through the pipeline.
Audit trail: unchangeable release logs, who/what/when; storage N years according to regulatory requirements.

7) Change management and risk control

Change Types: standard (fully automatic), normal (auto + approval), emergency (accelerated window + post-mortem).
CAB minimalism: CAB for changed risks and infrastructure "breaking" updates, the rest - through automatic quality gates.
Risk Matrix: influence × probability → choice of strategy (canary deeper, flags, additional monitoring).
Runbooks & Playbooks: Clear instructions for each type of release and rollback.

8) Observability, SLO and auto-rollback

Golden signals: latency, errors, saturation, traffic; business metrics (conversion, deposit, payment success).
Guardrails: if p95> threshold, error rate↑, business metrika↓ - auto-stop/rollback.
Release Dashboards: widgets: versiya→metriki→flagi→kanareyechnyye share of traffic.
Alerts: noise reduction levels, on-call rotations, communication with incident management.

9) CD Metrics

DORA metrics: depletion rate, lead time for changes, MTTR, share of unsuccessful releases.
Change-failure-rate on cohorts (by provider, region, device).
Gate pass time: where are the "bottlenecks" (security scan, integration tests).
Cost-to-Release: cost per minute window, infrastructure markup of strategies (blue-green vs canary).

10) Rollback patterns and compatibility

Auto-rollback: at the level of routing (traffic switch) and/or versioning (K8s rollout undo).
Database migrations: expand-migrate-contract strategy, feature flags hide inaccessible fields.
Idempotency & Exactly-once-like: for queues/payments - idempotency keys, deduplication.
Back-pressure and graceful degradation: if degraded, disable non-functional features.

11) Practical model of environments

GitOps approach: the target state is stored in the git, the controller applies manifests.
Environments: 'dev' (fast and dirty), 'stage' (prod-like, chaos-samples), 'prod-A/B' (blue-green) or 'prod' with canary pools.
Data isolation: configs as data, secrets outside the image, individual accounts/limits.

12) Processes and roles

RACI: Architect (Policies), Platform Team (Pipeline, Clusters), Product Teams (Tests/Flags), Security (Policies/Scans), SRE (SLO/Reliability).

ChatOps: releases from PR bots, visibility of statuses, "/promote, ""/rollback."

SOP: release checklists, post-release review, aging flags control.

13) Features for highly regulated domains (e.g. iGaming/fintech)

Traceability - Audit trebovaniye→tiket→PR→bild→artefakt→sreda→log.
Geo-release: by country/jurisdiction, with local payment configuration/LCC.
Anti-fraud/risk engines: canary traffic pools, false-positive/negative monitoring.
KYC/AML/responsible game: release features through flags with mandatory monitoring of user impact.

14) Frequent anti-patterns

Manual steps between stages ("brought artifact by hand").
"Gray flags" without owner and life span.
One common "fat" integration test instead of contracts.
No reversible database migrations.
Security scan after deploy, not before.

15) Mini CD readiness checklist

• The build is deterministic; artifact signed; there is an SBOM.
• Contract tests and fixes for E2E.
• Security/Compliance gates as code; secrets - via vault.
• Observability: logs/metrics/tracks, release dashboards, SLO gates.
• Release strategy: canary/blue-green + auto-rollback.
• DB migration procedures (expand/contract).
• Feature flags with create → use → delete policy.
• RACI/Runbooks/ChatOps integration.

16) Example flow (scenario)

1. Merge in 'main' trigger line.
2. Container assembly, signature, SBOM.
3. Lint/unit/contracts → passed.

4. SAST/SCA/secret scan → "green."

5. Autopromo in stage: E2E + chaos + profile load.
6. Canary 1% per prod, error/latency/business metrics control.
7. Escalation to 25 %/50 %/100% with green gates.
8. Auto-close the "rollout-guard" flag, record audit artifacts.
9. Post-release review, removing temporary flags.

17) The bottom line

CD is not a "deploy button," but a culture of small, safe and observable changes. With the right policies and automation, CD reduces risk, accelerates value delivery, and makes releases a routine rather than an event. For highly loaded and adjustable systems, the key to success is strict quality gates, phased rollout, feature flags, observability and reproducibility of each step.