Software Build and Release Specialist

To promote the spirit of Agile Development and Continuous Integration, groups of builds must be classified and treated differently within the development organization. These builds are as follows:

• 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.