What We Built Together: A Practical Understanding of CI/CD

It started with a simple question: how do you get changes to your application, database, and infrastructure to the place where people actually use them, without breaking their experience?

That question is harder than it sounds. Every team I've worked with has felt the tension between shipping fast and shipping safely. Some teams solve it with elaborate ceremonies. Others solve it with scripts that only one person understands. Neither approach scales, and both create anxiety around every deployment.

This post walks through the foundation we built together in the book. It's not a summary of chapters. It's a map of how the pieces fit when you stop treating CI/CD as a tool and start treating it as a capability.

Start With Deployment, Not Pipeline

Before you can automate anything, you need to understand what deployment actually means. Deployment is the act of placing a new version of something into an environment where users can reach it. That sounds obvious, but the implications are not.

If you deploy a bad version of an application, you can replace it entirely. If you deploy a bad database migration, the data is still there, and rolling back is more complex. If you deploy infrastructure changes that break networking, nothing else works.

These three things—applications, databases, and infrastructure—cannot be treated the same way. Each has its own deployment strategy. Applications work well with blue-green deployment, where you switch traffic between two identical environments. Databases need gradual migration, where changes are applied in small, reversible steps. Infrastructure benefits from an immutable approach, where you replace entire environments instead of patching them.

The diagram below shows the three parallel tracks and their recommended strategies:

flowchart TD subgraph Application A1[New Version] --> A2[Blue-Green Deploy] A2 --> A3[Switch Traffic] A3 --> A4[Rollback if needed] end subgraph Database D1[Change] --> D2[Gradual Migration] D2 --> D3[Small Reversible Steps] D3 --> D4[Rollback Scripts] end subgraph Infrastructure I1[Config Change] --> I2[Immutable Replace] I2 --> I3[Replace Entire Environment] I3 --> I4[No Patching] end A1 -.->|different strategies| D1 D1 -.->|different strategies| I1

The point is not to memorize these strategies. The point is to recognize that deployment is not a single action. It is a set of decisions about how to move changes safely, and those decisions depend on what you are moving.

Pipeline as a Contract, Not a Script

Once you understand deployment, you can build a pipeline. But a pipeline is not a script that runs commands. A pipeline is a contract that every change must pass through the same checks, in the same order, in a consistent environment, before it reaches production.

This distinction matters because teams often treat pipelines as automation for their existing manual process. If the manual process has gaps, the pipeline will automate those gaps too. A good pipeline starts from the question: what must be true about a change before it reaches users?

For application changes, the answer might include passing unit tests, integration tests, and security scans. For database changes, it might include verifying that migrations are reversible and that rollback scripts exist. For infrastructure changes, it might include running validation against a live staging environment.

Building a pipeline for all three types of changes simultaneously is the real challenge. Most teams start with one and add the others later. That is fine, as long as you know which one you are missing and why.

Deploy Is Not Release

One of the most useful distinctions in the book is the separation between deploy and release.

Deploy is putting a new version on the server. Release is making that version actually used by users. When you separate these two actions, you gain control over risk. You can deploy a version, test it in production with internal users, and only release it to everyone when you are confident.

This separation is what enables strategies like feature flags, canary releases, and progressive delivery. Feature flags let you turn functionality on and off without redeploying. Canary releases send a small percentage of traffic to the new version first. Progressive delivery increases that percentage gradually as you observe metrics.

None of these strategies require a specific tool. They require a mindset that treats deployment and release as separate decisions, each with its own risk profile.

Platform Engineering as an Accelerator

When you have multiple teams shipping changes through pipelines, you start to see patterns. Every team needs the same basic things: a way to build, test, and deploy their changes; consistent environments to run those tests; and self-service access to infrastructure.

Platform engineering is the practice of building these capabilities as internal products. A platform is not a big project that must be finished before anyone uses it. A platform starts from a real need that a team has, solves it well, and then expands as more needs emerge.

The key insight here is that platform engineering is not about building the perfect abstraction. It is about reducing the cognitive load on teams so they can focus on delivering value. If a team spends two days setting up a pipeline, the platform is not working. If they can spin up a new service with a single pull request, the platform is working.

Governance as Guardrails, Not Gates

Governance is often misunderstood as a layer that slows things down. In practice, governance in CI/CD is about setting boundaries that let teams move fast without breaking things.

Review policies for production changes, automated audit trails, and risk-based deployment rules all serve the same purpose: they create a clear path for changes to follow, so teams do not have to guess what is allowed or wait for manual approval every time.

The difference between governance as a gate and governance as a guardrail is subtle but important. A gate blocks changes until someone approves them. A guardrail defines the safe path and lets teams move freely within it. The first creates bottlenecks. The second creates autonomy.

A Practical Checklist

If you are building CI/CD capability in your organization, here is a short checklist to guide your decisions:

  • Can you deploy a change to production without manual steps?
  • Can you roll back a deployment in under five minutes?
  • Do you know the difference between your deploy strategy and your release strategy?
  • Does every change pass the same checks, regardless of who made it?
  • Can a new team member deploy their first change on day one without asking for permissions?
  • Do you have a way to test database migrations before they reach production?
  • Is your infrastructure treated as code, not as a snowflake server?

If you answered no to any of these, you know where to focus next.

CI/CD Is a Capability You Maintain

The most important lesson from this journey is that CI/CD is not a project you finish. It is a capability you maintain. Tools change. Teams grow. Requirements shift. The practices that work today may not work next year.

What stays constant is the understanding that shipping changes safely is a skill, not a script. It is built from small decisions made every day: how you structure your tests, how you handle failures, how you balance speed and safety. These decisions compound over time, and they determine whether your team ships with confidence or with fear.

Start with one change. Make it safe. Then make it repeatable. Then make it fast. The rest will follow.