At a basic level, DevOps emphasises collaboration between development and operations. It is built upon a set of practices that automate processes between software development and IT teams, allowing them to build, test and release software and services more quickly and reliably.
DevOps can be a loaded term and is open to misinterpretation. A good way to describe DevOps could be ‘automation through engineering’; sometimes DevOps teams can actually be renamed as Automation or Platform teams.
More than just a set of iterative development cycle best practices that offers greater agility than the traditional waterfall development model, DevOps also looks beyond development. It encompasses all the steps from conception to delivery, in order to deliver continuous value to the business.
Breaking down silos within the business to take a cross-functional approach is core to DevOps, but this cultural change is one of the biggest challenges for a traditional organisation embracing DevOps. The larger the enterprise, the slower the cadence, especially if it’s still set up for waterfall-style development.
In the traditional development model, developers write code and then they pass it down the line to test teams. If that code runs OK on their test box, the testers pass it to production support for deployment. If they deploy that code into production and then discover an issue, it goes back up the line to be triaged and fixed. This is one of the biggest challenges with traditional, operation-centric cultures: teams working in silos that don’t collaborate with each other from the inception phases of the development cycle. This is why DevOps is often illustrated using an infinity loop, which is a really a continuous feedback loop. Understanding how DevOps is put into action requires understanding the concept of a CI/CD pipeline – Continuous Integration and Continuous Delivery.
Advantages
The business advantages of this approach include faster time to market, along with the ability to easily add new features and unlock value quicker than compared to sticking with annual waterfall monolithic releases.
When it comes to practices, DevOps introduces CI/CD to better support the cycle of development, testing and deployment by adding a pipeline of quality gates. Developers check their code into a repository where it undergoes initial testing and peer review. Developers are prone to writing their own tests to suit their own code – automation included testing phases early on in the development cycle can identify a wide range of issues, speeding up the process while catching problems before they make it any further down the pipeline. Making smaller changes, more often, allows for easier rollback and regression testing of existing code.
The rise of cloud infrastructure makes this testing much easier, as every phase of the testing can run like-for-like on an accurate replication of the environment, rather than running on undocumented uniquely-configured development machines.
Traditionally, developers and testers have often relied on a collection of undocumented workarounds in order to get code to run smoothly in different stages of the release cycle. Attempting to replicate changes across those uniquely-configured environments is fraught with risk.
Without standardisation in the testing environments along the pipeline, deployments can stall for days as engineering, testing and production support staff finally start working as a team – scrambling to isolate the root cause and come up with a solution to tactically fix the issue.
Making the most of DevOps requires re-evaluating how your teams function and interact. That’s where cross-functional teams come into play, as DevOps is really the ultimate cross-functional team. Traditional operations are becoming redundant; in big organisations they should be woven into the fabric of the business and it’s better to actually embed a traditional operations person into a DevOps team and basically retool them, because they do bring a lot of context into the conversation.
Traditional mindset
Continuous Integration and Continuous Delivery can unlock a lot of value, but they’ll never reach their full potential if the business is still trapped in the traditional mindset. This can result in agile development cycles of a few weeks delayed by enterprise test teams that can take, in some cases, months to test. If you’ve gone down the DevOps path, but it’s still taking you three months to push through major changes, then you may only be halfway there.
It should be said that few organisations actually achieve the DevOps nirvana of true CI and CD, let alone take the next step of implementing Continuous Deployment. A global software powerhouse, for example, may deploy a thousand times a day. Every time someone makes a code change, it runs all the way through the pipeline and actually gets deployed to production with no one touching it. That’s the dream, but in reality Continuous Deployment is a very rare thing.
In most organisations, once code is ready to be released into production, there is a handover, which is usually managed by user permission controls on the pipelines. You may go through a traditional ITSM (IT Service Management) tool for extra approval workflow, to satisfy all the stakeholders in a traditional organisation.
This is why the primary step to success with DevOps, and the most difficult challenge, is stakeholder engagement and long-term commitment to change. At first glance, the DevOps approach can seem like throwing caution to the wind, but it’s actually reducing risk to the business – and that’s how you sell them on the idea.