Continuous integration Study Guide

📖 Core Concepts Continuous Integration (CI) – Frequently merging developers’ code changes into a shared branch and automatically building & testing to keep the codebase in a workable state. Continuous Delivery (CD) – The integrated code is always in a deploy‑ready state; deployment to production is a manual decision. Continuous Deployment – Extends CD by automatically releasing every change that passes the CI pipeline to production. CI/CD Pipeline – Sequence of automated steps (build, test, quality checks, deployment) that runs on each commit. Single‑Command Build – A CI‑compliant build can be triggered with one command, producing compiled binaries, docs, and distribution packages. Feature Toggle – Runtime switch that disables incomplete features so they can be merged safely. 📌 Must Remember Atomic Commits: All of a developer’s changes must be recorded as a single, indivisible commit. Frequent Commits: Merge to the integration branch at least once per day (ideally multiple times) to avoid “merge hell.” Build After Every Commit: Guarantees rapid feedback; a failing build points to the most recent change. Run All Unit Tests Locally before committing. Add a Regression Test for every bug fix. Visibility: Build status must be visible to the whole team (green/red badge, change culprit). Keep Builds Fast – Long build queues erode CI’s feedback value. 🔄 Key Processes Developer Workflow Pull latest integration branch → create feature branch → develop → run local unit tests → commit (atomic) → push → CI server builds & runs automated tests. Automated Build Triggered by commit → compile → link → package artifacts (e.g., .deb, .rpm, installer) → generate docs & metrics → publish results. Testing Pipeline Static analysis → unit tests → integration tests → performance tests → code‑coverage report. Release Pipeline (CD) Successful build → staging deployment (production‑like environment) → automated acceptance tests → (optional manual approval) → production deployment. 🔍 Key Comparisons CI vs. CD vs. Continuous Deployment CI: verify every change (build + test). CD: prepare every change for release; deployment still manual. Continuous Deployment: automatically release every passing change. Feature Toggle vs. Incomplete Branch Toggle: merge incomplete work, disabled at runtime. Incomplete branch: keep work isolated → risk of merge hell. Single‑Repository Pipeline vs. Multi‑Team Pipelines Small team: one repo + one pipeline → simplicity. Large org: multiple repos/pipelines per service/team → isolation & scalability. ⚠️ Common Misunderstandings “CI means only building.” – CI also includes automated testing, static analysis, and quality metrics. “Frequent commits are optional.” – Infrequent merges re‑introduce integration chaos and larger merge conflicts. “If tests pass locally, CI will always pass.” – CI runs in a clean environment; missing dependencies or environment differences can cause failures. “Feature toggles eliminate all testing.” – Toggled code still needs unit tests; otherwise hidden bugs may surface later. 🧠 Mental Models / Intuition “Rapid Feedback Loop” – Treat each commit like a small experiment; the faster you see results, the quicker you can correct. “One Change = One Failure” – When builds are frequent, a failing build points almost always to the last commit, simplifying root‑cause analysis. “Build as a Safety Net” – Think of the CI server as a gatekeeper that only lets well‑tested code pass through to later stages. 🚩 Exceptions & Edge Cases Heavy Integration Tests – May be run in a separate nightly pipeline to keep daily builds fast. External Service Dependencies – Use service virtualization when real APIs are unavailable or costly. High Build Queue – If latency spikes, temporarily limit parallel builds or prioritize critical branches. Low‑Quality Test Suite – CI feedback is only as good as the tests; poor coverage yields false confidence. 📍 When to Use Which Choose CI vs. CD vs. Continuous Deployment Start with CI for any project. Add Continuous Delivery when you need a reliably deployable artifact on demand. Move to Continuous Deployment only when you have high test confidence and can tolerate automatic releases. Single vs. Multi‑Stage Pipelines Use single‑stage for small, monolithic apps. Use multi‑stage (build → test → stage → production) for microservices or regulated environments. Feature Toggle vs. Branch Isolation Use toggles for short‑lived incomplete features. Keep long‑running work on separate branches to avoid toggling complexity. 👀 Patterns to Recognize “Build → Test → Deploy” sequence repeated on every commit. Failing build → blame the most recent commit (look for the change that introduced the failure). Metrics spikes (e.g., code coverage drop) coincide with new feature merges – indicates missing tests. Long build times often correlate with large monolithic builds; consider modularization. 🗂️ Exam Traps Distractor: “CI only requires building the code.” – Wrong; CI also mandates automated testing and quality checks. Distractor: “Feature toggles eliminate the need for unit tests.” – Wrong; toggles hide functionality but do not replace tests. Distractor: “Atomic commits are optional if using a modern VCS.” – Wrong; atomic commits are required to keep change granularity clear. Distractor: “Continuous Deployment can be used without any manual approval.” – Correct only if the test suite is comprehensive; many organizations still require a manual gate. Distractor: “A single repository is always best for CI.” – Wrong for large organizations; multiple pipelines improve scalability.