Petya Petrova - Fotolia
3 DevOps antipatterns to avoid at all costs
A DevOps initiative is not a single task, but an evolution of an organization's technology, processes and culture -- and without a collaborative mindset, it will likely fail.
DevOps adoption might entail short-term goals, such as daily code deployments to production, but it takes time to learn DevOps practices and processes for a successful implementation.
Enterprises sometimes believe that the creation of a dedicated DevOps team is all it takes to achieve same-day code deployments. Others think a quick pivot from traditional software development practices to DevOps always yields the best results. But these are common misconceptions, said Colin Wynd, head of Real Time Payments Technology at The Clearing House, in his 2020 DevOps Enterprise Summit Las Vegas session, The Three Anti-Patterns of DevOps, this month.
Just as there are steps to a successful DevOps transition, there are DevOps antipatterns -- common, yet ultimately ineffective approaches -- that organizations fall into.
But not all hope is lost. Below are three common DevOps antipatterns in the enterprise, according to Wynd -- and how to break them.
Antipattern #1: Thinking it's all about the DevOps team
What's in a name? Well, in the case of "DevOps team," often very little substance.
DevOps is more than a team name: It is an organizational structure, set of processes and a culture that changes the dynamics of a company to promote faster software release cycles. Simply calling a group of developers and IT operations staff a DevOps team does not, in fact, make them so. A name change doesn't address process or technology issues, nor does it train the staff and organization about DevOps.
"Really, it's this integrated team consisting of all the resources -- consisting of developers and operations, [and] information security -- [that creates] the business value," Wynd said.
The DevOps organization should stem from existing dev and ops teams, not be a separate entity. The creation of a separate DevOps organization might work if the long-term goal is to migrate, or integrate, the existing dev and ops staff into that organization. However, this approach can cause friction between the new and old teams.
A DevOps team is also not synonymous with the team that works on CI/CD tooling and creates an integrated tool stack, because the CI/CD tooling team isn't producing applications for production -- a key tenet of DevOps.
Break this DevOps antipattern with three steps:
1. Fix underlying processes. Enterprises need to implement continuous integration, which includes automated regression testing, security scanning, open source compliance and license monitoring, and code reviews. And they need to implement continuous deployment to all environments, including dev, quality control and production. Enterprises also need to consider how they will perform continuous measurement. In the DevOps infinity loop, it is critical to measure the environment and applications to give feedback to dev and operations.
2. Structure teams correctly. A team structure in a DevOps organization needs to not only have all resources -- dev, infosec and operations staff -- working together to reach business outcomes, but must also be balanced.
"What you don't want to have is development do a takeover of operations, or vice versa, where so much stuff is mandated you're not actually getting that equal partnership. It's more of a dictatorship," Wynd said.
3. Build the right culture. The emphasis on DevOps culture is well-deserved. For a DevOps organization to evolve and push code to production more quickly, management needs to enforce key principles of DevOps culture, such as collaboration, continual improvement and an openness to failure.
Antipattern #2: Taking too big of a step
A direct Waterfall-to-DevOps transition is too big of a jump for some organizations. While it's necessary to move away from Waterfall, diving straight into DevOps from software practices that are anything less than Agile, or Agile-like, might lead to drowning.
A sudden jump to DevOps from Waterfall methodologies means a lot of times enterprises will struggle to adjust their processes, people and culture to focus on multiple releases, Wynd explained. To break this DevOps antipattern, step back and transition more slowly between the different software development methodologies. Go from Waterfall to Water-Scrum-fall to an Agile-like approach before full Agile and, finally, to DevOps.
Over a period of a year or two, get to Agile, and then start to implement more of a DevOps philosophy, Wynd advised. "That gives you time to change your culture, to change a lot of your processes that you have, organize the teams and have people be able to understand DevOps and kind of get the basics in place. I think that's going to be a critical step, rather than the big jump."
Aim to get to production every couple of sprints and to decrease the time it takes to reach production. This approach will reveal any deployment roadblocks that prevent more frequent releases and give teams a chance to address them.
Antipattern #3: Not deploying code to production
If an organization isn't deploying code to production, it's not doing DevOps. And to get code to production, DevOps needs to be a partnership between the dev and ops teams.
Even if a dev team drives a DevOps implementation, gets the right tooling in place, sets up a CI process integrated with open source compliance practices, and does security scans, it doesn't have control of the production environment and can't deploy the code.
This is where poor integration or poor communication can halt deployment.
If the operations team hasn't bought into DevOps, or hasn't been told about it at all, bringing code into production requires a ticket, followed by lots of meetings and reviews -- a process that can take months, Wynd said. Integrate all teams and create a collaborative environment from the start to avoid this type of delay.
