Transcript MULTI-QA BRANCHED DEVELOPMENT Using Git By Jon Messer & Tariq Ahmed http://www.amcomtech.net PROBLEM DEFINITION  Current source code methodology and tooling uses a linear approach. Big changes can jam.

MULTI-QA BRANCHED
DEVELOPMENT
Using Git
By Jon Messer & Tariq Ahmed
http://www.amcomtech.net
PROBLEM DEFINITION

Current source code methodology and tooling uses
a linear approach.
Big changes can jam up QA for a long time.
 QA difficult to know what’s being tested when multiple
changes are in QA.
 Forced to “leap frog” emergency/hotfix changes, which
is high risk.

Dev

QA
Staging
Solution:
Test changes independently.
 Have flexibility to control what is being tested at any
given time.

WHAT WE NEED TO DO – SYSTEM WISE
Dev spins off
feature branch
Release branch xyz
spun off and
staged for release
QA1
RTB
Dev
QA2
Integration
PreProd
Release xyz
released by Rel
Mgr.
QA3
Rel Mgr approves
& designates QA
Env per project
Status: QA Testing
Set QA Env
Prod
Dev merges to integration branch.
Status: Integration Testing
How it works:
• You develop off your own/team feature branch.
• You then move the feature branch into a targeted QA environment as designated by the Release Manager.
• When verified, changes would merge into an integration branch for testing changes together as a build.
•Testing would be done in the Integration environment.
•After integration testing, the build/release is staged and deployed.
BASIC PROJECT BRANCH LIFE CYCLE
branch merge or create
In Progress = Development
Released
v457
Master
Code
Verified Reviewed
Resolved
Minor Fix
Staging/Pre-Prod
Integration now
locked to just
planned
branches
REL-457
Minor Fix
rare fixes need to
merge back down
new release
branch
Integration
merge back in
Integration
Testing
new branch
PRJ-9232
Integration now
open to next
group of changes
Branch no longer
needed
In Progress
merge to
master
QA Testing
QA Env
TBD by Rel Mgr
time
INTEGRATION TESTING OF MULTIPLE PROJECTS
Released
v457
Master
Resolved
Code
Verified Reviewed
merge to
master
REL-457
Staging/Pre-Prod
new release
branch
Integration
PRJ-9232
new branch
In Progress
merge
Integration
Testing
QA Testing
PRJ-9987
In Progress
QA Testing
time
ensure any changes
merge back down
HANDLING MAJOR ISSUES



Project branch remains open until moved to a staging/release branch.
If a major issue is encountered, changes can be worked on the project branch
and merged back into integration.
Or if the release deadline is looming, that project is backed out of integration.
v457
v458
Master
still issues - back out 9232 so that
release can move fwd
Staging/Pre-Prod
REL-457
REL-458
good to go
Integration
Issues
w/9232
PRJ-9232
In Progress
QA Testing
major fix
PRJ-9987
In Progress
QA Testing
time
now aiming for
next release
project branches stay open until
changes are spun off on a release
branch
WORKING WITH RTB CHANGES


Multiple RTB (run the business, point releases) changes will
co-exist.
An RTB branch is used to group these together so that they
can move as a whole to an QA RTB environment.
v457
Master
REL-457
Staging/Pre-Prod
ensure any changes
merge back down
Integration
new one created as soon as the
previous RTB branch is released
RTB
QA Testing
RTB-1234
RTB-4567
In Progress
In Progress
time
MULTI-DEVELOPER PROJECTS

For large multi-developer projects a similar technique to
the RTB approach is used.
v457
Master
REL-457
Staging/Pre-Prod
ensure any changes
merge back down
Integration
minor fix
PRJ- {Title}
QA Testing
PRJ-1234
PRJ-4567
In Progress
In Progress
major fix
time
WORKING WITH HOTFIXES

Emergency changes are branched off master, quickly
tested, and then released.
v458
Master
Hotfixes
HF-9766
In Progress
QA Testing
Integration
time
SUMMARY
Using Git, all of these branch operations are cheap
(vs. SVN which are expensive).
 With Git it’s easy to move in and out which branch
is being tested in any given environment.

vs. currently where the (one) QA branch is tied to the
(one) QA environment.
 We have now 3 QA environments, but can test one
branch for a few hours and then test another branch
later... easily...


Master and Integration are the only long lived
branches. Even though you delete the short lived
ones, Git preserves the full history.