Continuous delivery Study Guide

📖 Core Concepts Continuous Delivery (CD) – Produce software in short cycles; the code is always in a releasable state and can be shipped at any moment. Continuous Deployment – Extends CD by fully automating the final deployment step; no manual approval is needed. Deployment Pipeline – An automated, repeatable flow that builds, tests, and prepares code for release, providing visibility, feedback, and continual deployment. Feature Toggles – Runtime switches that let unfinished features be merged safely while staying hidden from users. Architecturally Significant Requirements – Non‑functional qualities (deployability, modifiability, testability) that the architecture must support to enable CD. Zero‑Downtime Deployment – Deploying a new version without interrupting service availability (e.g., blue‑green, canary). 📌 Must Remember CD guarantees that any committed version can be released; continuous deployment removes the manual release gate. Core pipeline purposes: Visibility (everyone sees build/test status), Feedback (problems surface immediately), Automation (any version can be pushed to any environment). Feature toggles = commit early, release later. Microservices → boost deployability & modifiability; ideal for CD. Key benefits – faster time‑to‑market, higher quality, lower risk, reliable releases. 🔄 Key Processes Commit → Build Server Code change pushed → build server compiles & packages. Automated Tests (unit → integration → non‑functional) run in pipeline; failures stop the flow. Feedback Loop – Test results instantly reported to developers. Deployment Automation – Successful builds are automatically promoted to staging, then (for CD) held for manual approval or (for continuous deployment) auto‑released to production. Feature Toggle Evaluation – Toggle state determines if a feature is exposed to users after deployment. 🔍 Key Comparisons Continuous Delivery vs. Continuous Deployment CD: final production release requires manual approval. CDep: production release is fully automated. Feature Toggles vs. Long‑Living Branches Toggles: merge early, hide at runtime. Branches: keep code separate until ready, risk integration drift. Microservices vs. Monolith for CD Microservices: independent deployability, easier rollback, better modifiability. Monolith: larger deploy units, higher risk of breaking unrelated parts. ⚠️ Common Misunderstandings “CD means no testing.” – CD relies on extensive automated testing; lack of test automation is a major obstacle. “Automation eliminates all human work.” – Manual approval (in CD) or decisions about toggles still require human judgment. “Zero‑downtime = no deployment.” – Zero‑downtime is a deployment strategy (e.g., blue‑green), not the absence of deployment. 🧠 Mental Models / Intuition “Pain Forward” = detect problems early – Imagine the pipeline as a conveyor belt; the earlier a defect is caught, the cheaper it is to fix. “Lean Validation (Poka‑Yoke)” – Think of the pipeline as a safety guard that prevents bad code from moving forward, just like a mistake‑proofing device on a factory line. “Toggle as a Light Switch” – Code is always present; the toggle decides whether the light (feature) is on for users. 🚩 Exceptions & Edge Cases Legacy Systems – May not support full automation; adopt incremental modernization and hybrid pipelines. Environment Differences – When dev/test/prod differ, containerization or infrastructure‑as‑code mitigates slip‑through bugs. Large Organizations – Single pipeline may become a bottleneck; adopt per‑team or per‑service pipelines while maintaining cross‑team visibility. 📍 When to Use Which Feature Toggle vs. Separate Branch → Use toggles for small, incremental changes that need early integration; use branches for large, disruptive rewrites. Microservices Architecture → Choose when you need high deployability/modifiability and can afford the operational overhead. Single vs. Multiple Pipelines → Small team → single repo/pipeline; large org → separate pipelines per service/team to reduce queue times. Zero‑Downtime Techniques → Blue‑green for full version swaps; canary for gradual traffic shift; choose based on risk tolerance and traffic pattern. 👀 Patterns to Recognize Rapid Feedback Loop – Tests fail immediately after a commit → indicates proper pipeline feedback. Toggle‑Driven Release – New UI appears only after toggle flip, not after new deployment. Incremental Deployability – Each pipeline stage produces an artifact that can be independently deployed to any environment. 🗂️ Exam Traps Confusing CD with Continuous Deployment – Remember the manual approval gate differentiates them. Assuming “Automation = No Manual Work” – Questions may imply that manual testing is still required; focus on the need for automated verification, not the absence of human decisions. Over‑generalizing “Microservices always better” – Exams may present scenarios where monoliths are preferable (e.g., low team count, tight latency). “Feature Toggles eliminate need for testing” – Toggles hide features but still require tests for both enabled/disabled states. --- Use this guide for a quick, confidence‑boosting review before your exam – each bullet is a high‑yield fact you can recall in seconds.