A model-driven approach is the best way to scale DevOps
Source – techtarget.com
Modern software requires deployments that run consistently and correctly across different environments. As the software release process matures within an organization, a model-driven approach helps enable automation for complex deployment scenarios, increase release velocity and improve software quality.
Deployment milestones of maturity
The first milestone of maturity in this process is reached when manual processes no longer work. As deployment demands grow, there are almost always mounting impediments — lack of speed, consistency and visibility, to name a few. Driven by novel-length run books that need to be executed perfectly by imperfect people, this approach is not sustainable in today’s application release landscape.
The next milestone is scripting, which often correlates with automation. If you rely too much on scripts, though, it’s likely you’ve stretched them beyond what is practically useful. Scripts, while quick and easy, are brittle. They provide no visibility and were likely written by people no longer with the company. The pain eventually starts to outweigh the value. Despite the disadvantages, many organizations tend to take this approach, simply because scripting is free.
The next milestone is to model the different components of your release process to form an overall methodology. If a team needs to change the technology or environment, all they have to do is pull out that piece and insert another one. This method provides reliability, visibility and usability.
Any organization with these benefits is likely to outperform its competition. Companies that find themselves stuck in manual and error-prone script-driven releases should consider a model-driven approach.
Shift to a model-driven approach
It’s easy to get overwhelmed, so focus on simply getting one piece in place. Automate a common deployment process, for instance. Then, teams can iterate on that piece until they have an orchestrated, modeled portion of the process. Start small and secure quick wins. This creates excitement and momentum within the organization.
What (and how) to model
When it’s time to decide what to model, the organization will need to define the what, where and how.
The what can be a variety of things. What is the organization trying to deploy? What is it trying to release? It could include an application or set of applications, and all the components, code, artifacts and packages that go with the deployment of that application, along with the dependencies.
The where refers to where the organization is trying to deploy it and what it means to deploy to dev, QA, operations or even to hybrid environments.
Once you’ve defined the what and where, determine how those will be pushed up. Will it be a single application to an environment, multiple applications with dependencies to an environment or set of environments? The how also accounts for things like compliance.
Application release orchestration platforms, as a byproduct of being able to model this out and to run visualizations, provide the who and the when — i.e., who ran what at what time.
How to get started
A model-driven approach to application-release orchestration accelerates releases and maximizes the benefits, but it can be unclear where to start. A great place for each organization to start the journey is with one simple question: Why are we doing this in the first place?
An organization that implements a certain process because everyone else is doing it might not make it very far. If, on the other hand, a process is built around real business initiatives, such as reducing errors, quicker time to market, reduced costs or increased efficiency, then results should be better.
In Jez Humble and Dave Farley’s book Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment they said, “If something hurts, do it more frequently, and bring the pain forward.” If the organization can solve the processes’ biggest issues, or at least one of the biggest issues, then it can gain traction because the technology is easy in the end. Design and methodology are a little more challenging, but the hardest part is often getting people to jump on board. The best way to diffuse that resistance is to demonstrate that value where it hurts the most, expand it and turn people into champions.
If done right, with best practices in mind, benefits of a model-driven approach will show across the board: Decreased time to market will become the norm, all-hands emergency meetings at any hour of the day or night will become a thing of the past, onboarding new applications and switching out technologies will become more trivial and the business will grow. As a result, people in the organization will spend less time struggling to get a product out the door and more time focusing on what they do best.