Close

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.

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


Stopwatch illustration

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%
Platform illustration

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.