Software Engineering and Architecture Release Management & Branching Models

Henrik Bærbak Christensen Branching CS@AU Henrik Bærbak Christensen

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 CS@AU Henrik Bærbak Christensen

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??? CS@AU Henrik Bærbak Christensen

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 CS@AU Henrik Bærbak Christensen

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 ) CS@AU Henrik Bærbak Christensen

Recommended for HotCiv Two Simple Models Recommended for HotCiv

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

Henrik Bærbak Christensen In Practice Finally, all features implemented CS@AU Henrik Bærbak Christensen

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 CS@AU Henrik Bærbak Christensen

Continue work on master Refactor architecture to support BetaTown CS@AU Henrik Bærbak Christensen

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

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! CS@AU Henrik Bærbak Christensen

Henrik Bærbak Christensen Simple Release Model B Major Release Branches Each major release give rise to new branch CS@AU Henrik Bærbak Christensen

Henrik Bærbak Christensen In Practice Working on ‘master’, close to release CS@AU Henrik Bærbak Christensen

Henrik Bærbak Christensen In Practice Make the final code, commit that CS@AU Henrik Bærbak Christensen

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

Continue work on master Refactor architecture to support BetaTown CS@AU Henrik Bærbak Christensen

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! CS@AU Henrik Bærbak Christensen

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 CS@AU Henrik Bærbak Christensen

… 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  CS@AU Henrik Bærbak Christensen

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 CS@AU Henrik Bærbak Christensen

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… CS@AU Henrik Bærbak Christensen

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’ CS@AU Henrik Bærbak Christensen

Henrik Bærbak Christensen Examples Future reference for (very) large scale development http://nvie.com/posts/a-successful-git-branching-model/ CS@AU Henrik Bærbak Christensen

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 CS@AU Henrik Bærbak Christensen