This page describes how release engineering is currently performed for Commons REST (CREST) and the OpenDJ LDAP SDK. Both projects are multi-module Maven projects. Since they are components of other projects it is important that both of them are maintained regularly and released frequently. Therefore, the release engineering process must be as simple and lightweight as possible.
This page is not a guide nor a "best practices": it is just a description of what we are doing currently and any feedback on how we can improve the process is more than welcome. The main purpose is to share the knowledge and hopefully save some time for other projects.
Ok, let's get started...
NOTE: I'm assuming that many of the concepts below will apply equally to Git when we migrate.
Many of the tools discussed below are "convention" based and therefore work much better if your Subversion repository conforms to the standard project layout convention of trunk/branches/tags. Deviate at your own risk! Let's look at these in more detail:
Example SVN: https://svn.forgerock.org/commons/forgerock-rest/trunk
Example pom version: 2.1.0-SNAPSHOT
Description: this is where the next "dot zero" version of the project is being developed. I think we all know that, so no more details required. Projects should never be released from the trunk. Instead, a branch should be created first and the release performed from the branch.
Maven versioning: the version assigned to the trunk (via the various pom.xml files) is of the form "x.y.0-SNAPSHOT", where "x.y" is greater than the most recent branch.
Jenkins: we only have a single "post commit" job for the trunk, which is triggered periodically, or when dependencies are updated, or when changes are committed. Release engineering is disabled for this job.
Example SVN: https://svn.forgerock.org/commons/forgerock-rest/branches/2.0
Example pom version: 2.0.2-SNAPSHOT
Description: this where existing versions of the project are maintained and prepared for release. Typically changes are cherry picked from the trunk and back-ported to the appropriate branch(es). New versions of the project are always released from a branch, and never the trunk. In particular, a "dot-zero" release developed on the trunk, is first branched, and then released.
Maven versioning: the version assigned to a branch is of the form "x.y.z-SNAPSHOT" where "x.y" is older than the trunk version, and "z" is more recent than the most recent tag associated with the branch.
Jenkins: we have two jobs per branch. The first is a "post commit" job, identical to the trunk "post commit" job and differing only in the Subversion checkout URL which refers to the branch instead of the trunk. The second job is the job which will be used for performing release engineering. It has a very different configuration compared to the post commit jobs. More on that below...
Example SVN: https://svn.forgerock.org/commons/forgerock-rest/tags/2.0.1
Example pom version: 2.0.1
Description: this is where released versions of the project are located. Although not enforced, tags should be considered read-only and, therefore, should never be updated once they have been created. A released product is built from its tag and deployed to our Maven repository (Artifactory). If a release fails for some reason, the tag should be rolled back (i.e. deleted) - a tedious process which should rarely occur because the project should have already been stabilized on the branch.
Maven versioning: the version assigned to a tag is of the form "x.y.z" where "x.y.z" is older than the associated branch version. In addition, a released project MUST NOT have any dependencies on unreleased (SNAPSHOT) components.
Jenkins: we do not have any jobs for building tags. Typically a tag is built once while performing a release from a branch.
Configuring Maven for branching and releasing
Creating project branches
Configuring Jenkins jobs for release engineering
Artifactory release plugin or M2 release plugin?
Releasing a project using Jenkins