1. Software Engineering and Architecture
Release Management &
Branching Models

2. Henrik Bærbak Christensen
Branching
Henrik Bærbak Christensen

3. Henrik Bærbak Christensen
Branching Models
Git excels in branching, whereas SubVersion is bit heavy
I use SubVersion for document oriented projects
Because I like the simpler model of SubVersion and there is seldom need for branching
All my course web pages and my book are SubVersion handled
I use Git for source code oriented projects
Because branching provides better workflow for experimenting and releasing
Henrik Bærbak Christensen

4. Henrik Bærbak Christensen
Release Management
You need to know what you release!
Users report bugs and you need to fix them fast on the right code
Example
Release to AlphaTown
Rewrite part of the AlphaTown code to support BetaTown
(Major refactorings in core AlphaTown code)
AlphaTown phones us ”Hurry, fix major bug now”
But the code base is in a ‘state of flux’ (read: messy, broken, …) and also includes new features that AlphaTown has not paid for
What to do???
Henrik Bærbak Christensen

5. Not all versions are equal
Some versions attain a special meaning: Release
How to manage?
Write down the version identity. Git: 4ef678a…
‘Tag’ a version on the graph.
Essentially put a human readable label on specific version
Make a ‘release branch’
Branch and name the new branch ‘Release-AlphaTown-V1.7.4’
Merge into a ‘release branch’ and tag it
Merge current version into global release branch and tag it
Releases should always reside on a branch! Why?
Because otherwise main development interfere in case you need to fix a bug; and branches makes the release ‘stand out’ from the main development work
Henrik Bærbak Christensen

6. Tags Considered Harmful?
Tags are available in all SCM system
However ‘tags’ have some liabilities
They are just ‘strings’ without any semantics
Version id 12: ‘Release2.0’
Version id 13: ‘Release1.0’ ???
I.e. not really organized in a version graph
No automation – you have to remember to tag
Tag twice with same string?
(git actually rejects it; CVS just overwrote it )
Henrik Bærbak Christensen

7. Recommended for HotCiv
Two Simple Models
Recommended for HotCiv

8. Henrik Bærbak Christensen
Simple Release Model A
Single Release Branch
Hotfixing must be done on separate branch
And merged back
Henrik Bærbak Christensen

9. Henrik Bærbak Christensen
In Practice
Finally, all features implemented
Henrik Bærbak Christensen

10. Henrik Bærbak Christensen
Release 1
Let us release it!
All releases are on the release branch; use ‘tag’ to id it
Only first time
Henrik Bærbak Christensen

11. Continue work on master
Refactor architecture to support BetaTown
Henrik Bærbak Christensen

12. Henrik Bærbak Christensen
Release 2
‘cross the t, dot the i’ and release
Checkout the release branch; merge master into it; tag
Henrik Bærbak Christensen

13. Henrik Bærbak Christensen
Discussion
Pro
Get the latest release is just ‘git checkout release’ which is easy
Fewer branches (only ‘release’ and ‘hotfix’ used for releasing)
Cons
Hotfixing is difficult; you need a special branch for that
Branch/Merge over into hotfix, make changes, merge back
Hotfixing release 1 after release 2 will require a new branch
Or you will mix the two!
Henrik Bærbak Christensen

14. Henrik Bærbak Christensen
Simple Release Model B
Major Release Branches
Each major release give rise to new branch
Henrik Bærbak Christensen

15. Henrik Bærbak Christensen
In Practice
Working on ‘master’, close to release
Henrik Bærbak Christensen

16. Henrik Bærbak Christensen
In Practice
Make the final code, commit that
Henrik Bærbak Christensen

17. Henrik Bærbak Christensen
Release 1
‘cross the t, dot the i’ and release
‘branch’ and potentially ‘checkout’
Henrik Bærbak Christensen

18. Continue work on master
Refactor architecture to support BetaTown
Henrik Bærbak Christensen

19. Henrik Bærbak Christensen
Release 2
Make a new branch for every major release
Hotfixing e.g. release 1
Checkout that branch; make changes; commit to make release 1.0.1
Tag it with that name (Release1.0.1) to know what is released!
Henrik Bærbak Christensen

20. Henrik Bærbak Christensen
Discussion
Pro
Each major release has a branch, allows hotfixing each with ease
Con
Many releases means many branches to overview
Henrik Bærbak Christensen

21. … and an Important Note…
Tag information is stored in the repository
So remember to push them to the origin
git push - - tags
The ”Ferrari without any safetybelt” again 
Henrik Bærbak Christensen

22. Henrik Bærbak Christensen
Maintaining Releases
Maintaining multiple concurrent releases is expensive
Windows 7, Windows 8.1, Windows 10, Win Server …
And even Windows XP in the face of WannaCry virus!
Thus many companies adopt one release policy
Firefox checks for new versions and enforces updating!
As do
Dropbox, source tree, ... And Windows 10!
And of course all web based tools
Henrik Bærbak Christensen

23. Recommended Models in SWEA
Keep it simple.
Learn a stronger model for heavy industrial practice, later in your life . (Have a look at Driessen’s model.)
Git defaults to the branch called ‘master’ so stick to this as your team’s development branch.
You ‘release’ every time you hand in a mandatory project to your TA and evaluation.
Either
Single release branch – or one branch per release model…
Henrik Bærbak Christensen

24. Recommended Model in SWEA
Major refactoring/risky business/experiments on a ‘issue’ branch
To avoid messing up the master branch!
Easy to ‘Do Over’, just orphan that branch
Tag it with ‘BAD-IDEA-17’ 
If the idea was good, them merge it back into ‘master’
Henrik Bærbak Christensen

25. Henrik Bærbak Christensen
Examples
Future reference for (very) large scale development
Henrik Bærbak Christensen

26. Henrik Bærbak Christensen
Summary
Branching supports the release and development process
Releasing, bugfixing, subteams, feature branches, …
Many different models can be made
Agree on a model in your team!
Keep it simple! Emphasize ease in daily work!
Avoid reinventing the wheel
Find a suitable model in literature
Henrik Bærbak Christensen