One of the great traits of an organization that adopts DevOps principles or even just an Agile methodology is that everything, and I mean everything, is more dynamic. While each company will have a different level of fluidity in their processes, Clip Interactive’s source control and deployment processes are very fluid. As such, we attempt to over communicate when it comes to these parts of the engineering process.
The primary methods of communication the engineering team and rest of the company have adopted are chat/instant messaging and email. There are several chat clients out there, all of which have their pros and cons and there is no one right answer except what works best for your team. At Clip, we have chosen to use HipChat. Other options include IRC, Flowdock, GTalk, Skype and the list goes on. HipChat was a good option for us because it is cross-platform, supports custom plugins and integrates with a wide variety of tools.
In HipChat, each time an engineer pushes code into source control, a build is started, finishes or deployment runs on a QA system a message gets posted to the “Engineering Feed”. The messages for code pushes include the commit summary and link to the code diffs. Messages regarding builds and deployments contain a link to their respective outputs. More significant events, such as deployments to staging and production, get posted to the general chat room where more conversation happens and other non-engineers are more likely to be. Those notifications are pulled “out of the noise” of the feed. Additionally, these activities are typically chatted about more before they happened, so they fit more in the flow of conversation. Last but not least, system notifications, including warnings, problems, recoveries and acknowledgements from Nagios, are sent into the “Operations” room. To keep everyone informed and spread the knowledge, we post updates and resolutions to issues in the chat room. All of these messages enable everyone to keep a pulse on the state of the system without being intrusive and should problems arise, to very quickly put together a chronology of events. Aside from the automated items, there are additional rooms for in-depth feature discussion, production problems and sometimes just for fun.
Another key form of communication is good old email. Our build and monitoring systems sends the standard emails and text messages directly to the engineering team. Each production deployment sends out the list of commit messages, naturally with links to the code diffs. Since our deployment process is very fluid, this extra notification has gone a long way toward keeping everyone informed on the features being deployed into production.
Going forward, we intend to add more automated communication around the product management process and system performance metrics. These automated communications, when added to our normal cadence of meetings, have had a significant impact on getting us closer to the goal of improving transparency in and out of the engineering team, while not making people go out of their way gain value from the tools.
