DevOps automation guide
Bring automation and continuous feedback to your entire team.
DevOps automation best practices
There’s a paradoxical question in the DevOps community: Is DevOps a set of tools or practices?
The contradiction is that DevOps is both: new tools have sprung up to enable new practices. For instance, continuous delivery tools make it seamless for teams to automate their releases and ensure those releases are both frequent and predictable.
The following reference architecture can help teams introduce automation as part of their software development practices and move toward continuous feedback and iteration.
Automation reference architecture
Workflow
Practice
Action
Plan and track
Code
Control the flow with dev panel
Loop up to Plan and Track
Detect
Package
Deploy
Feedback
Validate deployment frequently
Control the flow with dev panel
Loop up to Plan and Track
About this guide
What worked before won't work in the future for DevOps teams. The fundamental struggle is changing team skills as a whole, rather than just the individual members. It means learning together what it means to do CI/CD and bringing new tools into play that can be used by not just specialists, but everyone on the team.
Working styles need to adapt to include practices like pairing, swarming, and mobbing to create shared knowledge about the code base and tools.
Where you are today
Process Indicators
- Lead time for changes:
Between one week and one month - Deployment frequency:
Between once per week and once per month - Time to restore service:
Less than one day - Change failure rate:
0-15%
Tech
- Tool stack:
Integrated tools - Technology platform:
Platform as a Service (PaaS)
How to make these team changes
Dig into details, from the customer perspective
Beyond the focus on the product owner, this customer-centricity is something the whole team should learn together. If user stories fall flat for your team, it might be that you need to take a step back, or a step toward more detail. Impact mapping, as a team-wide activity, can be a great way to take large business goals and break them down into parts that still hold customer meaning. It helps connect the things in a backlog to an overall target.
Meanwhile, specification by example is a way to get more detailed about the work, without losing customer perspective. Examples express how customers are going to interact with a system, so that we can better test our system. More than just as "yet another artifact", examples should be built collaboratively so that building examples is a way of building common customer empathy.
Recommended resources
Atlassian’s collection of resources for product development
Learn from those who have gone before
Many teams are already operating at the edge of efficiency, making it difficult for them to make big skills leaps while keeping forward momentum to deliver a working product. In this case, teams require an outside influence. To adopt new practices faster, even provisionally, it helps to leverage wisdom and experience of people who have done it before.
This kind of external catalyst can be its own dedicated team, providing help to the teams that need it most. Inside Atlassian, teams like Program Management, QA, and SREs, are stable teams, but they are dedicated to enabling other teams, rather than doing the work for them. We even call our QA “Quality Assistance” instead of “Quality Assurance”, because they are responsible for helping teams learn new testing skills instead of conducting tests themselves.
Whether it’s formal training or consulting relationships, external expertise allows your team to learn in a quick burst.
Go from normal change to standard change
Moving away from what ITIL characterizes as normal change to standard change is critical to DevOps.
Normal changes are non-emergency changes that don’t have a defined, pre-approved process. They’re not standard and repeatable. There are risks involved. But they’re also not emergencies. Which means they can go into the usual change management queue for risk assessment and approval.
For example, upgrading to a new content management system is a normal change.
Standard changes are low-risk, commonly repeated, and pre-approved. They’re performed frequently and follow a documented, approved process.
For example, adding memory or storage is a standard change.
So, what does that mean in practice? It means moving away from common rituals on the left to focus on ways of working on the right.
| Normal Change (using processes) | Standard Change (using continuous delivery) |
| Many human steps to deployment | Single click to deploy |
| Batch for change windows | Single-piece flow (CI & trunk-based development) |
| Assume highly-coupled architecture | Target loosely coupled architecture |
| Tickets and documentation as audit trail | Version control as audit trail |
| Mostly manual testing | Continuous testing |
| Reactive problem detection | Proactive monitoring & observability |
| DBA-gated changes | Integrated database changes |
| Post-hoc security review | Early involvement with security |
Recommended resources
Learn more about CI/CD
Embrace automation
Tools like Ansible help organizations express configuration of infrastructure as code (IaC). Continuing that pattern, the industry embraced IaC in more narrowly-focused tools, like Terraform Cloud or Docker, as the expression of all the system dependencies in a file.
DevOps also improves traditional capabilities, like event logs. Logs are no longer just spit out onto disk for use during troubleshooting. Logs now flow together into aggregation tools that often apply AI/ML to help find new information, before something goes wrong. Increasingly, humble logs form a foundational strategy for managing distributed systems, with more advanced practices like alerting and incidents built on top of that foundation.
The ability to configure infrastructure through automation and the stream of information coming from logs enables new levels of dynamic systems. Cloud providers set expectations for capabilities like auto-provisioning and auto-scaling. Inside applications themselves, feature flags empower teams to switch on and off different code paths or even infrastructure paths.
Recommended resources
Infrastructure as code
Not quite ready for this?
Build the foundation with customer centricity
Automation already part of your team?
Visit our next guide focused on observability and monitoring.