Release Management Access Control
Access Control, at first glance seems to be a rather straight forward topic or task to handle. Well, I can assure you it is not. Especially when you’re working in an Engineering organization that seems to be schizophrenic at times in terms of its own unique identity. I’m talking about how there should be a fine line drawn between Dev, QA, Tech Pubs, Process Group, Program Management, Product Management, Operations, etc.
Where there is a lack of established structure and process, there exists disorder and chaos relating to software Builds and Releases. Access control must be implemented early on and strictly enforced to clearly define what can certain groups consume.
Builds, whether it be continuous, hourly, daily, or nightly in frequencies should only be made available to Dev and QA. No exceptions. In your org, if Program Management happens to fall under the umbrella of Engineering, then it wouldn’t hurt to grant Program Managers the same access privileges as that of the Dev and QA teams.
In no circumstances should groups such as Tech Pubs or Operations be given access to the builds. That is the quickest way to creating confusion and risk having the software leaked prematurely or worst, given to the customer without proper and formal approval.
Operations should only be given access to the released software (FCS – First Customer Shipment or GA – General Availability). Tech Pubs and to a certain limited scope extent, Operations, can be given early access preview to the Alpha or Beta phase of the software in a separate distribution location made especially for these groups. Since there may be needs for Tech Pubs to begin the documentation work and for Operations to go through the initial deployment exercises.
Aside from that, I believe you must keep the distribution points between the various groups well defined, structured, controlled, and most importantly, enforced. Part of being a good Build and Release Engineer is being a good enforcer of processes. Be unwavering in your stance when approached with a sob story or forceful demand for access to the builds distribution by a group outside of the QA or Dev teams. Speak softly, but carry a big night stick. 
I’ll be interested to learn how you manage your released software’s distribution in your org. Please share your thoughts.
One Response to “Release Management Access Control”
Leave a Reply
Related Topics:
No related posts.
Completely agree on this.
In my organization we have a delivery process (maintened by SCM) with tools that handle it.
Builds first are delivered to Dev/QA, then the software is made available to System Verification only if QA gives OK. Then sw is delivered to customers only if SV gives OK.