Access Control,

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.

It should be the ultimate goal of an SCM Engineer to automate him/herself out of a job.  This may not make sense to some of you, but when you think about it–it should make perfect sense.  Our specialties are to enforce, streamline, and automate all software development activities. Forget the notion of ‘job security‘ by holding on to a certain build process that ONLY you know how to perform because at the end, it will only be detrimental to your career.

By sharing, automating, cross-training, and documenting all the processes, tools, and activities within the SCM group; you free yourself from a lot of manual tasks and at the same time, you become a leading edge industry expert within your field because you’ve worked with the latest and greatest.

This is my vision statement or somewhat of a professional credo, so to speak:

SCM is the singular working entity within [insert org name] that is responsible for planning, designing, defining, implementing, and managerial duties of the SCM build and release infrastructure, hardware and software architecture, processes, and activities by which to support the life-cycle of any Software Development Group/Project/Process.

Now, what’s yours?

There really isn’t one clean cut solution that will work for anyone because this largely depends on your organization’s structure and relationship with the IT group.  What has worked for me in the past SCM group was drafting then approving a service agreement with IT. In it, we specifically address the following questions:

1. What is expected of them?
2. How urgent each request should be classified?
3. What is the reasonable response time?
4. Which personnel resources are available?

If establishing a service agreement is too formal, and you don’t believe in the CYA (cover your ass) route then your team must have a rotational on-call support where at any given time you’ll have a point-of-contact SCM person.

No, Black Box is not referring to a quality assurance testing methodology.  What I am referring to, in this case, is to not let any one SCM Engineer build something that is so complicated that only he/she knows how to reproduce or trigger the build.  As a serious software development company, group, or team, you cannot afford to have one single point of failure; which in this case is a person.  How then, might you ask, can this problem be addressed? Here are some suggestions:

1. Cross-Training Between SCM Engineers
2. Un-complicate an otherwise Complicated Infrastructure/Process
3. Have a transparent “Hood Cover” so to speak
4. Switch each SCM Engineer’s support Role from Project to Project to Promote Even Rotation
5. Hire a Consultant who comes in once a month to learn the new project or infrastructure as a “backup” plan
6. You, as the manager, take the place of a consultant and do #5
7. Get creative..

The days where only a selected few in an SCM group knows how to build a particular project “by going into a certain script and adding a sequence of characters (%!@#!@) then pet the build machine exactly 5 times and turn yourself around followed by a brief chant of “hocus pocus” before the build finally kicks off” should be a distant memory.