As DevOps is increasingly recognized as a pillar of digital transformation, CIOs are becoming more enthusiastic about how DevOps and open source can transform enterprise culture. DevOps refers to a group of concepts that, while not all new, have catalyzed into a movement that is rapidly spreading throughout the technical community. Just look at the number of books and resources that are available to help you take your DevOps initiatives and practices to the next level.
Still, many people don’t fully understand what DevOps means. And without the right knowledge and understanding, many DevOps initiatives fail to get off the ground. Here are six common mistakes—and how to avoid them—as you start your DevOps journey.
1. Creating a single DevOps team
The most common mistake organizations make is to create a brand-new team, tasked with addressing all the burdens of a DevOps initiative. It’s complicated enough for development and operations to deal with a new team that must coordinate with everyone. DevOps started with the idea of improving collaboration between teams involved in the development of software such as security, QA, and DBMS; it’s not just about development and operations. If you create a new team to address DevOps, you’re just making things more complicated.
The secret sauce here is simplicity. Focus on culture by fostering a mindset of automation, quality, and stability. For example, you might involve everyone in a conversation about your architecture, or about common problems found in production environments in which all relevant players need to be aware of how their work affects others. DevOps is not just about a single dedicated team, but about organizations that evolve together as a DevOps team.
2. Focusing on too many tools
There are many tools available to help you implement DevOps initiatives. Don’t start your DevOps strategy by arguing about and selecting a bunch of different tools. You will soon see it is difficult to find the right tools for team and organizational processes because each team (developers, IT operations, security, etc.) will want to use a specific tool for their DevOps practices, even if it makes it harder to collaborate with other teams. Also, new tools are emerging all the time—there’s even one that will help integrate other tools.
Of course, you need to have the right tools for agile software development, continuous integration, deployment, version control, and so on. Not having the right tools can prevent teams from seeing the maximum benefit from their DevOps efforts. But simply buying a continuous deployment tool or deploying application containers isn’t enough to transition your organization to DevOps.
You will likely hear some vendors claim to have the perfect tool for your DevOps practices, but take an agnostic approach and keep in mind that there’s no single tool that can possibly cover everything you need.
3. Focusing on speed rather than safety and quality
Many organizations adopt a CI/CD strategy as a part of their DevOps initiatives because they need to reduce the amount of time it takes them to develop and deploy new application code. However, DevOps practitioners say that increasing speed at the expense of security and quality is a big mistake. Even if you build, test, and deploy new applications much faster in production, what if those applications don’t function as intended?
Many enterprises make the mistake of not following their security practices well in advance
To keep security and quality high, development teams should conduct testing as early in the development process as possible. More importantly, prove that the release candidate is ready for continuous delivery before deploying.
4. Allowing too many branches
In agile software development and DevOps practices, software (trunk) should always be deployable so developers are able to check into trunk—not feature branches—at least daily. If the build breaks, it can be fixed in ten minutes and a new developer can be on-boarded in one day, with a production-like environment on their developer workstation.
It can be difficult to break developers out of the habit of using branches if they are accustomed to a traditional waterfall environment, but limiting branches can be highly beneficial. If you favor trunk-based development, have developers work at all times in a mostly coherent, single version of your codebase.
According to Puppet’s 2017 State of DevOps report: “We found that having branches or forks with very short lifetimes (less than a day) before merged into trunk, and less than three active branches in total, are important aspects of continuous delivery, and all contribute to higher performance. So does merging code into trunk or master on a daily basis.”
DevOps automates many aspects of how you treat your code between developers’ machines and production environments. Keeping many different conceptual flavors of your codebase around makes DevOps concerns an order of magnitude more complex.
5. Not involving the security team
DevOps involves more than simply putting the development and operations teams together; it is a continuous process of software development and automation, including security, audit, and compliance. Many enterprises make the mistake of not following their security practices well in advance.
In fact, a CA Technologies survey found that security concerns were the number-one obstacle to DevOps, cited by 38% of respondents. In the same vein, the Puppet survey found that high-performing DevOps teams “spend 50% less time remediating security issues than low performers.” Clearly, these high-performing teams have found ways to communicate their security objectives and to build security early into phases of their development process.
The DevOps practitioner should understand the processes, evaluate the controls, and identify the risks. In the end, security is always a part of DevOps practices like DevSecOps. For example, if you have any security issues in production, you can address them within your DevOps pipeline through the tools that the security team already uses. DevOps and security practices must be strictly followed. There should be no compromises.
6. Not preparing for culture change
Once you have the right tools for DevOps practices, you will probably face a new foundational challenge: Trying to make your teams use the tools for faster development, automated testing, continuous delivery, and monitoring. Is your Dev or Ops culture is ready for the changes?
For example, agile methodologies generally mandate that you ship new code once a week, or even once a day. This can result in a lot of awkward, halting, and failed adoptions of agile. You face the same conceptual issues with DevOps. It can be like pulling onto a nice smooth new road with a car that has no gas.
To avoid this, plan for a transition period. Leave enough time for the Dev and Ops teams to get used to your new practices. Make sure they have a chance to get hands-on experience with the new processes and tools. Before adopting DevOps, make sure you’ve matured your Dev and Ops culture.
Conclusion
Once you overcome the challenges and adopt DevOps practices, your organization will enjoy greater agility, improved customer satisfaction and employee morale, and increased productivity—all of which should help grow your business.
Source: opensource.com
