Stop the Release Craze: Why DevOps Teams Must Automate CI/CD Now

The pace of software releases is accelerating at a rate that manual processes simply cannot sustain. According to Cloud Native Computing Foundation (CNCF) survey data cited by Copado’s Andrew Davis, the share of companies releasing software daily or weekly grew from 35% to 65% over a two-year period, while the share with daily release cycles nearly doubled from 15% to 27%.

Those numbers signal a fundamental shift in how engineering organizations must operate. Skilled developers alone are no longer enough — the delivery pipeline itself has to carry much of the load.

The Six-Step Foundation of Every DevOps Pipeline

Andrew Davis, author of Mastering Salesforce DevOps and a practitioner at Copado, outlined at Dreamforce 19 that software deployments typically follow six steps, regardless of the platform or team size:

1. Understand what users need.
2. Build it.
3. Verify it works as intended.
4. Verify it integrates correctly with the rest of the system.
5. Confirm it does not break anything else.
6. Deploy it to users.

Although Davis presented in the context of Salesforce teams, the framework maps directly onto any software delivery organisation. The first two steps are where developers feel most productive — deep in the problem, with the full solution in working memory. Steps three through six, however, are where most teams stumble.

The Working-Memory Problem

Davis identifies a cognitive reality that every developer recognises: the state of flow. When you are deep in a feature, you hold the entire mental model of the system in your head. You can trace every dependency and reason about every edge case. That clarity is both the joy and the fragility of software development.

The problem appears when that context dissolves. A new project starts, a support ticket arrives, a sprint ends. Days or weeks later a defect surfaces — but the developer who introduced it has already moved on mentally. Reconstructing the original context takes significant time, and in a high-velocity release environment, three weeks of rework for a single regression can cascade into missed commitments across multiple teams.

Multiply one such incident by hundreds or thousands of concurrent change requests inside a large organisation, and the compounding risk becomes plain.

DevOps as a Three-Phase System

Davis simplifies the DevOps value chain into three phases:

• Development — Creating new features and capabilities.
• Innovation Delivery — The automated pipeline that moves code from development into production safely and repeatedly.
• Operations — Running and maintaining what is already in production.

The middle phase — innovation delivery — is the one that breaks down most often when left to manual processes. Automating it is the core purpose of a continuous integration and continuous delivery (CI/CD) strategy.

What an Effective CI/CD Strategy Looks Like in Practice

Based on Davis’s recommendations, a mature automated pipeline should meet three concrete criteria:

1. Trunk-based development at team scale. Every developer and team merges into a shared codebase — often called the trunk or main branch — at least once per day. Long-lived feature branches are a primary source of integration pain; short-lived branches merged frequently eliminate that class of problem.
2. Automated testing on every commit. The moment the codebase changes, an automated test suite runs. Human review is reserved for interpretation and escalation, not for catching regressions that a computer can find in seconds.
3. A ten-minute fix target for test failures. When a test fails or something breaks, the team resolves it within ten minutes. This constraint is not arbitrary — it keeps the broken state in working memory and prevents accumulation of unresolved failures that obscure the health of the codebase.

The speed of the feedback loop is critical. Davis argues that automated tests must return results to developers in under five minutes — ideally while the developer is still mentally engaged with the change. Tests that take hours to run are nearly as useless as no tests at all, because by the time results arrive the cognitive context is gone.

Configuration Drift: The Silent Threat to Continuous Delivery

Automating the build and test phases is necessary but not sufficient. Davis also highlights configuration drift as a chronic threat to continuous delivery — one that many teams underestimate until it causes a production incident.

Configuration drift occurs when environments diverge over time. Common causes include:

• Production-only hotfixes that are never back-ported to development or staging environments.
• Long-lived sandboxes that accumulate experimental changes, legacy data, and ad-hoc configurations that bear little resemblance to production.
• Manual environment changes made by multiple operators over months or years, with no automated record of what changed or why.

The result is an environment mismatch: code that passes every test in staging fails or behaves unpredictably in production because the two environments are not actually equivalent. The fix is to treat infrastructure and environment configuration as code — version-controlled, tested, and deployed through the same automated pipeline as application code.

Accelerating Development Requires Both Mindset and Tooling

Davis’s central argument — that accelerating delivery cycles requires “a combination of thinking and good tools” — resists reduction to a tool-selection problem. Purchasing a CI/CD platform without changing branching strategies, testing culture, or ownership models will not produce the outcomes organisations expect.

Conversely, the right mindset without automation at scale is equally insufficient. At the volume of change requests that modern engineering organisations handle, human coordination cannot substitute for a reliable, fast, automated pipeline.

The practical starting point for most teams is modest and sequential:

1. Establish a single shared branch and enforce daily integration.
2. Instrument automated unit and integration tests that run on every commit.
3. Measure and actively reduce the time from commit to test feedback.
4. Bring environment configuration under version control and automate provisioning.
5. Treat every manual step in the delivery pipeline as a candidate for automation.

None of these steps are novel, but their consistent execution at scale is what separates teams that ship reliably from teams that are perpetually firefighting.

Key Takeaways

• Release frequency is increasing industry-wide; manual delivery processes cannot keep pace.
• Developer working memory is finite — fast automated feedback loops preserve the context needed to fix defects quickly.
• An effective CI/CD pipeline requires daily trunk integration, automated testing on every commit, and rapid resolution of failures.
• Configuration drift between environments is a structural risk that only infrastructure-as-code practices reliably address.
• Tooling and organisational mindset must change together for CI/CD adoption to deliver measurable results.