Improving DevOps Communication Means Fewer Roadblocks and Risk to Project Schedule

When developers were asked what the main cause of failure or delays in getting code into production was, more than half cited that either inconsistencies between production and development or a lack of collaboration with operations were at fault. Over half!

Communication is central to solving these problems, and processes such as continuous delivery can help reinforce the proper behaviors. Continuous delivery’s focus on automated testing and environment building points out breakdowns in DevOps collaboration and provides a natural incentive for people to communicate, because no one wants to be the one to have broken the smooth flow of work.

Consider a developer who runs into a problem in his or her local development environment because the list of dependencies needs to be updated. The developer installs an extra library and gets on with his work. When the time comes to deploy the software, it doesn’t work in production, because the library isn’t there. Downtime may be involved, the release may be delayed while operations determines the impact of the library, or both.

In a continuous delivery environment, the continuous integration (CI) server is constantly testing new changes to the code base by running the complete test suite. When the developer committed his code, the CI server ran the automated tests, which failed because the local version of the library is out of date. The failure would bring the problem to the attention of the whole team, including operations staff, who could then make sure the library is supportable and that it has been pushed to CI and production. With good infrastructure automation, this addition is easily promoted to all environments after the testing has been performed. The systems change can also be pushed out to development environments, which gives other developers a production-like environment in which to work.

The checks and balances that CI and infrastructure automation provide offer a natural feedback cycle to improve DevOps communication. If a developer breaks the build because he or she didn’t involve operations soon enough, the team has to stop shipping until the problem has been fixed. When the developer involves operations at an early stage, operations teams can spend more time understanding the proposed changes. Through automation, the infrastructure changes are ready in all environments when they are needed and staff have more confidence in the reliability of the process.

Similarly, continuous delivery ensures regular communication from operations back to developers. Operations staff must also communicate their changes with developers or they will quickly break the build and possibly developers’ local environments. If operations solicits early feedback from developers, such as the effects of upgrading a PHP libary, the upgrades can be tested by developers and promoted to CI, staging, and finally production without breaking anything. Operations gets the upgrades they need to stay current and developers aren’t needlessly bothered with broken builds.

Continuous delivery relies on people to communicate, lest the flow be interrupted as a result of some unforeseen change. When communication is poor, the continuous delivery cycle breaks easily as the changes become material. The desire to keep the flow going and not to be the person to have broken the build provides incentive for the team to work together and communicate changes. Regular reviews or retrospectives provide further feedback to the group, allowing them to reflect on situations where communication helped or hindered the continuous delivery pipeline and ultimately led to the team hitting or missing their deadlines.

What are the key takeways?  Encourage development teams to involve operations staff early in projects and when environment problems are found. Operations staff, in turn, must keep the lines of communication open with the developers. Implementing ideas from continuous delivery processes and regular review of problems and successes will help to reinforce these behaviors.

Learn More about Continuous Delivery best practices:

The Zend Blueprint for Continuous Delivery provides practical best practices to help companies implement each step of the continuous delivery cycle. Based on the Zend Server platform, the blueprint provides an easy way to implement these best practices through a series of patterns and plug-ins.

The following two tabs change content below.

    Sean Walberg