General Release Process

Preparation for Release or Deploy

1. Ensure that maven has access to
   • Git
     • If you are working on the asl cluster, ensure your kerberos ticket is still valid (so your session is not older than ~10h) use the commands
       • klist to show your current ticket
       • kdestroy to delete your current ticket (if the expiration time is very soon or already in the past)
       • kinit to create a new ticket (requires cluster acoount password)
   • nexus (see also Maven and Eclipse)
   • site location (look up your access rights for locations configured in pom properties <docu.url.snapshot> and <docu.url.release> or ensure <maven.site.skip> is set to true)
2. Synchronise your project with Git (Refresh and execute Team -> Fetch from Upstream)
   • Handle upstream changes by using Team -> Pull and merging them
3. Fix pom
   • Fix parent version
   • Fix infos in pom (compare with the template pom)
   • Check if dependencies are really needed
   • Fix dependency versions (run command mvn versions:display-property-updates versions:display-plugin-updates versions:display-parent-updates versions:display-dependency-updates)
4. Clean code (no clean up and format for CERN artifacts!)
   
   • Ensure you have eclipse configured as described here
   • Right click on your project -> Source -> Clean Up...
     • choose the CSCOAP Profile
   • Right click on your project -> Source -> Format
   • Run command "mvn clean site" and look at the Checkstyle, Spotbugs, PMD and CPD reports -> the fewer reports the better your code (open website target/site/index.html)
5. Run command "mvn clean verify"
   • Fix errors if necessary
   • Fix Javadoc if necessary
6. Test your code
   • Run your application (using the provided start script in target/bin/)
   • Open all UIs
   • Call at least each function you have changed
   • ...
7. Commit and push to Git

How to Snapshot-Deploy

A snapshot deploy can be done multiple times per version.

1. Ensure the version in the pom file has the suffix "-SNAPSHOT" (e.g. version number is 1.0.0-SNAPSHOT)
2. Optionally but recommended: go through Preparation steps
3. Run command "mvn clean deploy"

How to Release

1. Go through Preparation steps
2. If you release from command line it's recommended to close eclipse, disable eclipse' autobuild (Project -> Build Automatically) or close the project in eclipse. Otherwise eclipse might clear the project target folder while maven is using the compiled resources and will fail at this point.
3. Run command (please update the versions given in this example to the one of your project)

   mvn --batch-mode release:prepare release:perform -DreleaseVersion=13.0.0 -DdevelopmentVersion=13.0.1-SNAPSHOT

4. If you are doing a hotfix release where the major version does not change (leftmost number) you can just run:
   

   mvn release:prepare release:perform

Recover from errors

• To recover the project after a failed release attempt you have to call mvn release:rollback release:clean. This will also remove the temporary file release.properties that you might see in this situation.

Rollout of Services and Applications:

The general workflow is (also explained before on this page):

CLEAN -> COMPILE -> VERIFY -> INSTALL -> DEPLOY/RELEASE-> ROLLOUT

In Git there is a repository containing the rollout script: https://git.acc.gsi.de/fcc-applications/common-scripts/

This script (rollout) should be installed in the group directory (/common/usr/cscoap/bin) on all environments (development, integration and production).

If the script is installed rolling out an artifact is easy. The only precondition is, that the artifact was built using the 'csco-parent-java-bundle' as a parent.
This will create a ZIP file with all dependencies for this product during the deploy phase, and this ZIP file is used for the ROLLOUT.

The syntax for the rollout script is as follows:

$ rollout -h
usage: rollout [-h] [--repo REPO] [--dest DEST_DIR] [--yes] [--not-current] g:a:v
Rollout Script - This script is used to download artifacts from the central
repository. The contents will be extracted to a directory on disk were the
user expects the files to be located.
positional arguments:
g:a:v group, artifact and version to rollout e.g. de.gsi.cs.co.ap:feedback:0.0.2
optional arguments:
-h, --help show this help message and exit
--repo REPO the repository to use e.g. csco, csco-snapshot. Defaults to "csco"
--dest DEST_DIR The directory were the files are extracted to. Defaults to "/common/usr/cscoap/htdocs/applications"
--yes If specified all questions are answered with "yes"
--not-current If specified the "current" symlink is not updated.

Make sure you're logged on to the environment you want to perform the rollout to (asl3xx for production, vmla006 for integration and asl7xx for development)!

A usage example for an application 'parammodi-app' would look like this:

rollout de.gsi.fcc.applications:parammodi-app:16.0.0

Serivces (like the LSA Server) should be deployed into the 'opt' directory of your group and can be deployed like this:

rollout de.gsi.lsa.core:lsa-server-gsi:16.0.0 --dest /common/usr/cscoap/opt

To start a service you have to provide the environment to starting it against. At the moment there are the options --dev, --int and --pro.
If you want to start a service in the production environment it would look like this:

/common/usr/cscoap/opt/lsa-server-gsi/current/bin/lsa-server-gsi.sh --pro

An example for rolling out a Snapshot Version for testing purposes (e.g. being logged in to development cluster):

rollout de.gsi.fcc.applications:parammodi-app:16.0.0-SNAPSHOT --repo csco-snapshot