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.

So why build machine image archiving you may ask?   Because sometimes when certain software gets released (1.0), the new (2.0) continues on the trunk with added features and *changes* compiler(s).  Now as 2.0 goes forward, the legacy 1.0 may still have bug fixes and the build loop may need to be brought back to reproduce a certain build; with that in mind, having a VMWare image works wonders in such situation.  There is a long list of benefits for such practice as well, but I’m not going through them now; I may add to this post in the future…

Project after project, build after builds and releases gets implemented and soon the SCM team experiences what I would like to call the avalanche of legacy build project conversion requests.  Early adopters get to experience the bliss of a particular new build and release infrastructure and suddenly good words and reviews spreads like wild fire to other groups.  Soon every group within the developmental organization is knocking on the SCM group’s door asking to have their projects converted over.

So what do you do when business is good and the team seems like it can do no wrong?  You pay attention to the burnout factor of each of these overworked and overstressed SCM Engineers.  Offer telecommuting options or flex days (days off for extra hours worked), pay attention to each Engineer’s sentiments and get frequent feedback.  Failure to do so will be the quickest way to drive talented SCM Engineers out of the company and into the doors of your competitor.

• Engineering: These builds lives on the individual developer’s machine. It should never see the light of day beyond this scope. This is merely a convenient build tool designed to allow developers to easily build and debug their code. There are exceptions, however; for teams developing in the new .NET paradigm using the all inclusive solution (*.sln) files to build will have no need for this type of build. This is mainly useful for older softwares where several manual modification/moving/copying of file operations are need. These builds are then classified as on-demand.
• Continuous Integration (Development): These types of builds can also be referred to as the Continuous Integration (CI) builds. These builds lives on a stand-alone machine and the artifacts should only be made available to the immediate development team of the respective project. These builds should then be considered continuous since it is constantly polling for new check-ins.
• Software Configuration Management (Product Testing): These builds are on-demand and should only be initiated by team leads or managers of the particular development group. These builds should be built based on a label within the source control tool. There should not be any errors as these builds are derived from successful CI builds. The consumer for these builds will be the QA group.
• Software Configuration Management (Product Release): Similar to that of the product test SCM builds, these only differ in nature and title as they are meant for real world consumption.

To create quick build turn-arounds, plentiful CPU cycles, clean and reproducible build environments; each one of these build classifications should live on its own machine/server.   The two flavors of SCM builds can actually be on the same server, but Engineering, CI, and SCM must all exist separately.

There is another way of looking at this, especially when considering the agile process, and especially when in an enterprise software environment.

You still have the needs for a Engineer build and a CI build but instead of the SCM builds you instead “promote” the CI build.  What this effectively means is that someone chooses a CI build to push towards QA, and then this is pushed ultimately to production, etc.

As a process it has the advantage of being simplier and centralises all efforts around the automated build.   It is physically impossible for the wrong code to get built for production because someone changed a tag, instead the built artifact is the same (and can be checked against an MD5 to test it).

Although not as frequent in the .NET world its a common practice in the Java world.