-
Notifications
You must be signed in to change notification settings - Fork 3
Automated Build Process
Percussion maintains a Jenkins server that is responsible for performing automated builds of the open projects on GitHub.
There are two primary branches involved in the build process:
- development
- master
The development branch contains the latest experimental code, including any merged pull requests from project contributors. This build is run based on an hourly poll of the Git repository for changes on the development branch. As part of the build, unit tests are run and failures fail the build, emailing the contributors. This branch can also be considered to be the integration branch for the project.
The master branch contains the latest stable code, auto-merged from the development branch after a successful integration build and test execution of the development branch code. Code from the development branch is only promoted to the master branch when all unit and integration tests pass on the development branch.
There are 3 jobs responsible for the build automation:
- Development Continuous Integration (CI) (development)
- Nightly Integration (development -> master)
- Daily Snapshot (master)
The overall build flow looks like this:
Development CI -> Nightly Integration -> Daily Snapshot
Any failures, like unit test failures for example, stop the build flow from continuing. Integration tests always run against the latest version of CM System.
Build artifacts, e.g. the download packages, for the project are created from the Daily Snapshot on the master branch. If the build fails for any reason, the prior days snapshot will remain published to the download area.
The last successful snapshot for this project is uploaded to:
http://cdn.percussion.com/downloads/open/psotoolkit/PSOToolkit-7.x-SNAPSHOT.zip
SNAPSHOT releases are considered stable for the current release of CM System.
There is an additional set of branches for the project assigned to each major release of CM System that the project supports. These Release branches were created at the time the Product was released and in many cases were included in some part of Percussion's internal QA process for the release. These are the 'official' release of a project - specifically tested with the version of CM System at time the CM System version was released.
For example the following branches were created and tested specifically for the 7.3.0, 7.0 and 6.7 releases.
- rel-cms73
- rel-cms7
- rel-cms67
The Release build job handles the build for a given release branch. In general new code and bug fixes are not back ported to release branches, however the branching strategy makes that possible to handle an urgent requirement or bug fix in the scenario where someone can't upgrade to the current release.
SNAPSHOT and Release builds are revision controlled by Tags in the Git repository with a unique build id that is based on the date and time that the build was run. For example: a Tag of SNAPSHOT_2013-08-22_23-59-59 would indicate a Snapshot build that was generated on August 22, 2013.
The individual project artifacts will also be stamped with this tag in the projects MANIFEST.MF file. This will allow for the version to be detected both in code and visually by looking at the Manifest for a given jar.
A manifest entry with: RELEASE_2013-08-22_23-59-59 would indicate a release build.