Development and operations (DevOps) is a set of methodologies and processes that promote efficiency and innovation in product development and delivery. Our experience has been that some developers and managers mistake DevOps to mean the automating of an infrastructure. While automation is often an attribute of a DevOps model, DevOps in itself is an idea that encompasses a variety of attributes. A key point of failure for projects we studied was the disregard for the cultural aspect of DevOps. A no-blame culture encourages innovation because individual contributors know they are part of a team and that any failure is a learning opportunity and a chance to grow professionally; they do not fear ridicule or avoid innovation for fear of unconstructive criticism.
DevOps failure often comes in one of three flavors:
- Cultural rejection (failure to adapt)
- Incomplete design
- Unsupported infrastructure
Cultural rejection is widespread because once you have a system that seems to work, starting over and learning a new procedure isn’t appealing to IT professionals. I remember my first attempt at implementing a CI/CD strategy and using a YAML linter on a Puppet project. The first developers who committed their hieradata got rejected because of inconsistent spacing; after three tries, all commits were in, but the developers refused to use the pipeline because it set them back.
We have also implemented Git branching strategies to keep version features from creeping into previous software iterations. The strategy had a version branch and a master branch. Both branches were locked, and the only way to get code in was to create a feature branch off the version branch and submit a pull request, also called a merge request. The idea was that peer code review would occur and would be a second pair of eyes for possible bugs or design flaws.
A branching strategy may be a new idea to a developer, and their willingness to adopt the approach may hinder the efficiency of the pipeline. The chances of cultural rejection decline when the team is part of the design; when someone feels they are vested in an idea, they are more willing to accept it and overcome obstacles. The best advice I ever received in my DevOPS career was that adopting DevOPS requires the support of upper-level management; it also needs the support of those who will use the system. What is it worth if a solution is implemented but nobody uses it? A good implementation plan, participative leadership, stakeholder support, and a supportive culture are great ingredients for Successful DevOps.