The idea of automating company operations is becoming increasingly favoured as a way of speeding up tasks and enabling round-the-clock delivery. The six Cs of DevOps are no exception. This article explores how organisations can go about effectively automating each of these continuous and collaborative DevOps principles.
What Are the Six Cs of DevOps?
The six Cs provide a structured framework for understanding the continuous and collaborative nature of modern software delivery. They are:
- Continuous Business Planning – Aligning engineering cycles with evolving business objectives.
- Collaborative Development – Breaking down silos between development, operations, and other business units.
- Continuous Testing – Embedding automated tests throughout the delivery pipeline.
- Continuous Release and Deployment – Shipping code reliably and frequently using automated pipelines.
- Continuous Monitoring – Observing application and infrastructure behaviour in production at all times.
- Collaborative Customer Feedback and Optimisation – Feeding real user data back into the planning and development cycle.
“The six Cs are just a way of explaining to a business audience what a software engineer does naturally as part of his or her innate problem-solving process. This involves taking a deep dive into the problem that needs to be solved and working to continuously deliver and iterate solutions.”
— Ashley Coker, CEO, Slate
1. Start With Release and Deployment Automation
If you are deciding where to begin your automation journey, release and deployment is the most impactful starting point. It underpins many of the other Cs and delivers immediate, measurable returns.
“You should start with release and deployment not only because it underpins many of the other capabilities, but because it has the most dramatic impact upon your ability to resolve issues in production and overall agility. Patching security vulnerabilities, shipping new features, implementing disaster recovery and the provisioning of test environments are all sped up by automated release and deployment processes, and this ability to respond quickly is invaluable for all sorts of situations.”
— Nigel Kersten, Field CTO, Puppet
Automating your release pipeline removes manual handoffs, reduces human error, and creates a repeatable, auditable process for getting code from a developer’s commit into production.
2. Build Continuous Testing in Parallel With Deployment Automation
A common mistake organisations make is waiting until they have comprehensive test coverage before they start automating their test pipeline. Kersten recommends a different approach:
“The best approach is to create a ‘walking skeleton’ testing process. Start by building a CI pipeline that simply takes a commit and deploys it into an environment without any additional tests or gates. From there you can add tests — lint, unit, acceptance, integration, monitoring — when it makes sense for your teams.”
— Nigel Kersten, Field CTO, Puppet
This iterative approach allows teams to gain immediate value from automation while incrementally improving quality gates, rather than delaying all progress until a theoretically perfect test suite exists.
Canary and A/B Deployments as Automated Tests
Jon Hammant, Head of DevOps & Full Stack Engineering at Accenture UKI, highlights the value of progressive delivery techniques as part of the testing strategy:
“When it comes to release and development, flow should be automated all the way down to production, with deployment to a subset of users — known as canary deployment — and analysing automated metrics, a recommended way to test the success of a project. From there, A/B deployment should be practised, and once code is refined, it can be rolled out at scale.”
— Jon Hammant, Head of DevOps & Full Stack Engineering, Accenture UKI
3. Automate Testing Across Multiple Pipeline Stages
Testing should not be limited to a single phase of the pipeline. Hammant argues that every deliverable should have an associated test:
“Everything that’s developed should be testable, as without a test case, something becomes immeasurable. Testing should also be automated amongst multiple stages, including check-in, unit, integration and acceptance.”
— Jon Hammant, Accenture UKI
Automated feedback from production should also flow into continuous monitoring. When issues are detected, self-healing processes should be triggered automatically, with notifications routed to engineering teams via tools such as Slack or ChatOps integrations. This keeps developers focused on building new features rather than manually triaging production incidents.
4. Identify and Remove Process Barriers Before Automating
Automation amplifies whatever process it is applied to—good or bad. Automating a broken or redundant workflow simply produces broken results faster. Ashley Coker explains:
“Automation only makes DevOps more efficient if the existing business processes and development cycle have been thoroughly analysed to root out any issues, otherwise you’ll simply end up automating bad or redundant processes. Before automating DevOps, we go through a diagnosis and prognosis stage to identify any cultural or legacy challenges that are inhibiting agility.”
— Ashley Coker, CEO, Slate
Practical steps to address barriers before automating include:
- Mapping existing workflows to identify bottlenecks and redundancies.
- Involving both engineering and business stakeholders in the discovery process.
- Addressing cultural resistance by demonstrating early wins from targeted automation.
- Upskilling in-house teams so they can maintain and evolve automated pipelines independently.
5. Establish a Performance Baseline Before Automating Monitoring
Continuous monitoring is only useful if teams know what “normal” looks like. Tori Wieldt, Senior Solutions Manager at New Relic, makes an important point:
“Whether continuous or not, you should start with ‘what is the normal performance for our applications?’ Surprisingly, not many companies can answer this, but can by easily monitoring the behaviour of their apps and infrastructure. Once that practice is set up, teams can begin to automate the process. Rolling instrumentation into standard build process makes visibility the default, instead of being viewed as yet another burden on developers.”
— Tori Wieldt, Senior Solutions Manager, New Relic
Modern build tools provide the hooks needed to instrument code as part of the standard build process, meaning observability can be baked in from the start rather than retrofitted later.
6. Make Observability a Prerequisite for Automation
Underpinning all six Cs is the concept of observability—the ability to understand what is happening inside your systems from the outside. Paul Dix, CTO of InfluxData, puts it directly:
“In order to be confident in your continuous delivery system, you need to have everything highly instrumented and you need to have continuous monitoring in place. To automate almost anything, you need to have tools in place to observe what is happening and then be able to act on it. Observability is a necessary prerequisite to making anything automatable and continuous.”
— Paul Dix, CTO, InfluxData
Without metrics, logs, and traces flowing from your systems, automated processes have no signal to act on. Instrumentation is therefore not an optional extra—it is foundational infrastructure for any automated DevOps practice.
Key Takeaways
- Start with release and deployment automation — it delivers the broadest impact and enables all the other Cs.
- Build continuous testing incrementally — use a walking skeleton CI pipeline and add gates progressively.
- Use canary and A/B deployments as production-stage automated tests before full rollout.
- Audit your processes before automating — automation of bad processes produces bad results faster.
- Establish performance baselines before attempting to automate monitoring and alerting.
- Treat observability as foundational — without instrumentation, nothing is truly automatable.
Automating the six Cs of DevOps is not a single project with an end date—it is an ongoing engineering discipline. Teams that address cultural and process barriers first, build automation incrementally, and invest in observability will see compounding returns across delivery speed, system reliability, and developer experience.