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.
...
For example, the upcoming 2017 changes would could be best 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.