Difference between revisions of "Release process"
| Line 16: | Line 16: | ||
Java Guidelines - Branching Strategy describes how development branches (a.k.a feature branches) are used. However, in order to support continuity (see introduction), a new class of branches is introduced: release branches. The picture below shows how they work: | Java Guidelines - Branching Strategy describes how development branches (a.k.a feature branches) are used. However, in order to support continuity (see introduction), a new class of branches is introduced: release branches. The picture below shows how they work: | ||
| − | [ | + | [[File:Branches.Png]] |
The blue branch is a development branch. The red branch is a release branch. | The blue branch is a development branch. The red branch is a release branch. | ||
| Line 41: | Line 41: | ||
The picture above shows the version numbers used on branch and tags names (large fonts) as well as the pom files (small fonts). | The picture above shows the version numbers used on branch and tags names (large fonts) as well as the pom files (small fonts). | ||
Release script | Release script | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Build and deploy | Build and deploy | ||
| Line 70: | Line 48: | ||
Overall test/release cycle | Overall test/release cycle | ||
| − | [ | + | [[File:Process.Png]] |
The picture above shows the overall release process. This can also be described as follows (steps 1-3 are not part of the picture above): | The picture above shows the overall release process. This can also be described as follows (steps 1-3 are not part of the picture above): | ||
Revision as of 11:52, 16 February 2014
Introduction
When releasing a new version of a component, certain things need to be in order:
- Content: the content is known
- Stability: version 1.1.1 stays 1.1.1 over time (only one 1.1.1 version)
- Continuity: work doesn't stop on the component during the test/release phases
The process described here should take the points above into account. Configuration management Release branches
Most of the work done in order to make a release happens in our source control system: Subversion.
Java Guidelines - Branching Strategy describes how development branches (a.k.a feature branches) are used. However, in order to support continuity (see introduction), a new class of branches is introduced: release branches. The picture below shows how they work:
The blue branch is a development branch. The red branch is a release branch.
All release branches are made from trunk. All releases (tags) are made from release branches. Bug fixing are done on release branches and the changes must be merged back to trunk. New bug fix releases are made from release branches.
Only when new features are introduced in the component a new release branch should be made.
All changes made to trunk (merges) should be reviewed. Version numbering
All component version numbers should be formatted like:
x.y.z, where:
x = major version. Increased if major changes are introduced.
y = minor version. Increased if minor changes are introduced.
z = build version. Increased with every release from a given release branch.
NB! for trunk, z is always 0.
The picture above shows the version numbers used on branch and tags names (large fonts) as well as the pom files (small fonts). Release script
Build and deploy
See Build and Deployment Process Overall test/release cycle
The picture above shows the overall release process. This can also be described as follows (steps 1-3 are not part of the picture above):
- Do work on a component on a development branch
- Merge to trunk
- Make a release branch
- Make a release (tag) and build it using Hudson
- Deploy on a test environment
- Perform test
- If an error is found, fix it on release branch, merge to trunk and repeat steps 4-6.
- No errors are found. Continue on QA and prod.
- If an error is found, repeat steps 4-8.
