Software Engineering and Architecture Release Management Branching Models

Software Engineering and Architecture Release Management & Branching Models

Branching CS@AU Henrik Bærbak Christensen 2

Git branches • Git is really strong in branching support ! – Why? Because it is a powerfull development tool… • Example: feature branch – Arne makes branch ‘add-german’ and change code without interfering with Bente – Bente makes branch ‘fix-bug-21’ and fixes – well – bug #21 • Merge back when done – Or orphan branch if really bad idea… CS@AU Henrik Bærbak Christensen 3

Software is a Lab! • I do a lot of experiments on my code! – I was originally trained as a physicist • Experiment = I think this is a good idea, but do not know? • How do I get ‘to know!’ By doing it! • Make an experimental branch in git – It was a good idea! – It was a bad idea!!! CS@AU Merge that branch into master Orphan the branch Henrik Bærbak Christensen 4

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 Alpha. Town • Rewrite part of the Alpha. Town code to support Beta. Town – (Major refactorings in core Alpha. Town code) – Alpha. Town 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 Alpha. Town has not paid for – What to do? ? ? CS@AU 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. – ‘Tag’ a version on the graph. Git: 4 ef 678 a… • Essentially put a human readable label on specific version – Make a ‘release branch’ (single release branch model) • Branch and name the new branch ‘Release-Alpha. Town-V 1. 7. 4’ – Merge into a ‘release branch’ and tag it (major release branches model) • Merge current version into global release branch and tag it • Releases should always reside on a branch! Why? CS@AU Henrik Bærbak Christensen 6

Two Release Management Models • Single Release Branch Next slide – Daily development on ‘master’ – New release => Merge into ‘release’ branch – Pro: Always find release as tip on release branch • Major Release Branches Next+1 slide – New release => Create new branch – Pro: Naming the releases by the branch name • Used in SWEA up until E 2020… CS@AU Henrik Bærbak Christensen 7

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

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

Continuous Deployment • Release Management is important but… – There is a distinct release process involved – I download the latest release and install • Lots of modern software does not follow that paradigm – You do not download + install facebook – Firefox updates itself • CD = You continuously get the latest release – Releasing every couple of hours! Done by machines… CS@AU Henrik Bærbak Christensen 10

CD Release Management • CD streamlines release management! – ‘master’ is the release branch! • Daily work done on feature branches – When feature/iteration is ‘working’… • Tests pass, requirements complete – … you merge back into master • Git. Hub Flow – [https: //docs. gitlab. com/ee/topics/gitlab_flow. html] CS@AU Henrik Bærbak Christensen 11

SWEA Relation • In the SWEA mandatory project… • You should create an ‘iteration branch’ that holds the development in the given iteration / delivery • Like branch ‘iteration 3’ = – Work on the requirements for mandatory ‘iteration 3’ • Credits: – Pioneered by TA Mikkel J. Juhl from E 19… CS@AU Henrik Bærbak Christensen 12

Git. Hub Flow In Practice

Starting Iteration Work • Let us start on the exciting mandatory 3 – hurrah! • Tell Git. Lab about the branch – WIP = Work In Progress CS@AU Henrik Bærbak Christensen 14

Starting Iteration Work • Let us start on the exciting mandatory 3 – hurrah! • Check the s eenc. Inas. Progress Tell Git. Lab about the branch – WIPc=r. Work ts on the weekp lan CS@AU Henrik Bærbak Christensen 15

Merge Request • Follow the link that Git provides • And fill in the details about Goal, and ‘submit Aka: Pull Request CS@AU Henrik Bærbak Christensen 16

In the Branching Model Iteration 3 CS@AU Henrik Bærbak Christensen 17

Merge Request • Is ‘Open’ = ‘we are working on it’ CS@AU Henrik Bærbak Christensen 18

Daily Grind • Now you work on this branch as you work towards the requirements of the mandatory CS@AU Henrik Bærbak Christensen 19

Branch and Versions CS@AU Henrik Bærbak Christensen 20

Release Time • Green bar and testlist empty – we are done! Release! • The ‘commandline’ way Or use the - -no-commit, to ‘dryrun’ CS@AU Henrik Bærbak Christensen 21

Release Time • Green bar – we are done! • Git. Lab interaction • Hit ‘Merge’ • I like to keep the branch around Uncheck it! CS@AU Henrik Bærbak Christensen 22

Done CS@AU Henrik Bærbak Christensen 23

In the Branching Model • Release is now present on the master branch. • The key point: – You can always release the software on the master branch! • CD = Cont. Delivery Iteration 3 – Every 1 hour, a job simply copies SW from master onto production machines CS@AU Henrik Bærbak Christensen 24

Simple Example • Crontab on ‘baerbak. cs. au. dk’ CS@AU Henrik Bærbak Christensen 25

TA Workflow If they desire…

TA Workflow CS@AU Henrik Bærbak Christensen 27

Selects your MR • And can comment on a line basis in your code CS@AU Henrik Bærbak Christensen 28

Pipelines Beyond the curriculum But it is quite nice, so…

Git. Lab CD support • Automated testing is central to CD • Every push to Git. Lab will initiate a virtual machine executing the script in the. gitlab-ci. yml • (Which is not really CD but CI) – CI = Continuous Integration • Integrate latest changes, and validate through automated testing • Screencast of the process – https: //vimeo. com/444850519 CS@AU Henrik Bærbak Christensen 30

Automated Testing CS@AU Henrik Bærbak Christensen 31

And Coupled to your Mail Account • I checked in a few commits in which the test cases failed CS@AU Henrik Bærbak Christensen 32

The Default Pipeline • It does three things – 1) Compiles, 2) run tests, 3) generate Ja. Co test coverage – This pipeline failed in stage 2 – test cases did not pass • Click to get details CS@AU Henrik Bærbak Christensen 33

Details • But – well – you should have that information already, in Intelli. J, right… CS@AU Henrik Bærbak Christensen 34

TA may download the Ja. Co CS@AU Henrik Bærbak Christensen 35

Summary • Branching supports the release and development process – Releasing, bugfixing, subteams, feature branches, … • Many different models can be made – Keep it simple! Emphasize ease in daily work! • In SWEA we adopt a simple CD model – Git. Hub Flow – Latest working release on ‘master’ – Do development on an ‘iteration’ branch, use ‘merge requests’ CS@AU Henrik Bærbak Christensen 36