How software actually gets built, tested, and shipped automatically, from continuous integration pipelines to infrastructure as code.
A monorepo keeps many projects or services in a single version-controlled repository, making cross-project changes and dependency consistency easier at the cost of needing CI/CD tooling that scales to a large, shared codebase; a polyrepo keeps each project independent, which simplifies per-project tooling and ownership but pushes the cost of coordinating changes across repositories onto the teams that have to do it manually.
Secrets leak from CI/CD pipelines through a small number of recurring patterns — hardcoded credentials in source control, secrets printed to build logs, and overly broad pipeline permissions — and the core defenses are keeping secrets out of version control entirely, using a dedicated secrets manager, preferring short-lived over long-lived credentials, and applying least privilege to what a pipeline is actually allowed to access.
An immutable build artifact is built exactly once, then promoted unchanged through every subsequent environment — test, staging, production — rather than being rebuilt separately for each one; this guarantees that what was actually tested is byte-for-byte identical to what ships, closing off an entire category of 'it worked in staging' failures caused by environments quietly building slightly different things.
Smaller Docker images start faster, transfer faster, and have a smaller attack surface; multi-stage builds and minimal base images are the two techniques that do the most to shrink them, while understanding how image layers and caching actually work is what makes builds fast to iterate on, not just fast to run.
A feature flag is a conditional check that determines, at runtime, whether a piece of code is active — which lets a team deploy new code to production while keeping it dark, then turn it on separately, for specific users or gradually, without a further code deployment; that separation of deployment from release is the core idea, and it comes with real ongoing cost in flag cleanup and testing complexity.
GitOps is a specific operational pattern built on top of infrastructure as code: a Git repository is treated as the single source of truth for desired system state, and an automated agent continuously reconciles the live system to match it — which means every change is inherently version-controlled, reviewable, and auditable, and manual out-of-band changes get automatically corrected rather than silently tolerated.
Blue-green deployment cuts traffic from the old version to the new one all at once between two full environments, giving an instant rollback; canary releases shift traffic to the new version gradually, in small increments, trading a slower rollout for earlier, smaller-blast-radius detection of problems.
Infrastructure as code means defining servers, networks, and other resources in versioned configuration files rather than provisioning them by hand; declarative tools like Terraform compare that configuration against current real-world state and compute a plan of changes before applying anything.
CI/CD bundles three related but distinct practices: continuous integration (frequently merging and automatically testing code), continuous delivery (keeping every change deployable, with a manual release gate), and continuous deployment (removing that gate entirely) — and conflating them leads to real confusion about what a pipeline actually guarantees.