4 Common Pitfalls When Adopting DevOps
DevOps isn't just implementing one or two tricks. Take a look at these common mistakes to make sure you're on the road to full DevOps adoption.
Join the DZone community and get the full member experience.Join For Free
DevOps as a concept has been around for nearly 10 years. While it’s more widespread than ever, for many, DevOps has gone from magic bullet to meaningless buzzword status. There’s a creeping sense of unfulfilled promises. Where did it all go wrong? Are we setting expectations too high? Moving too fast? Not being ambitious enough? Did we set DevOps up to fail?
I chatted with some of our Customer Success team members here at GitLab to find out where customers are running into trouble, and what they can do about it. Below are the top four pitfalls organizations can avoid when adopting DevOps:
1. You Invest in Too Many Tools
“You think you have it all when you’ve got your issue tracker, version control system, CI/CD service, etc.,” says Technical Account Manager, John Woods. “However, what's the cost of setting all those up and configuring them to ‘talk’ to each other?” The cost of maintaining and upgrading each of those instances and maintaining the connection between all of them is difficult to tally both in pure monetary terms and in time. We call this the DevOps tax, and it’s often overlooked when assessing the success (or lack thereof!) of DevOps adoption. Which brings us to...
2. You’re Married to Your Toolset
When you’ve invested in tools it’s difficult to throw in the towel. But sometimes that’s exactly what needs to be done. “I recently was in a conversation where the VP said their system was solid and robust. They insisted they are doing everything the way that things should be done using tools they've been honing since 2003,” says Joel Krooswyk, solutions architects manager at GitLab. This speaks to complacency in DevOps implementation. “DevOps is never ‘done.’” says Joel. “Tools come and go, and some of the ones you’ve invested in don’t have a strong roadmap or are dying slowly. To put faith there is poor judgment.”
What’s the upshot? “We need to be aware that better solutions may be available, which provide us more speed, increased efficiency, and improved workflow,” Joel adds. This includes considering solutions that are built for DevOps, rather than just being adapted to it.
3. You Stop at Testing
Integrating testing into deployment pipelines has been a huge shift for many large, legacy companies, and this should be treated as a major accomplishment. But why stop there? “All too often, pipelines are ‘build, test’ and that’s it. It’s a step forward, but it’s insufficient,” says Joel. “They don’t go far enough for their first iteration.” A deployment pipeline that’s truly DevOps optimized should incorporate deployment and monitoring as a minimum requirement as well.
4. You Still Treat Security as an Afterthought
Running security checks infrequently is a hangover from legacy systems where security testing is costly (sometimes requiring payment per line of code). A recent study found that only 50 percent of CI/CD workflows include application security testing. Adopting a tool whose security products are truly shifted left, and can be run without per-line cost fears, is essential to leveling up DevOps transformation and preventing the loss of gains from other DevOps initiatives when security vulnerabilities are discovered at the 11th hour.
Published at DZone with permission of Rebecca Dodd, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.