In this article I have explained how to do Maven release of IIB projects using Jenkins. Before you go through this article, please look at my another article that explains how to do build and deployment automation of IIB using Maven and Jenkins:
http://anandawasthitech.blogspot.com/2015/10/iib-continuousintegration-maven-jenkins.html
Assuming that you have gone through the article mentioned above, you know how to configure Maven, Jenkins, iib-maven-plugin etc.
Environment:
IBM Integration Bus v9
SVN
CollabNetSubversion-client-1.6.23-1-x64
Maven 3.2.1
Jenkins
nexus repository
What would we achieve at the end of this:
Prepare Release:
- Check that there are no uncommitted changes in the sources
- Check that there are no SNAPSHOT dependencies
- Change the version in the POMs from x-SNAPSHOT to a new version (you will be prompted for the versions to use)
- Transform the SCM information in the POM to include the final destination of the tag
- Run the project tests against the modified POMs to confirm everything is in working order
- Commit the modified POMs
- Tag the code in the SCM with a version name (this will be prompted for)
- Bump the version in the POMs to a new value y-SNAPSHOT (these values will also be prompted for)
- Commit the modified POMs
Perform Release:
- Checkout from an SCM URL with optional tag
- Run the predefined Maven goals to release the project (by default, deploy site-deploy)
So, basically the release will be prepared and performed. To deploy the BAR on the Integration Node/Integration Server, you can write a deployment jenkins job as explained in previous article (link provided above). I have deliberately isolated release job from deployment job to maintain the flexibility of build once and do repeated deployments to various environments as per need.
One more thing worth to note here is the Maven version I have taken here. There is a small bug in Maven 3.3.3. After Maven version 3.2.1, the mvn.bat file has been renamed to bat.cmd; however Maven invoker in version 3.3.3 still looks for bat file. There is workaround for it and this issue has been fixed for upcoming release of maven. To keep things clean, I have used version 3.2.1; however once new version is released, you can switched to that.
Also note that you need to install SVN client on the Jenkins server. I have used CollabNetSubversion-client-1.6.23-1-x64. The reason behind using version 1.6 is that starting from v1.7 'svn update' is not done automatically. So to keep things simple, I have used version 1.6.
Now let us verify that Jenkins is referring to correct Maven installation. Got to Manage Jenkins -->Configure System
Make sure that you have installed Maven release plugin into jenkins.
Make sure that you have entered repository information and credentials in maven settings.xml. Below is a sample settings.xml file.
Now update the iib project POM file. Below is a sample POM.
In POM, take note of below sections:
<properties>
<iib.dir>D:\IBM\IntegrationToolkit90</iib.dir>
<eclipse.workspace>D:\DevOps\Jenkins\jobs\${project.artifactId}\workspace</eclipse.workspace>
<perform.workspace>D:\DevOps\Jenkins\jobs\${project.artifactId}\perform-workspace</perform.workspace>
<project_properties>${basedir}\properties</project_properties>
</properties>
'eclipse.workspace' is the workspace where release will be prepared.
'perform.workspace' is the workspace where release will be performed.
'project_properties' is the folder that contains properties files to override the bar. One BAR will be created corresponding to each properties files. So, if you want to create BAR files for DEV, QA, UAT, and PROD; you should put properties files corresponding to each of them. BAR files will be created with the name as respective property file name appended with release version. For example, if you are releasing version 1.5, BAR file names will be DEV_1.5.bar, QA_1.5.bar, UAT_1.5.bar and PROD_1.5.bar.
Look at another section of POM:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.4.2</version>
<configuration>
<workingDirectory>${perform.workspace}</workingDirectory>
</configuration>
</plugin>
'workingDirectory' tells maven to 'perform' release in this workspace.
Also note that, release:prepare step is done in different workspace where all referred projects are present in addition to the main project. Same thing should be taken care of here also. In perform workspace, all the referred projects in addition to the main project should be present. Here I am doing this using a jenkins plugin 'Copy Artifacts Plugin' to copy projects into workspace.
Also make sure you have installed subversion tagging plugin so that jenkins can tag the build if running a normal build.
Also look at 'distributionManagement' and 'scm' section in POM:
<distributionManagement>
<repository>
<id>nexus-release</id>
<name>Corporate Repository</name>
<url>http://hostname:port/nexus/content/repositories/releases</url>
<layout>default</layout>
</repository>
<!-- <id>nexus-snapshots</id> <name>Corporate Repository</name> <url>http://hostname:port/nexus/content/repositories/snapshots</url>
</snapshotRepository> <site> <id>siteDeploy</id> <url>file:///z:/sites/</url>
</site -->
</distributionManagement>
<scm>
<connection>scm:svn:http://hostname/svn/EA.Integration/trunk/iib.project</connection>
</scm>
You need to specify at least one nexus-repository where Maven will deploy the release.
Also you must specify your project SVN url in connection under scm.
At this point I assume that your IIB Maven project is ready and you have checked-in the project into SVN.
Let us now configure Jenkins Maven job to perform the Maven release.
Click On 'New Item' and create a Maven project.
Under 'Source Code Management', select 'subversion' and provide the information.
In Repository Url, give link to your project in SVN.
Enter credentials.
Provide the Local Module Directory. Keep its name as your project name only for simplicity.
In 'Build Environment', select 'Maven release build'. Keep the default golas and options.
Now add 'Pre-Steps' to copy referred projects and libraries into both workspaces i.e. prepare workspace and perform workspace. Since release:prepare is being done in current workspace, you don't need to supply 'Target directory', however release:perform is done in as separate workspace, so you need to specify path to perform workspace under Target directory. Below are the screenshots for both. Make sure you specify the same 'perform-workspace' that was specified in POM.
Keep the 'Build' step same as you see in previous article. This step is executed for normal build, not for maven-release.
You must have followed previous article to send email notification and audit job info into database so that you can see it from Jenkins dashboard. So I am ignoring that step here.
Provide Post Build action to perform subversion tagging in case of successful builds.
You can use delete workspace plugin to clean-up the current workspace; however you need to explicitly clean-up the perform-workspace. You can execute commands to clean up the directory.
Click Apply and Save.
Now Jenkins job configuration to perform Maven-release is done. Let us execute the job.
In left pane you will see the option 'Perform Maven release'. Click on it.
Specify Release version and Development version. Supply credentials and click on 'Schedule Maven Release Build'.
It will now do a release:perform and release:prepare. You can validate the SVN repository and nexus repository to make sure everything worked as expected.
Now you can write a Jenkins deployment job that can pull a specified BAR from nexus repository and deploy to an Integration Node/Integration Server. This job configuration has already been explained in a previous post.
Feel free to post any queries.
Cheers!!!
