h1. Requirements
* A linux operating system (tested on Ubuntu only) with a bash shell
* subversion package installed : *sudo apt-get install subversion*
* maven package installed
* xmlstarlet package installed : *sudo apt-get install xmlstarlet*
* proper permissions should be set in maven .m2/settings.xml so that local user can deploy artifacts on [http://artifactory.petalslink.com/public] (server id : ebmws-public.release)
h1. {color:#492562}{*}Release steps{*}{color}
This section describes the main steps of the release process script :
* Checkout svn copy of the project structure to release (for exemple svn trunk directory)
* Extract dependencies of the project to release
* Starting from the upper dependency, ask user for release info (need release?, release version?, next dev version?, etc.). SVN changes and previously released dependencies information is provided to help user during this step.
* Once all information is collected, an automatic release process is launched. For all project dependencies, starting from the upper dependency, execute a concrete release:
** Updates pom dependencies according to provided release info (using release version)
** Execute a maven:prepare command (see [http://maven.apache.org/plugins/maven-release-plugin/examples/prepare-release.html|http://maven.apache.org/plugins/maven-release-plugin/examples/prepare-release.html] for more information about this step)
** Execute a maven:perform command (see [http://maven.apache.org/plugins/maven-release-plugin/examples/perform-release.html|http://maven.apache.org/plugins/maven-release-plugin/examples/perform-release.html] for more information about this step)
** Updates pom dependencies according to provided release info (using next dev version)
* The project and all its dependencies are released. Fix all poms to ensure that all internal dependencies are aligned on trunk version.
* Ask for the creation of "meta-tag" (copy of the checkouted svn directory in its state after the release process). This "meta-tag" is useful for maintenance purposes.
h1. Usage
* Choose the appropriate moment : jenkins CI must be all green for all projects to be released.
* Inform all developers that a release will be launched soon. No commit allowed during release process (if possible, block the commit to the other SVN users).
* Check that you have a copy of all release bash scripts located into : [https://svn.petalslink.org/svnroot/trunk/infra/tools/release/|https://svn.petalslink.org/svnroot/trunk/infra/tools/release/] (all release scripts need to be located into the same folder)
* Launch the release script : *release.sh* *{_}PROJECT_NAMES{_}* *{_}URL_CHECKOUT{_}{*}* *
** *{_}PROJECT_NAMES{_}* : the list of all project names to release, separeted by ",". Project name pattern : *groupID:artefactId*. Exemple : org.ow2.petals:petals-enterprise
** *{_}URL_CHECKOUT{_}* : URL of the svn basedir to checkout. This basedir need to included the projects to release and all its internal dependencies (also released during release process). Release will be performed on this checkouted directory. The checkouted sources will be placed into a subfolder of the folder from which you launch the release process, called "RELEASE_CHECKOUT".
** Answer the questions about release info (the first part of the release process)
* Once the release is performed, you could find released artifacts into petalslink maven repository. More, a subdirectory of the "RELEASE_CHECKOUT" directory, called "release", is created during this process and contains useful release information (global release changelog, released modules, release log).
* Enjoy \:-)
h1. In case of failure
If the script fails in the course of the release process,
* before beginning the automatic release process itself (that is to say during the checkout, the dependencies extraction or the questions to the user about release info),
** just delete the local checkout directory (it is called RELEASE_CHECKOUT)
* after beginning the automatic release process itself,
** change the current directory to the directory of the project which fails (in the local checkout directory)
** if release failed at perform time (prepare worked), remove by hand created svn tag.
** remove target dir
** launch the rollback of the release (*mvn release:rollback*) => POM should be reverted.
** correct the failure
** return to the release directory and resume (*release.sh resume*).
* A linux operating system (tested on Ubuntu only) with a bash shell
* subversion package installed : *sudo apt-get install subversion*
* maven package installed
* xmlstarlet package installed : *sudo apt-get install xmlstarlet*
* proper permissions should be set in maven .m2/settings.xml so that local user can deploy artifacts on [http://artifactory.petalslink.com/public] (server id : ebmws-public.release)
h1. {color:#492562}{*}Release steps{*}{color}
This section describes the main steps of the release process script :
* Checkout svn copy of the project structure to release (for exemple svn trunk directory)
* Extract dependencies of the project to release
* Starting from the upper dependency, ask user for release info (need release?, release version?, next dev version?, etc.). SVN changes and previously released dependencies information is provided to help user during this step.
* Once all information is collected, an automatic release process is launched. For all project dependencies, starting from the upper dependency, execute a concrete release:
** Updates pom dependencies according to provided release info (using release version)
** Execute a maven:prepare command (see [http://maven.apache.org/plugins/maven-release-plugin/examples/prepare-release.html|http://maven.apache.org/plugins/maven-release-plugin/examples/prepare-release.html] for more information about this step)
** Execute a maven:perform command (see [http://maven.apache.org/plugins/maven-release-plugin/examples/perform-release.html|http://maven.apache.org/plugins/maven-release-plugin/examples/perform-release.html] for more information about this step)
** Updates pom dependencies according to provided release info (using next dev version)
* The project and all its dependencies are released. Fix all poms to ensure that all internal dependencies are aligned on trunk version.
* Ask for the creation of "meta-tag" (copy of the checkouted svn directory in its state after the release process). This "meta-tag" is useful for maintenance purposes.
h1. Usage
* Choose the appropriate moment : jenkins CI must be all green for all projects to be released.
* Inform all developers that a release will be launched soon. No commit allowed during release process (if possible, block the commit to the other SVN users).
* Check that you have a copy of all release bash scripts located into : [https://svn.petalslink.org/svnroot/trunk/infra/tools/release/|https://svn.petalslink.org/svnroot/trunk/infra/tools/release/] (all release scripts need to be located into the same folder)
* Launch the release script : *release.sh* *{_}PROJECT_NAMES{_}* *{_}URL_CHECKOUT{_}{*}* *
** *{_}PROJECT_NAMES{_}* : the list of all project names to release, separeted by ",". Project name pattern : *groupID:artefactId*. Exemple : org.ow2.petals:petals-enterprise
** *{_}URL_CHECKOUT{_}* : URL of the svn basedir to checkout. This basedir need to included the projects to release and all its internal dependencies (also released during release process). Release will be performed on this checkouted directory. The checkouted sources will be placed into a subfolder of the folder from which you launch the release process, called "RELEASE_CHECKOUT".
** Answer the questions about release info (the first part of the release process)
* Once the release is performed, you could find released artifacts into petalslink maven repository. More, a subdirectory of the "RELEASE_CHECKOUT" directory, called "release", is created during this process and contains useful release information (global release changelog, released modules, release log).
* Enjoy \:-)
h1. In case of failure
If the script fails in the course of the release process,
* before beginning the automatic release process itself (that is to say during the checkout, the dependencies extraction or the questions to the user about release info),
** just delete the local checkout directory (it is called RELEASE_CHECKOUT)
* after beginning the automatic release process itself,
** change the current directory to the directory of the project which fails (in the local checkout directory)
** if release failed at perform time (prepare worked), remove by hand created svn tag.
** remove target dir
** launch the rollback of the release (*mvn release:rollback*) => POM should be reverted.
** correct the failure
** return to the release directory and resume (*release.sh resume*).