The MAIN branch is junction between development and RELEASE branches. Changes in the MAIN branch will FI into every DEVELOPMENT branch, so it is critical that builds from MAIN remain high quality. At minimum this means MAIN must remain buildable and pass all build verification tests
Attributes of MAIN
- Main should build daily to give the team a daily cadence to work toward.
- Every branch should have a natural merge (RI) path back to MAIN (i.e. no baseless merges).
- Breaks in MAIN need to be fixed immediately.
- No direct check-ins to MAIN branch; only build and BVT fixes.
- Successful MAIN build indicates child DEVELOPMENT branches should FI from MAIN.
- QA teams should be able to pick up any MAIN build for testing.
Code flow, the movement of changes between child and parent branches, is a concept all team members must consider. As the number of DEVELOPMENT branches increases the need to FI each successful MAIN build increases. Any DEVELOPMENT branch that is more than a couple days out of sync with MAIN is effectively working in the past.
About versioning…
One strategy to keep track, at a glance, of how far out of sync a DEVELOPMENT branch is from MAIN is to increment the build number in MAIN only. When DEVELOPMENT branches FI from MAIN they get the latest version resource from MAIN. If MAIN builds daily then the build number would increment each day.
Example:
MAIN build 1.0.27.0
Dev_team1 build 1.0.25.0
The Dev_team1 branch has not FI’d MAIN in 2 days if MAIN builds daily.
Teams that adopt this strategy will frequently append a date time stamp to the build number to prevent overwriting builds on the release share and provide clearer reporting since the dev builds may keep the same build number for a few days.
All I need is MAIN…
Some teams are small enough that only one branch, MAIN, is needed. This is great but almost always short-lived. Eventually individuals or teams will need some sort of isolation to work on next version work, complicated bug fixes or breaking changes.
If you do not create a specific place for development work, developers will create their own. The danger here is that the ad-hoc branch created by the developer may not have a natural branch path back to MAIN.
Since these situations are inevitable it is best to have the development branch plan ready when needed.
If ever you need advice on when to branch, think of this:
Create a new branch when the check-in policy is so restrictive you can’t do work.
This means when the check in policy of your main branch is to take version 1.0 changes only and you have a version 1.1 changes then that would be a good signal to create a child branch of main for your 1.1 work.
Attributes of MAIN
- Main should build daily to give the team a daily cadence to work toward.
- Every branch should have a natural merge (RI) path back to MAIN (i.e. no baseless merges).
- Breaks in MAIN need to be fixed immediately.
- No direct check-ins to MAIN branch; only build and BVT fixes.
- Successful MAIN build indicates child DEVELOPMENT branches should FI from MAIN.
- QA teams should be able to pick up any MAIN build for testing.
Code flow, the movement of changes between child and parent branches, is a concept all team members must consider. As the number of DEVELOPMENT branches increases the need to FI each successful MAIN build increases. Any DEVELOPMENT branch that is more than a couple days out of sync with MAIN is effectively working in the past.
About versioning…
One strategy to keep track, at a glance, of how far out of sync a DEVELOPMENT branch is from MAIN is to increment the build number in MAIN only. When DEVELOPMENT branches FI from MAIN they get the latest version resource from MAIN. If MAIN builds daily then the build number would increment each day.
Example:
MAIN build 1.0.27.0
Dev_team1 build 1.0.25.0
The Dev_team1 branch has not FI’d MAIN in 2 days if MAIN builds daily.
Teams that adopt this strategy will frequently append a date time stamp to the build number to prevent overwriting builds on the release share and provide clearer reporting since the dev builds may keep the same build number for a few days.
All I need is MAIN…
Some teams are small enough that only one branch, MAIN, is needed. This is great but almost always short-lived. Eventually individuals or teams will need some sort of isolation to work on next version work, complicated bug fixes or breaking changes.
If you do not create a specific place for development work, developers will create their own. The danger here is that the ad-hoc branch created by the developer may not have a natural branch path back to MAIN.
Since these situations are inevitable it is best to have the development branch plan ready when needed.
If ever you need advice on when to branch, think of this:
Create a new branch when the check-in policy is so restrictive you can’t do work.
This means when the check in policy of your main branch is to take version 1.0 changes only and you have a version 1.1 changes then that would be a good signal to create a child branch of main for your 1.1 work.
|
|
0 comments
Post a Comment