Our current release procedure consists of taking a snapshot and putting it on the R drive. We cannot rebuild that snapshot, and it's difficult to patch with certainty. Even if we documented this as the approach to take, this would fail any audit.

Here I will sketch out a design for what I think is necessary to achieve a re-buildable release. It is however only a proposal and ideas are welcome.

There are two (main) ways of building products. These are the vastly oversimplified thumbnail sketches of both approaches.

Develop along Master (or Trunk) - freeze, then branch for a release. Bugs are fixed by patching the active branch and master.
Release along Master, branch for a development line/bug/feature, merge back to Master then release. Test builds are built along the branch.

The latter approach is described in more detail here:

https://www.atlassian.com/git/tutorials/comparing-workflows

(Counter views can be read here: http://endoflineblog.com/gitflow-considered-harmful)

For example, the upcoming 2017 changes could be developed along it's own branch then merged back and released when finished. It's probable that we could fit that branch name with the epic in bamboo - we can certainly tie in feature/bug builds with JIRA ticket numbers.

The problem we have is that our code-base is split across multiple repos, most of which are badly structured. We need to re-architect the code-base so it can be branched easily.

An interim approach would be to label all the necessary repos on the Master branch, check the repos on the label out and build - probably with a script.

Take Validation, for example. A major chunk of work that's been done on validation needs to be released - soon(ish). We should try that approach then.

Browser not supported