Deployment and operations
Software only creates value when it runs for real users. Deployment moves code into production, and operations keep it running reliably and securely.
Environments
Code typically moves through environments: development on programmers' machines, testing or staging, which mirrors production as closely as possible, and production, which real users rely on. Configuration, such as database addresses and API keys, differs between environments and is supplied through environment variables or configuration services, not hard-coded.
Continuous delivery and deployment
A CI/CD pipeline automatically builds, tests, and packages every change. Continuous delivery means every passing change is ready to release at the push of a button; continuous deployment releases it automatically. Automation makes releases frequent, small, and routine instead of rare, risky events.
Packaging and containers
Applications are packaged with their dependencies so they run the same everywhere. Containers, built from a Dockerfile into an image, bundle code, runtime, and libraries. Orchestrators such as Kubernetes run many containers across servers, restarting failed ones and scaling with demand. Platform services, such as Vercel, Heroku, or cloud app services, handle much of this automatically.
Release strategies
Safe release strategies reduce risk. Blue-green deployment runs the new version alongside the old one and switches traffic over at once, allowing instant rollback. Canary releases send a small share of users to the new version first and expand if metrics look healthy. Feature flags turn features on or off without redeploying.
Monitoring and logging
Once live, systems need observation. Monitoring tracks metrics such as response time, error rate, and resource usage, and alerts engineers when thresholds are crossed. Centralised logs record events for investigation, and distributed tracing follows a request across services. You cannot fix what you cannot see.
Reliability and incidents
Teams set targets, such as 99.9% availability, which allows about 43 minutes of downtime in a 30-day month. When incidents happen, the priority is restoring service, often by rolling back, then investigating the root cause. Blameless post-incident reviews focus on improving systems and processes rather than blaming individuals.
Security in operations
Production security includes keeping dependencies patched, scanning for known vulnerabilities, using HTTPS everywhere, storing secrets in dedicated managers, applying least privilege to accounts and services, and keeping backups that are regularly tested by actually restoring them. Security is an ongoing practice, not a one-time task.
Worked example
A web app's pipeline: a developer merges a pull request; CI runs 600 tests in four minutes, builds a container image, and deploys it to staging, where automated smoke tests pass. A canary release sends 5% of production traffic to the new version. Monitoring shows the error rate rising from 0.1% to 2%, so the pipeline rolls back automatically, and the team investigates using logs before trying again.
Key takeaways
Code moves from development through staging to production; configuration comes from environment variables, not code. CI/CD pipelines build, test, and release automatically; continuous delivery keeps changes release-ready, and continuous deployment ships them. Containers and orchestrators such as Kubernetes package and run applications consistently. Blue-green, canary, and feature flags reduce release risk. Monitoring, logs, and tracing make systems observable. Availability targets guide reliability; incidents prioritise restoration and blameless review. Operational security is continuous.
Flashcard
Environment real users rely on
Check your understanding
A new release is shown first to 5% of users while error rates are watched. What is this strategy called?