How to Think about DevOps: It's a Journey, not an Either/Or Choice
People tend to describe DevOps, the "agile" approach to software development and delivery, as something an organization either does or does not do. Yet in reality, DevOps is a journey, rather than an either/or proposition.
People tend to describe DevOps, the “agile” approach to software development and delivery, as something an organization either does or does not do. Yet in reality, DevOps is a journey, rather than an either/or proposition. Here’s what that means, and an explanation of how to “do” DevOps.
We’ve explained the meaning of DevOps before, so I won’t rehash it in detail here. Suffice it to say, however, that DevOps is all about reducing barriers between collaboration, making software delivery modular and adding scalability to the development and deployment process. All of these practices make workflows more “agile,” one of the keywords in the DevOps lexicon.
DevOps Stages
What remains less well understood is that there are different stages of DevOps. Organizations don’t jump overnight from an old-fashioned approach to app development to one that is completely DevOps-based. Instead, they tend to progress along a continuum, which looks something like this:
“Waterfall” development. This term refers to traditional, non-agile development processes. When you do waterfall development, you release, test and deploy code according to a staccato rhythm, rather than on a continuous basis. Because of this, your delivery is not at all continuous. Plus, when one part of the development process experiences a delay, it hampers all the other parts.
“Fast waterfall” development. If you optimize your waterfall development process, you move on to the “fast waterfall” stage. There are different ways to do this. It might mean you automate your code testing and use Git for scalable code management, for instance. Those tools provide you with much more agility than a traditional workflow. But there’s still a lot more you can do to become fully agile.
“Really fast” waterfall. Going a step further, you might adopt a Continuous Integration (CI) platform, such as Jenkins or TeamCity, for app development. CI tools automate the process of building software. They give you a very high degree of agility — but there are additional optimizations that you could adopt.
Continuous Delivery. At the end of the DevOps journey comes the stage of Continuous Delivery. This means all of your code development, testing and deployment processes are as automated as possible. It also means you have an agile, scalable system for managing your software in production. In many cases containers are (or will soon be, as adoption of platforms like Docker continues) a key ingredient for reaching this state of full agility.
You could define the DevOps journey in other ways, of course. There are no hard-and-fast rules that delineate the difference between one stage on the DevOps spectrum and another.
Nor is there any single tool that is absolutely necessary to use in order to be considered agile. These things are specific to each organization.
The more important consideration is simply to recognize that doing DevOps and becoming agile is a process, rather than something you either do or don’t do. In addition, it’s important to keep in mind that even if your organization has adopted some DevOps practices already, there is likely more that it can do to increase its agility.
rel
About the Author
You May Also Like