The concept of DevOps is central to any organization’s ability to deliver applications and services quickly and efficiently. As it gains traction in many high-profile organizations, DevOps administrators must work to integrate DevOps practices, tools and techniques into a wide range of teams, from development and support to operations and management. Completing this implementation seamlessly leads to better productivity and a smoother overall workflow.
Bad Habits Derail DevOps
But along the way, administrators tend to fall into bad habits that affect their ability to deliver these services effectively and efficiently. Here are a few of the most common habits that need to be broken.
Working in Silos
Some DevOps teams work in silos, in which development isn’t just one team but many. Think about a group project where everyone divides and conquers on tasks and at the end comes together to integrate different parts, which in turn have different formats, styles, etc.
This is a bad habit that needs to be broken as it produces an additional level of complexity, with everyone working to solve their own issue at hand in their silo. Operations then struggle to unify the activity into a consistent process. This, coupled with occasional tensions between development and IT operations over different approaches to infrastructure and competition for resources, creates opportunities for failure. As the growing emphasis on DevOps places an added burden on infrastructure teams already struggling to cope with the digital transformation of their organizations, unification will be key to success.
It is also true that DevOps can find success in small organizations where teams of people are focused on smaller, one-off IT projects, rather than the enterprise as a whole. These smaller teams have the luxury of sticking to themselves and the allowance to work on sequential projects, while their projects don’t scale up to the enterprise stage because they don’t have to. But smaller organizations such as these also likely won’t see much of a difference if they were to adopt a DevOps approach.
That difference will be most noticeable in substantially larger organizations that see software release cycles rapidly changing on a daily basis. It is imperative for these organizations to avoid silos and to instead have pronounced team roles, better communication and the ability and willingness to break free of old habits that only cause chaos and confusion in the rapidly evolving delivery cycle.
Planning Too Much, Too Soon
Success requires continual improvement and refinement, rather than an initial push for certain changes without an overarching plan. The focus of administrators looking to implement DevOps should be on doing all things continuously by starting small.
Early focus should be on selecting one or two new DevOps teams that start a new initiative. Then, with these new teams in place, you can build on successes and work through challenges slowly, and begin to scale this through the organization. In the beginning of the process, it’s also important to identify one person such as director of operations or chief planner who can be responsible for seamlessly integrating DevOps into your project. This lead owner can then work project by project, setting goals and showing the rest of the team the results in real time. Insight into the progress will allow the team to see their work paying off, and in turn, make it possible for them to realize the benefits of scaling up slowly.
You need to know what the business problem is and the anticipated benefits, therefore measuring every factor that contributes to DevOps success. DevOps promises an array of automation. This can’t be achieved in a single attempt or overnight. Enterprises have to focus efforts on continuous integration, following it with continuous delivery and eventually continuous deployment.
Believing Implementation is Easy
After admins are finally swayed by the promise of DevOps, a belief often held is that the implementation of the practice is smooth and easy. And while DevOps can often lead to a simpler life for specific jobs in IT, the reality is that in many instances, the ease of deployment comes at a cost. It can shift an imbalance of responsibility for production control and quality management to the operations side, and burden the team rules and processes if IT departments fail to understand how to adapt.
As with any process in any organization, the amount of effort required to support software delivery is a constant. Often, administrators fall into the habit of believing DevOps will handle itself. But if you are managing a large enterprise, you will have teams accountable for quality, performance and change management. The difference with DevOps is the way in which automation is leveraged to place control in the hands of application development teams and redefines the relationship between operations and development. This is a good thing, but the administrators need to be there every step of the way in the process.
Failing to Take Full Advantage of Continuous Integration and Delivery
Continuous integration and continuous delivery (CI/CD) are key to successful DevOps teams. However, a bad habit many DevOps teams can fall into is failing to take full advantage of all the CI/CD benefits. The process must to be fast and efficient, as anything that slows down any part of the process increases the cycle time and slows down delivery. To break the habit, DevOps teams need to focus on eliminating bottlenecks in their pipeline to then facilitate agile development processes.
Your CI/CD pipeline allows for the chance to administer efficient automated testing into your process, but shouldn’t stop at continuous delivery and continuous integration. Another step in doing all things continuous is continuous improvement. DevOps teams and administrators are constantly evolving to fit the needs of the pipeline, and it is imperative that teams spend some time every day discussing and hashing out the small things that can be improved upon. Over time, these changes—no matter how small—will have a profound effect on the enterprise and overall quality of morale between administrators and their teams.
— Matt Geddes
