DevOps is Essential

In 2026, DevOps is Table Stakes

Written By

Where to Start?

Getting started with DevOps can be daunting, there are many potential places within an organization which could be tweaked or overhauled to achieve those three capabilities called out in the DORA research. DevOps is a whole-organization mindset that touches all parts of the business, and requires champions at all levels. However, even reluctant teams can get started on the journey towards seeing results by experimenting with some DevOps practices one step at a time.

Build and package on every change

DevOps is fundamentally about cooperation between the development and operations teams (hence the name). Helping to automate any “hand-off” between them is a great first step. Ideally this starts with a conversation. The developers need to understand the steps to take their code and put it into production, and the operations team needs to provide guidance on which parts of that process would be most helpful to automate. At the end of this process, the whole team has a workflow which allows a development team to submit a change to the code, and that change is automatically packaged into a format that the operations team can deploy without manual adjustments.

Automate testing

How do you know if that package is good enough to deploy into a production environment? While some amount of manual testing can provide assurances, the more often deployments are happening, the less realistic manual testing cycles become. Additionally, lower level “unit” testing that runs fast can provide much-needed feedback to developers throughout the cycle of writing code. Lower level testing can require changes to software architecture approach, whereas high level or end-to-end tests can be easier to create in legacy systems, but are slower to run and therefore provide less feedback. Some mixture of testing techniques will slowly move the team towards more frequent deployments with confidence.

Think about deploying

But how do you deploy? Many development teams don’t even think about what it takes to get code that runs in their local environment running on a test or production environment. But code that doesn’t run for customers is work that’s been paid for but not delivered. To get the benefit of your development team’s work, there needs to be a plan. This includes the automated packaging mentioned above, but also includes thinking about database migrations and feature flags, layering the development of features so that they can be delivered without unintended breakages. Putting all of this together, the development and operations teams can coordinate on automating deployments altogether, after the testing is providing enough confidence and the changes are small enough.

The Hard Parts

DevOps is a mindset shift, not just a set of things to do. Bringing development and operations together takes patience, planning, and leadership. It rarely works well when rushed, but requires education and experience to spread throughout the organization.

What does it look like when it goes wrong? What roadblocks might teams run into? In the process of automating everything, workflows necessarily become more rigid, and supporting every configuration could become difficult. Remember that the packaging and deployment is something your teams control, don’t let it control you. Teams need to get into the habit of modifying their automation when new situations are encountered, rather than using manual workarounds.

Some teams will become overeager about automating deployments before the tests are in place to give the requisite confidence. This leads to botched deployments that need to be rolled back (another sign of maturity is a solid rollback procedure). Testing and deployments go hand-in-hand. While there will be ups and downs, a team that isn’t willing to invest in testing will continue running into pain with their deployments.