Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Operations should Communicate Close to the Change

DZone's Guide to

Operations should Communicate Close to the Change

· DevOps Zone
Free Resource

Download the blueprint that can take a company of any maturity level all the way up to enterprise-scale continuous delivery using a combination of Automic Release Automation, Automic’s 20+ years of business automation experience, and the proven tools and practices the company is already leveraging.

I have said this before but it bears repeating. If you are making a change and you want people to know you have made a change, add a note where someone is most likely to come in contact with your note.

If you are editing a file, add a comment to the bit you edited stating you did it and when (and if there’s an internal story/ticket reference)

If you are performing maintenance on a system add a note to the motd so people see it when they login. Be specific about what they should expect to see and what, if anything, should NOT be out of the ordinary (services that should still be running).

If you deprecated an old script, make the script dump an error telling the person what happened. Make the script fail to run if it shouldn’t – don’t just expect that people will not run it, they will.

Think about how someone might come in contact with your change and be defensive, they’ll appreciate it.

Source:  http://www.opsbs.com/index.php/2011/11/communicate-close-to-the-change/

Download the ‘Practical Blueprint to Continuous Delivery’ to learn how Automic Release Automation can help you begin or continue your company’s digital transformation.

Topics:

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}