DevOps, with its pursuit of continuous application updates, is revolutionizing the way organizations approach software development. Doing so allows businesses to keep up with business demands and the more rapid pace of updates for cloud and mobile applications.
Unfortunately, many enterprises take DevOps to an unproductive extreme. In an attempt to automate development processes, people link together too many tools and end up over-automating. This level of DevOps automation can lead to all sort of undesirable outcomes.
The trick is to strike a balance between over- and under-automation of DevOps. It's a matter of understanding your own requirements when it comes to development, testing, and deployment. Only when you have that information should you bring in the appropriate processes and automated tools. You must also provide the training required to make sure your developers and administrators understand the proper use of the tools.
Overdoing DevOps automation
The root of the problem lies in confusion around waterfall versus agile methodologies. While agile is the newer and seemingly more productive approach, some enterprises miss the boat because they take agile to an extreme. They're overusing agile, and thus overusing the automation of agile and DevOps.
The PMI surveys of the last two years shed light on where traditional and agile methodologies are used. While more organizations realize the benefits of agile and DevOps, the survey reveals that in some cases, enterprises aren't doing a good job of managing projects correctly or using standard practices across projects. Consider:
- 38 percent of organizations report frequent use of agile
- High-performing organizations are three times as likely to have organizational agility
- 77 percent of high-performing organizations attend ongoing project management training
- 46 percent of organizations report they don't fully understand the value of project management
- Only 25 percent of organizations report using standardized project management practices
451 Research's senior research analyst Jay Lyman says he sees a similar trend. "I think there is a tendency to think that large enterprise organizations, with all their divisions and teams and silos, are capable of doing what Facebook or Netflix have done with their cutting-edge implementations of configuration management tools. In reality, all of the legacy technology and process has to be taken into account as well."
While DevOps tool providers may sell automation products that promise to make you the next Facebook or Netflix, the reality is that your organization isn't like Facebook or Netflix, and it never will be. If you try to replicate their automation solutions, you'll quickly find yourself in a world of hurt. The investment you have made in DevOps and automation will blow up in your face—not because you automated, but because you attempted to automate too much.
Striking a balance
Some enterprises are clearly over-automating DevOps, while some aren't automating at all. How do you find your own balance?
First, you need to understand that automation is about taking once manual processes and placing technology around them so they're inherently repeatable. If your processes are bad or flawed, then you're just making bad processes happen faster.
Your first efforts should be focused on what processes occur during development. Once those are vetted and locked down, it's just a matter of backing the appropriate DevOps automated tools into those processes. However, not all processes can—or should—be automated.
Second, understand that you're unique. DevOps tool vendors have a habit of getting you excited about what they're doing at a video streaming or social media provider, but your company has been manufacturing tires for the last 100 years. You're not Netflix, and your mix of old and new systems, as well as use of the cloud, will be much more of a challenge.
Take an inventory of all of your applications, data stores, and current development processes. This will lead to your meta development processes, which typically include design, development, test, provisioning, deployment, configuration management, and so on.
Breaking down processes
For your meta development process, you can break the process components down from there to sub-processes, which will be your candidates for DevOps automation. However, it's at this time that you may choose to fix some or all of those processes and determine which processes should be kept, created, or fixed. Take your time during this phase. It'll set the stage for how you do development for years to come.
Next, combine your fixed or corrected processes or any tasks that will include DevOps-related concepts and enabling technology, such as continuous development, continuous integration, continuous testing, and continuous deployment.
Finally, it's time to select tools—and this is where most enterprises go off the rails. Once you have defined the major and minor processes and combined those into DevOps processes, you must figure out which tools are appropriate to automate those processes.
Those who over-automate typically focus on the tools more than the processes. They select the technology based upon what others use and don't understand how they're doing—or should be doing—development. They end up with too many tools and must adjust their DevOps processes to accommodate those tools, not the other way around.
For example, a retail organization tried to automate the entire lifecycle to make it possible for developers to build, test, integrate, and deploy any code at any time. The vision was to build or change applications at the "speed of need" for the business. This was the objective, but the reality was that new versions of the application code were released to a cloud platform twice a day or more.
As a result, the users became frustrated with the number of times that the user interface changed, as well as items in the database that were added or removed. Moreover, the automated testing was not completely holistic, and some quality issues emerged that could have easily been caught if humans were doing at least some of the regression and performance testing.
The end result was the retail organization removing some of the DevOps automated tools from the developers' work stream. They also limited the types of changes the developers could make and placed more rigor around reviews, deployments, and testing.
Above all, do no harm
Don't shy away from agile or DevOps because of a few examples of over-automation. There's a huge amount of value that you can gain from the use of these approaches and enabling technologies. The amount of DevOps technology on the market today is growing by leaps and bounds, and it's improving and growing rapidly.
According to Gartner, sales of DevOps tool sets will reach $2.3 billion in 2015, up 21.1 percent from 2014. "By 2016, DevOps will evolve from a niche strategy employed by large cloud providers to a mainstream strategy employed by 25 percent of Global 2000 organizations," the report states.
As DevOps tools improve and become more pervasive, 25 percent of Global 2000 organizations will begin to use DevOps and related technologies. The danger is that they'll over- or under-automate using these tools and miss out on the full benefits until some large mistakes are made, found, and corrected.
DevOps nirvana comes with the knowledge of how you need to do agile development, as opposed to how others are doing it. Organizations often end up using DevOps tools not with their own vision but with the visions of others. Don't make that mistake.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
