Effective Release Management and Branching Models in Software Engineering
S
o
f
t
w
a
r
e
E
n
g
i
n
e
e
r
i
n
g
a
n
d
A
r
c
h
i
t
e
c
t
u
r
e
Release Management &
Branching Models
B
r
a
n
c
h
i
n
g
CS@AU
Henrik Bærbak Christensen
2
G
i
t
b
r
a
n
c
h
e
s
•
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
S
o
f
t
w
a
r
e
i
s
a
L
a
b
!
•
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!
Merge that branch into main
–
It was a bad idea!!!
Orphan the branch
CS@AU
Henrik Bærbak Christensen
4
R
e
l
e
a
s
e
M
a
n
a
g
e
m
e
n
t
•
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
5
N
o
t
a
l
l
v
e
r
s
i
o
n
s
a
r
e
e
q
u
a
l
•
S
o
m
e
v
e
r
s
i
o
n
s
a
t
t
a
i
n
a
s
p
e
c
i
a
l
m
e
a
n
i
n
g
:
R
e
l
e
a
s
e
•
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
–
M
a
k
e
a
‘
r
e
l
e
a
s
e
b
r
a
n
c
h
’
(
s
i
n
g
l
e
r
e
l
e
a
s
e
b
r
a
n
c
h
m
o
d
e
l
)
•
Branch and name the new branch ‘Release-AlphaTown-V1.7.4’
–
M
e
r
g
e
i
n
t
o
a
‘
r
e
l
e
a
s
e
b
r
a
n
c
h
’
a
n
d
t
a
g
i
t
(
m
a
j
o
r
r
e
l
e
a
s
e
b
r
a
n
c
h
e
s
m
o
d
e
l
)
•
Merge current version into global release branch and tag it
CS@AU
Henrik Bærbak Christensen
6
(
S
i
d
e
N
o
t
e
)
•
Some of you have in a previous course handed in
mandatories using Git but made
one folder pr hand-in
?
–
I.e. ‘releases’ of the mandatory project
•
T
h
i
s
i
s
n
o
t
t
h
e
s
o
f
t
w
a
r
e
d
e
v
w
a
y
!
–
This is a 1990’es manual hack in the absence
of a version control system
•
SWEA: We use Git to do release
management
CS@AU
Henrik Bærbak Christensen
7
T
w
o
R
e
l
e
a
s
e
M
a
n
a
g
e
m
e
n
t
M
o
d
e
l
s
•
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 Branch
es
Next+1 slide
–
New release => Create
new
branch
–
Pro: Naming the releases by the branch name
•
Used in SWEA up until E2020…
CS@AU
Henrik Bærbak Christensen
8
S
i
m
p
l
e
R
e
l
e
a
s
e
M
o
d
e
l
A
•
Single Release Branch
–
Hotfixing must be done
on separate branch
–
And merged back
CS@AU
Henrik Bærbak Christensen
9
S
i
m
p
l
e
R
e
l
e
a
s
e
M
o
d
e
l
B
•
Major Release Branches
–
Each major release give
rise to new branch
CS@AU
Henrik Bærbak Christensen
10
C
o
n
t
i
n
u
o
u
s
D
e
p
l
o
y
m
e
n
t
•
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
–
Web systems are
continuously
updated…
•
CD = You
continuously
get the latest release
–
Releasing every couple of hours! Done by machines…
CS@AU
Henrik Bærbak Christensen
11
C
D
R
e
l
e
a
s
e
M
a
n
a
g
e
m
e
n
t
•
CD streamlines release management!
–
‘main’ is the release branch!
•
Daily work done on
feature branches
–
When feature/iteration is ‘working’…
•
Tests pass, requirements complete
–
… you merge back into master
•
G
i
t
H
u
b
F
l
o
w
–
[https://docs.github.com/en/get-started/quickstart/github-flow]
–
N
o
t
e
:
T
h
i
s
r
e
l
e
a
s
e
m
a
n
a
g
e
m
e
n
t
m
o
d
e
l
i
s
n
o
t
t
i
e
d
t
o
G
i
t
H
u
b
!
CS@AU
Henrik Bærbak Christensen
12
main
S
W
E
A
R
e
l
a
t
i
o
n
•
In the SWEA mandatory project…
•
Y
o
u
s
h
o
u
l
d
c
r
e
a
t
e
a
n
‘
i
t
e
r
a
t
i
o
n
b
r
a
n
c
h
’
t
h
a
t
h
o
l
d
s
t
h
e
d
e
v
e
l
o
p
m
e
n
t
i
n
t
h
e
g
i
v
e
n
i
t
e
r
a
t
i
o
n
/
d
e
l
i
v
e
r
y
•
Like branch ‘iteration3’ =
–
Work on the requirements for mandatory ‘iteration 3’
•
Contains ‘work in progress’ code, not suitable for customers
–
B
u
t
‘
m
a
i
n
’
b
r
a
n
c
h
c
a
n
a
l
w
a
y
s
b
e
r
e
l
e
a
s
e
d
•
B
e
c
a
u
s
e
i
t
i
s
c
o
r
r
e
c
t
,
w
o
r
k
i
n
g
,
w
i
t
h
o
u
t
b
u
g
s
…
CS@AU
Henrik Bærbak Christensen
13
G
i
t
H
u
b
F
l
o
w
In Practice
O
v
e
r
v
i
e
w
CS@AU
Henrik Bærbak Christensen
15
Iteration 3
main
1. Tell Git to create branch
O
v
e
r
v
i
e
w
CS@AU
Henrik Bærbak Christensen
16
Iteration 3
main
2. Associate ‘Merge Request’
with the branch
O
v
e
r
v
i
e
w
CS@AU
Henrik Bærbak Christensen
17
Iteration 3
main
3. Develop on that branch,
commit often
O
v
e
r
v
i
e
w
CS@AU
Henrik Bærbak Christensen
18
Iteration 3
main
4. Release: Merge back into
main branch
S
t
a
r
t
i
n
g
I
t
e
r
a
t
i
o
n
W
o
r
k
•
Let us start on the exciting mandatory 3 – hurrah!
•
Tell GitLab about the branch – Link will be provided
CS@AU
Henrik Bærbak Christensen
19
M
e
r
g
e
R
e
q
u
e
s
t
•
Follow the link that Git provides
•
And fill in the details about
Description,
and ‘Create…’
CS@AU
Henrik Bærbak Christensen
20
Aka:
Pull Request
N
o
w
:
W
o
r
k
•
Do the TDD
–
Do a ‘commit and push’ after each finished TDD iteration
CS@AU
Henrik Bærbak Christensen
21
R
e
l
e
a
s
e
T
i
m
e
•
We find it is time to release
–
That is: this is the best shot at a mandatory hand-in
•
Mark the iteration branch as ‘ready’ in AU GitLab
CS@AU
Henrik Bærbak Christensen
22
A
n
d
m
e
r
g
e
b
a
c
k
t
o
M
a
i
n
CS@AU
Henrik Bærbak Christensen
23
R
e
l
e
a
s
e
T
i
m
e
•
T
h
e
‘
c
o
m
m
a
n
d
l
i
n
e
’
w
a
y
CS@AU
Henrik Bærbak Christensen
24
Or use the - -no-commit, to
‘dryrun’
E
q
u
i
v
a
l
e
n
t
i
n
I
n
t
e
l
l
i
J
CS@AU
Henrik Bærbak Christensen
25
Branch in IntelliJ;
Associate merge
request in GitLab;
WORK
O
v
e
r
t
o
G
i
t
L
a
b
•
And fill in the details as outlined earlier
CS@AU
Henrik Bærbak Christensen
26
M
e
r
g
e
R
e
q
u
e
s
t
/
B
r
a
n
c
h
•
I have shown it here where a merge request is
associated with the ‘iteration 3’ branch.
–
It is a bit overkill in SWEA context to create merge requests, but
•
T
h
e
b
r
a
n
c
h
i
s
i
m
p
o
r
t
a
n
t
–
You may skip the ‘merge request’ thing but working on the
iteration branch is important
•
git checkout –b iteration4
Create branch
•
git commit & git push
Work on branch
•
Git checkout main; git merge iteration4
Merge back to main
CS@AU
Henrik Bærbak Christensen
27
I
n
t
h
e
B
r
a
n
c
h
i
n
g
M
o
d
e
l
•
Release is now present
on the main branch.
•
T
h
e
k
e
y
p
o
i
n
t
:
–
Y
o
u
c
a
n
a
l
w
a
y
s
r
e
l
e
a
s
e
t
h
e
s
o
f
t
w
a
r
e
o
n
t
h
e
m
a
i
n
b
r
a
n
c
h
!
•
CD = Cont. Delivery
–
Every 1 hour, a job
simply copies SW
from master onto
production machines
CS@AU
Henrik Bærbak Christensen
28
Iteration 3
main
S
i
m
p
l
e
E
x
a
m
p
l
e
•
Crontab on ‘baerbak.cs.au.dk’
CS@AU
Henrik Bærbak Christensen
29
S
u
m
m
a
r
y
•
Branching supports the release and development
process
–
Releasing, bugfixing, subteams, feature branches, …
•
Many different models can be made
–
K
e
e
p
i
t
s
i
m
p
l
e
!
E
m
p
h
a
s
i
z
e
e
a
s
e
i
n
d
a
i
l
y
w
o
r
k
!
•
In SWEA we adopt a simple CD model – GitHub Flow
–
Latest working release on ‘main’
–
Do development on an ‘iteration’ branch, use ‘merge requests’
CS@AU
Henrik Bærbak Christensen
30
Explore the importance of release management and branching models in software engineering, with insights on utilizing Git for efficient development processes, managing experimental branches, handling versions and releases effectively. Understand how to navigate through development challenges and streamline your workflow for better code management.
Uploaded on Sep 11, 2024 | 0 Views
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
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!!! Merge that branch into main Orphan the branch CS@AU 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 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 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. Essentially put a human readable label on specific version Make a release branch (single release branch model) Branch and name the new branch Release-AlphaTown-V1.7.4 Merge into a release branch and tag it (major release branches model) Merge current version into global release branch and tag it Git: 4ef678a CS@AU Henrik B rbak Christensen 6
(SideNote) Some of you have in a previous course handed in mandatories using Git but made one folder pr hand-in? I.e. releases of the mandatory project This is not the software dev way! This is a 1990 es manual hack in the absence of a version control system SWEA: We use Git to do release management CS@AU Henrik B rbak Christensen 7
Two Release Management Models Single Release Branch Daily development on master New release => Merge into release branch Pro: Always find release as tip on release branch Next slide Major Release Branches New release => Create new branch Pro: Naming the releases by the branch name Next+1 slide Used in SWEA up until E2020 CS@AU Henrik B rbak Christensen 8
Simple Release Model A Single Release Branch Hotfixing must be done on separate branch And merged back CS@AU Henrik B rbak Christensen 9
Simple Release Model B Major Release Branches Each major release give rise to new branch CS@AU Henrik B rbak Christensen 10
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 Web systems are continuouslyupdated CD = You continuously get the latest release Releasing every couple of hours! Done by machines CS@AU Henrik B rbak Christensen 11
CD Release Management CD streamlines release management! main is the release branch! main Daily work done on feature branches When feature/iteration is working Tests pass, requirements complete you merge back into master GitHub Flow [https://docs.github.com/en/get-started/quickstart/github-flow] Note: This release management model is not tied to GitHub! CS@AU Henrik B rbak Christensen 12
SWEA Relation In the SWEA mandatory project You should create an iteration branch that holds the development in the given iteration / delivery Like branch iteration3 = Work on the requirements for mandatory iteration 3 Contains work in progress code, not suitable for customers But main branch can always be released Because it is correct, working, without bugs CS@AU Henrik B rbak Christensen 13
GitHub Flow In Practice
Overview main 1. Tell Git to create branch Iteration 3 CS@AU Henrik B rbak Christensen 15
Overview main 2. Associate Merge Request with the branch Iteration 3 CS@AU Henrik B rbak Christensen 16
Overview main 3. Develop on that branch, commit often Iteration 3 CS@AU Henrik B rbak Christensen 17
Overview main Iteration 3 4. Release: Merge back into main branch CS@AU Henrik B rbak Christensen 18
Starting Iteration Work Let us start on the exciting mandatory 3 hurrah! Tell GitLab about the branch Link will be provided CS@AU Henrik B rbak Christensen 19
Merge Request Follow the link that Git provides And fill in the details about Description, and Create Aka: Pull Request CS@AU Henrik B rbak Christensen 20
Now: Work Do the TDD Do a commit and push after each finished TDD iteration CS@AU Henrik B rbak Christensen 21
Release Time We find it is time to release That is: this is the best shot at a mandatory hand-in Mark the iteration branch as ready in AU GitLab CS@AU Henrik B rbak Christensen 22
And merge back to Main CS@AU Henrik B rbak Christensen 23
Release Time The commandline way Or use the - -no-commit, to dryrun CS@AU Henrik B rbak Christensen 24
Equivalent in IntelliJ Branch in IntelliJ; Associate merge request in GitLab; WORK CS@AU Henrik B rbak Christensen 25
Over to GitLab And fill in the details as outlined earlier CS@AU Henrik B rbak Christensen 26
Merge Request/Branch I have shown it here where a merge request is associated with the iteration 3 branch. It is a bit overkill in SWEA context to create merge requests, but The branch is important You may skip the merge request thing but working on the iteration branch is important git checkout b iteration4 git commit & git push Git checkout main; git merge iteration4 Create branch Work on branch Merge back to main CS@AU Henrik B rbak Christensen 27
In the Branching Model Release is now present on the main branch. The key point: You can always release the software on the main branch! CD = Cont. Delivery Every 1 hour, a job simply copies SW from master onto production machines main Iteration 3 CS@AU Henrik B rbak Christensen 28
Simple Example Crontab on baerbak.cs.au.dk CS@AU Henrik B rbak Christensen 29
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 GitHub Flow Latest working release on main Do development on an iteration branch, use merge requests CS@AU Henrik B rbak Christensen 30
