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.
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 would 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
The problem we have is that our code-base is split across