What is DevOps?

The DevOps engineer’s handbook

Over the years, there have been countless technological advancements to the tools we use to develop software. The emergence of cloud platforms alone has made infrastructure faster, more reliable, and easier to provision. And yet, high-performing software delivery is not just about the tools, but how we use them.

Rather than technology alone, it’s the practices, processes, and culture changes DevOps introduces that can most positively impact your software delivery. DevOps is a lean, agile development method statistically proven to improve software delivery speed and quality. It’s also the most significant shift to happen to the software development community.

We built the DevOps engineer’s handbook to share our experience in the hope you benefit from the lessons we learned.

Read more guides on software development.

Principles and practices of DevOps

The core aim of DevOps is to remove barriers that get in the way of software delivery. Typical barriers include:

• Manual processes
• Office politics
• Counteractive support workflows

The reason to overcome these barriers is simple: If your product is software, then all processes should work toward delivering that software, not against it.

To achieve this, most organizations need to change their tooling, practices, and philosophies. To adopt DevOps you should focus on these key areas:

• Using automation, through practices like Continuous Integration and Continuous Delivery
• Embracing shorter development sprints and faster feedback loops
• Evolving team culture by bringing development and IT operations together
• Adopting smoother support workflows

You use these ideas across the entirety of what we call the “DevOps lifecycle”. The DevOps lifecycle suggests a start-to-finish process for development that looks like this:

1. Plan
2. Code
3. Build
4. Test
5. Package
6. Release
7. Deploy
8. Operate
9. Monitor
10. Repeat!

Adoption and automation

There’s no single correct way to adopt DevOps because every company is different. For example, you might find your:

• Existing tools aren’t suitable
• Team processes are so deeply entrenched that teams need convincing to change

Both these problems can take time to solve. However, by starting small, you can make gains you can quickly reinvest in improving other areas.

You should start with automation and your work culture, though. Let’s look at what those entail.

Automation

With DevOps, if you can automate it, you should automate it.

The benefits of automation are simple:

• You free people up for more important work
• Results are repeatable and predictable, especially when you remove the potential for human error
• Teams can respond much quicker and flexibly to problems

With the practices of both Continuous Integration (CI) and Continuous Delivery (CD) (usually coupled as ‘CI/CD’) you can automate huge chunks of the DevOps lifecycle.

Continuous Integration

Most developers know how source control works, and are familiar with coding in branches before merging into the main branch. Historically, organizations would only merge code at big intervals, saving updates to merge in batches.

While that technically works, developing in this way:

• Slows down development, releases, and deployments
• Increases the likelihood of a bug holding back other innocent updates

Instead, Continuous Integration means committing, merging, and testing your code many times throughout the day. Doing this means:

• It’s quicker and less disruptive to find problems
• There’s no need for change windows or commit deadlines
• Your results become far more predictable
• You have more confidence when deploying your product

Automation, however, is vital to the efficiency of Continuous Integration. Build servers or CI platforms can help you automate everything between code commits and release management, including:

• Compiling committed code from your repository many times a day
• Running automatic tests to validate and merge code into your main branch
• Creating deployable packages and handing off to a deployment tool, like Octopus Deploy

To look at it another way: Continuous Integration tooling can fully automate the following phases of the DevOps lifecycle:

• Build
• Test
• Package

That’s 3 of the 10 phases of the DevOps lifecycle automated. But you can do even better by adding Continuous Delivery.

Continuous Delivery

Continuous Delivery is a practice that starts with and includes Continuous Integration, but ends with users accessing your software. Continuous Delivery helps you:

• Get deployable artifacts to your environments as quickly and reliably as possible
• Build and constantly improve your deployment pipeline and its processes
• Use automation to free your team to focus on more important work

You achieve this by following Continuous Delivery’s 5 principles:

1. Build quality in
2. Work in small batches
3. Automate everything you can
4. Always improve
5. Everyone’s responsible

Continuous Delivery shares some basic ideas with Continuous Integration. Both ask you to work small, action often, and automate everything you can. Continuous Delivery’s focus, however, is building confidence and efficiency into your software delivery so it benefits everyone - your business, staff, and users alike.

Read more about Continuous Delivery, including:

• What is Continuous Delivery
• Why you should Adopt Continuous Delivery
• Continuous Delivery’s principles
• How to start using Continuous Delivery

Creating an ideal DevOps culture

In traditional organizations, developers and those who support them (such as operations or database teams) are often on separate teams with little interaction.

Each team has its own beliefs, responsibilities, and priorities. While not at odds exactly, those priorities can clash due to what each team believes is best practice.

Embracing DevOps as a culture means removing that friction by introducing shared purpose.

The methods to achieve that can differ and depend how entrenched people are in their ways of working. The aim is to ensure all teams:

• Build trust through clear, honest communication, and feedback
• Collaborate throughout the product’s entire lifecycle
• Have what they need to make quick decisions
• Can take risks without fear of failure or blame
• Are collectively responsible for the product’s success
• Review what worked and what didn’t for the next lifecycle

This is part of what the Westrum Organizational Topology calls a ‘Generative work culture’.

Where to learn more

You can learn more about DevOps right here on Octopus’s DevOps engineer’s handbook.

If you like books, check out our interactive DevOps reading list, though in particular, we recommend the following titles:

• The DevOps Handbook by Gene Kim, Jez Humble, Patrick Debois, and John Willis (2016)
• The Phoenix Project by Gene Kim, Kevin Behr, and George Spafford (2013)
• The Unicorn Project by Gene Kim (2019)

See additional guides on Key software development and delivery topics

Together with our content partners, we have authored in-depth guides on several other topics that can also be useful as you explore the world of software development and delivery.

Help us continuously improve

Please let us know if you have any feedback about this page.

Send feedback