Tech VocabularyThe deployment pipelineWhat is pipeline?A sequence of automated steps (install, lint, test, build, deploy) that code passes through before reaching production. is the automated assembly line that moves code safely from a developer's laptop to production servers where customers use it.
CI/CDWhat is ci/cd?Continuous Integration and Continuous Deployment - automated pipelines that test your code on every push and deploy it when tests pass. explained simply
CI/CD stands for Continuous Integration / Continuous Deployment. It's the automation that takes code from development to production.
Continuous Integration (CI): Check everything automatically
Every time a developer pushes code, CI runs checks automatically:
- Does the code compile?
- Do all the tests pass?
- Is the code formatted correctly?
- Are there security vulnerabilities?
CI is a tireless quality inspector, it catches problems immediately, before they affect customers.
Continuous Deployment (CD): Ship it automatically
When code passes all CI checks, CD automatically deploys it to production. Some teams prefer "continuous delivery" instead, where code is prepared for deployment but a human clicks the final "go" button, giving control over timing (e.g., avoiding Friday afternoons).
Build, test, deploy stages
Stage 1: Build
The build stage transforms source code into something that can run:
- Compiling TypeScript to JavaScript
- Bundling files together
- Optimizing images
- Minifying code (removing whitespace to make files smaller)
If the build fails, the pipelineWhat is pipeline?A sequence of automated steps (install, lint, test, build, deploy) that code passes through before reaching production. stops immediately.
Stage 2: Test
Automated tests verify the code works correctly:
- Unit tests: Test individual functions ("Does this calculator add correctly?")
- Integration tests: Test how components work together ("Does the cart update when I add an item?")
- End-to-end (E2E) tests: Test complete user flows ("Can a user complete a purchase?")
Stage 3: Deploy
If the code builds and passes all tests, the pipeline copies the built application to servers where customers can access it.
Automated testing: The safety net
Without automated tests, every code change is risky, you might fix one bug and create three new ones. With good test coverage, you can refactor, add features, and fix bugs with confidence.
- No tests: "I hope this works" (deploying is scary)
- Some tests: "This probably works" (deploying is nervy)
- Good test coverage: "I know this works" (deploying is routine)
Types of tests in the pipelineWhat is pipeline?A sequence of automated steps (install, lint, test, build, deploy) that code passes through before reaching production.
| Test type | What it tests | Speed | When it runs |
|---|---|---|---|
| Unit | Individual functions | Fast (milliseconds) | On every commit |
| Integration | Component interactions | Medium (seconds) | On every commit |
| E2E | Complete user flows | Slow (minutes) | Before deployment |
| Visual regression | UI appearance | Medium | Before deployment |
Staging vs production
Development environment
Each developer's local laptop environment, where they write and initially test code.
Staging environment
A complete copy of production that customers can't access. Code sometimes works on a developer's laptop but fails in production due to different configurations or database differences. Staging catches these issues first.
Production environment
The servers serving your actual customers. Changes here affect real users and real revenue. Deployments to production typically have extra safeguards:
- Approval gates (someone must manually approve)
- Deployment windows (only during business hours)
- Feature flags (new features can be turned off instantly)
| Environment | Purpose | Who uses it | Stability |
|---|---|---|---|
| Development | Writing and initial testing | Developers | Can be broken |
| Staging | Final verification before release | Team, QA, product | Should work |
| Production | Live customers | Everyone | Must work |
Deployment strategies
Even with testing, deployments can go wrong. These strategies reduce the risk:
Blue-green deploymentWhat is blue-green deployment?A zero-downtime deployment strategy where a new environment runs alongside the old one, and traffic is switched over only when the new version is verified.
Two identical production environments: "blue" (current) and "green" (new). When green is ready, you switch all traffic instantly. If something breaks, switch back to blue just as fast. Best for zero-downtime deployments.
Canary deploymentWhat is canary deployment?Sending a small percentage of real user traffic to a new version of your app while monitoring for errors before rolling it out to everyone.
Deploy the new version to a small percentage of users first (say 5%). Monitor for errors. Gradually increase to 25%, 50%, 100%. If problems appear, roll back for everyone. Best for catching issues that only appear under real load.
Rolling deploymentWhat is rolling deployment?A deployment strategy that updates servers one at a time while others keep serving traffic, ensuring continuous availability.
Update servers one at a time. While server 1 updates, servers 2 and 3 handle traffic. Best for gradual updates without duplicate infrastructure.
| Strategy | How it works | Risk level | Infrastructure cost |
|---|---|---|---|
| Blue-green | Two environments, instant switch | Low (instant rollback) | High (2x capacity) |
| Canary | Gradual user percentage increase | Low (limited blast radius) | Medium |
| Rolling | One server at a time | Medium | Low |
| Big bang | Update everything at once | High | Low |