E-mail
|
Key
This line was removed.
This word was removed. This word was added.
This line was added.
|
Changes (16)
View Page Historyh1. Requirements
* A linux operating system (tested on Ubuntu only) with a bash shell
* subversion package installed, to be able to retrieve SVN revision set in JAR manifests : *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)
* subversion package installed, to be able to retrieve SVN revision set in JAR manifests : *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)
# Internet connection
# You have an access to the OW2's MRM ([Nexus|http://repository.ow2.org/]), and your account can publish artifacts of the repository 'stagging'.
# Your Maven's setting file is right, containing:
#* MRM declarations,
#* Credential of the OW2's MRM to publish artifacts into the repository 'stagging'
{code}
<server>
<id>ow2.release</id>
<username>petals</username>
<password>......</password>
</server>
<server>
<id>ow2.snapshot</id>
<username>petals</username>
<password>......</password>
</server>
{code}
#* The secret GPG key to sign artifacts
{code}
cdeneux@cdeneux-laptop:~$ gpg --list-secret-keys
/home/cdeneux/.gnupg/secring.gpg
--------------------------------
sec 2048R/09334662 2012-10-08
uid Petals (ESB) <petals-dev@ow2.org>
ssb 2048R/C8353498 2012-10-08
{code}
{tip}If needed, import the secret key [{{secret.key}}|interne:Releaser un projet Petals^secret.key]: {{gpg --import secret.key}}{tip}
#* The credential of the GPG key:
{code}
<profile>
<id>gpg-passphrase</id>
<activation>
<property>
<name>performRelease</name>
<value>true</value>
</property>
</activation>
<properties>
<gpg.passphrase>.............</gpg.passphrase>
</properties>
</profile>
# You have an access to the OW2's MRM ([Nexus|http://repository.ow2.org/]), and your account can publish artifacts of the repository 'stagging'.
# Your Maven's setting file is right, containing:
#* MRM declarations,
#* Credential of the OW2's MRM to publish artifacts into the repository 'stagging'
{code}
<server>
<id>ow2.release</id>
<username>petals</username>
<password>......</password>
</server>
<server>
<id>ow2.snapshot</id>
<username>petals</username>
<password>......</password>
</server>
{code}
#* The secret GPG key to sign artifacts
{code}
cdeneux@cdeneux-laptop:~$ gpg --list-secret-keys
/home/cdeneux/.gnupg/secring.gpg
--------------------------------
sec 2048R/09334662 2012-10-08
uid Petals (ESB) <petals-dev@ow2.org>
ssb 2048R/C8353498 2012-10-08
{code}
{tip}If needed, import the secret key [{{secret.key}}|interne:Releaser un projet Petals^secret.key]: {{gpg --import secret.key}}{tip}
#* The credential of the GPG key:
{code}
<profile>
<id>gpg-passphrase</id>
<activation>
<property>
<name>performRelease</name>
<value>true</value>
</property>
</activation>
<properties>
<gpg.passphrase>.............</gpg.passphrase>
</properties>
</profile>
h1. {color:#492562}{*}Release steps{*}{color}
{code}
This section describes the main steps of the release process script :
h1. Before release
* 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.
* 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.
Before to start the release process, disable the continuous integration to avoid failed build because of artifacts not promote from the repository 'stagging' to the repository 'public'.
In the [Jenkins console script|http://jenkins.petalslink.com/script], execute the following script to disable all jobs:
{code}
import hudson.model.*
In the [Jenkins console script|http://jenkins.petalslink.com/script], execute the following script to disable all jobs:
{code}
import hudson.model.*
h1. Usage
// For each project
for(item in Hudson.instance.items) {
println("JOB : "+item.name)
item.disabled=true
item.save()
println("\n=======\n")
}
{code}
for(item in Hudson.instance.items) {
println("JOB : "+item.name)
item.disabled=true
item.save()
println("\n=======\n")
}
{code}
* 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/product/infra/tools/release/|https://svn.petalslink.org/svnroot/trunk/product/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 \:-)
* 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/product/infra/tools/release/|https://svn.petalslink.org/svnroot/trunk/product/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. Releasing Petals ESB
h1. In case of failure
To release Petals ESB, you will release, if needed, in the following order:
# Petals dev tools,
# Easycommons tools,
# Petals ESB.
# Petals dev tools,
# Easycommons tools,
# Petals ESB.
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*).
* 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*).
h2. Releasing Petals dev tools
For each dev tools:
# prepare the release executing the command:
{code}
> mvn release:prepare
{code}
# perform the release executing the command:
{code}
> mvn release:perform
{code}
During the perform phase, Maven will ask you the PGP's pass-phrase.
Once dev tools are released, go to the [OW2's MRM to promote|http://repository.ow2.org/nexus/index.html#stagingRepositories] the released artifacts into the repository containing released artifacts:
# Select the temporary repository containing artefacts just released,
# and "close" it,
# and "release" it.
h2. Releasing EasyCommons artifacts
h2. Releasing Petals ESB artifacts
h1. After the release
h2. Enable Jenkins's jobs
Now, the continuous integration can be re-enable. In the [Jenkins console script|http://jenkins.petalslink.com/script], execute the following script to enable all jobs:
{code}
import hudson.model.*
// For each project
for(item in Hudson.instance.items) {
println("JOB : "+item.name)
item.disabled=false
item.save()
println("\n=======\n")
}
{code}
h1. Release the documentation
If the released component has a documentation, copy the documentation 'SNAPSHOT' renaming 'SNAPSHOT' by the right version.
h1. Communication
If needed, an announcment will be done on the right channels: Twitter, News on the Petals web-site, ...
For each dev tools:
# prepare the release executing the command:
{code}
> mvn release:prepare
{code}
# perform the release executing the command:
{code}
> mvn release:perform
{code}
During the perform phase, Maven will ask you the PGP's pass-phrase.
Once dev tools are released, go to the [OW2's MRM to promote|http://repository.ow2.org/nexus/index.html#stagingRepositories] the released artifacts into the repository containing released artifacts:
# Select the temporary repository containing artefacts just released,
# and "close" it,
# and "release" it.
h2. Releasing EasyCommons artifacts
h2. Releasing Petals ESB artifacts
h1. After the release
h2. Enable Jenkins's jobs
Now, the continuous integration can be re-enable. In the [Jenkins console script|http://jenkins.petalslink.com/script], execute the following script to enable all jobs:
{code}
import hudson.model.*
// For each project
for(item in Hudson.instance.items) {
println("JOB : "+item.name)
item.disabled=false
item.save()
println("\n=======\n")
}
{code}
h1. Release the documentation
If the released component has a documentation, copy the documentation 'SNAPSHOT' renaming 'SNAPSHOT' by the right version.
h1. Communication
If needed, an announcment will be done on the right channels: Twitter, News on the Petals web-site, ...