The Unsung Heroes - Configuration Management and the Guy with Access to Production

Completing out this build series of blogs, I would be remiss if I didn't mention some of the key team members that keep products moving. When I think through the number of projects I have seen over the full product life-cycle, there's always a group of people who stand out to me. Namely, configuration management, and that one guy, or gal, who has production access.

These are the behind the scenes folks who do the heavy lifting when architects hang their hats and development turns out the lights. I've worked with configuration management resources who spent hours daily resolving merge conflicts brought on by missing libraries, or a developer who checked in untested code 5 minutes before leaving the office. And then there's that one person who has access to production to fix issues real-time. This is the person who is always calm and collected and never makes a mistake in production. The person we admire but never want to be. This person is accessible at any hour of the day, they'll get out of bed to fix a major production issue and not complain about it the next morning.

So how can we ensure we keep these people on our teams. Mainly we've got to keep their work manageable. To do this there are a few things the entire team can do to chip in.

Stakeholders should understand the full scope of requested production changes

Stakeholders might request what seems to be a simple change in production; such as a content management change, or event a configuration setting update. But often times those changes also require updates to code in multiple places. If a full investigation isn't performed, changes like these on a short timeline are bound to lead to a hot mess. One way to implement these changes in safely is by smoke testing in a QA environment prior to production. Also resisting the desire to promote such changes on a Friday afternoon is a big help. I know waiting for Monday morning might seem like an eternity and the thought of your users seeing an incorrect price or a misspelled word on the base page can be gut wrenching, but its worth it to ensure all required updates are made.

Project managers and business analysts should not force developers to make changes without the proper time to fully test and compile their code

When project managers and BA's are in a hurry to get a fix in, they can put developers in a position causing them to rush to make critical changes. These changes may not break the build, but they could wreak havoc on production, causing unnecessary work for those who manage it.

Developers should hold off on checking in code they haven't unit tested

Untested code is a big cause for merge conflicts. I know many of developers have been there, checking in small snippets of code at the end of the day to fix a seemingly easy problem, only to find they missed including a library or worse a semi-colon 😵 . Developers shouldn't assume that small changes don't require testing because when they do it causes more work for others.

Overall we should work hard for the people who work hard for us. The idiom, measure twice and cut once, comes to mind in these instances. If we do our due diligence, we can increase the quality of life for our teammates. Hats off to you, guy with production access!