Release Management with Atlassian Bamboo and Jira

August 4, 2008, 11:48 am

I recently released a new plugin for Atlassian Bamboo called Jira Versions.
In combination with Jira, the Bamboo Tagger Plugin and the Pre/Post Build Command Plugin it can be used as a complete release management system.

This post serves both as a quick tutorial on setting up bamboo as a release management system as well as a scenario that illustrates how the plugins can be used within a release workflow.

Scenario

Project Information

In our scenario, we will be building a fictitious web app project.
This project will be using an iterative/agile development process.
We will have:

3 development iterations
2 release candidates
1 production release
1 emergency bugfix release.

Bamboo Project Information:

Project Name	Web Apps
Project Key	WEB
Plan Name	My Web App
Plan Key	MYAPP

Deployment

Since we’re building a webapp, we need to deployment workflow for when and where different builds get deployed.
Figure A. shows our logical deployment workflow. The actual physical deployment all happens from the Bamboo server via shell scripts.

Figure A. Logical Release Deployment

Versioning

Our project will use the following version number scheme:

[Major].[Minor].[Bugfix]-[type][iteration]-[build]

Major	the major release number
Minor	new features backwards compatible
Bugfix	maintenance fixes / emergency
type	release level i.e. dev, rc, prod
iteration	iteration number
build	bamboo build key / number

Using this scheme, our project will produce the following final version numbers (with multiple build versions in-between)

1.0.0-dev1 – development iteration 1
1.0.0-dev2 – development iteration 2
1.0.0-dev3 – development iteration 3
1.0.0-rc1 – release candidate 1
1.0.0-rc2 – release candidate 2
1.0.0 – first production release
1.0.1 – emergency production bugfix release

Installation

Installation is simple….
Assuming you already have Jira and Bamboo installed and running:

Just download the 3 distrubution jars from the respective plugin pages and drop them into your ${BAMBOO_INSTALL}/webapp/WEB-INF/lib folder.

now just restart bamboo.

Project Setup

Version Your Package

Most software built today is compiled and packaged with some sort of automated tool. I’m sure there are a few die-hards that are still using vi and javac on the command-line but for the rest of us not living in the eighties, we’re using something like ant, maven, etc.

To that end, the jiraversions plugin was written to be compatible with almost every automated builder known today. This is accomplished by the use of parameters that can be passed to the builder of choice via the command-line. (how that gets done will be discussed shortly).

So the first thing we need to do is setup our build script to figure out which version it’s building and use it as part of the package name.

note: for simplicity’s sake, I’m going to use Ant in the examples, but the same method can be applied to anything that can run via a command line. I’m also going to use java as the language of choice, but again, bamboo and the plugins mentioned in this post can be used to build anything.

Assuming you already have targets that compile and jar up your project, we just need to add a target that gets the current version for the build and sets it as a property that can be used to append to the name of your jar file.

<target name="get-version" unless="version.name">
    <tstamp>
        <format property="build.time" pattern="yyyyMMdd_HHmmss" />
    </tstamp>
    <property name="version.name" value="${user.name}-${build.time}" />
    <property name="version.type" value="user" />
    <property name="version.released" value="false" />
</target>

Essentially this target is here to handle builds done on a local developer’s machine.
It’s saying that if version.name was not passed on the commandline (or set some other way) then set default version properties.
The most interesting property is the version.name which will be set to the user’s username and a timestamp.
i.e. if I do a build on my local machine, the version will look something like: jdoklovic-2008-Aug-01_130923

Now we need to make sure that our final artifact is named properly. Usually you’ll have some sort of package target that handles spitting out the final artifact.
In our case the packaging looks like this:

<target name="package" depends="create-war" />
 
<target name="create-war" depends="compile,get-version">
    <property name="warfile" value="${ant.project.name}-${version.name}.war"/>
    <property name="warfile.path" value="${dist.dir}/${warfile}"/>
    <war warfile="${warfile.path}">
        <!-- add the rest of the war task specifics here -->
    </war>
</target>
 
<target name="auto-build" depends="checkbamboo,test,package,publish" />

So there are a few things going on here.
First, we have a target called package that simply depends on a target called create-war.

Although this isn’t really neccessary, it’s useful to have common target names across multiple projects. So if I had another project that creates a jar or a zip file, you would simply adjust the depends on the package target in that project. This way the lazy developers can always rely on running the package target regardless of what it actually spits out.

Next we have our create-war target.
This target depends on a compile target (which aptly named, compiles our project) and the get-version target we defined previously.
When it creates the war, it uses the ant project name and the version.name as the name of the war file. (real exciting, huh?)

Finally we have a target called auto-build.
I include this target in any of my ant files that will be called from Bamboo. Again, this just makes it simpler to setup in bamboo since you don’t need to think about which target to run.
This target can do anything you want it to and in my example I’ve included the bare minimum that I usually need a build to do…..

checkbamboo – this simply checks that ${user.name} is equal to the name of the user that bamboo runs as, and fails if it doesn’t.
test – runs unit tests and generates reports
package – runs our package target
publish – publishes our artifact to our dependency management system (i.e. apache ivy, a maven repo, what have you)

Some may wonder why the checkbamboo target exists and if it’s really useful. Although it’s very easy to get around, it’s there as a sanity check when developers are doing builds on their local machines and ensures that a developer does not accidentally publish a locally built artifact to the repository.

Obviously this is not a real and/or complete build file. It’s simply here to illustrate a basic outline of what’s needed for the automation to work.

Got Versions?

Our next order of business is to get versions setup in Jira.

There’s nothing special here…. simply create a Jira Project, go into the manage versions screen and add the proper versions.
Make sure all of the versions start out as Unreleased and are in the proper order. Bamboo will use the order provided by Jira to determine the latest version.

For our scenario, I’ve setup a Jira Project named “My Web App” with the key WEBMYAPP

My versions initially end up looking like this: (note: waiting to add the bugfix version till later)
manage versions

On To Bamboo

The last part of the setup is to configure our project in Bamboo. I’ve already setup my project with the Project Info listed at the beginning of this post, and have tied it to version control (specifically subversion).

Now it’s time to start configuring the JiraVersions plugin. The first screen we need is in the Configuration > Builder tab. Naviagte to there and click Edit Plan.

In the main Builder configuration, select Ant as your builder and put build.xml in the Build File box.
Now in the Target box, let’s add our build target and pass the version properties our build is expecting:

autobuild -Dversion.name=${bamboo.custom.jiraversion.name} -Dversion.released=${bamboo.custom.jiraversion.released} -Dversion.type=${bamboo.custom.jiraversion.type}

Our builder ends up looking something like:

Scrolling down on this same screen, click the “Enable Jira Versions” checkbox and the Jira Versions options will appear.

General Settings
First we need to let Bamboo know where to find our Jira Project by giving it the Jira Project key. You can click the test button to see if it Bamboo can find the project in the Jira server.

Next, set the Default Version Strategy to “Current Unreleased Version”. This tells Bamboo to ask Jira for the current unreleased version during “normal” operation. We’ll see how to override this later for a single build.

The Null Version strategy tells Bamboo what to do if Jira either has no versions setup, or none of the versions are unreleased (resulting in a null version returned).

The best idea is to set this value to “Skip and Pass Build” which will mark the build as successful but not actually build anything.

note: if we set it to fail the build, then builds that are fully released will fail just because there are no open/unreleased versions which might cause unwanted results in your project dependency chain.

In the future, you’ll have even more options…. (BJVER-6).

Now we can setup our version appenders. These let you append any string on to the version name before it gets expanded by any other fields. In our scenario, we’re going to append the full Bamboo build key (including the number) to the end of unreleased version names.

To do this, set the Unreleased Appender field to: -${bamboo.buildResultKey}
We’ll just leave the released appender field blank.

Version Types

The version types section allows you to add keywords that will be searched for in the version name and used as the type of release.
The searching uses a similar algorithm as the php version_compare function.

In our scenario we just need to setup dev and rc keywords.

We’re now done configuring the Builder section, so we can click the save button at the bottom of the screen and move on to the Post Actions tab.

Post Build Commands

Uner the Post Build Commands in the Post Actions tab, we need to add a Success Command.

This will be the absolute path on the Bamboo server to the shell script that will be responsible for deploying our app to the various servers.

We will setup the script to accept the properties set by the JiraVersions plugin as well as the Bamboo build result key so we need to pass them to the script here.

/opt/bamboo/deploy-scripts/deploy-webapp.sh -n ${bamboo.custom.jiraversion.name} -r ${bamboo.custom.jiraversion.released} -t ${bamboo.custom.jiraversion.type} -k ${bamboo.buildResultKey}

Tagging

Below the Post Build Commands, we can enable the Jira Versions Tagger which will allow us to make tags in our scm system based on some parameters.

In our scenario, we only want to tag successful builds, and since we’re using subversion, we’ll need to tell Bamboo where the tags should be made.

Finally, we only want Bamboo to tag Released versions of each version type.

That’s it for the configuration. Just one more thing to do before we get to the workflow:

Create the Deploy Script

Our deploy script will be responsible for figuring out which environment(s) to deploy to based on the input parameters. The deploy worflow image at the beginning of this post shows what gets deployed to where.

Create a file in the same path as we defined in the post build command. In our case, we will create: /opt/bamboo/deploy-scripts/deploy-webapp.sh

It should contain something similar to the following code:

#!/bin/bash
 
# parameter examples:
#  -n 1.2.0-dev1
#  -r false
#  -t dev
#  -k MY-WEBAPP-3
 
set -x
 
version=""
release=""
version_type=""
build_key=""
release_env=""
 
mypath=`dirname "$0"`
 
DEV_ENV="dev.mydomain.com"
QA_ENV="qa.mydomain.com"
BUG_ENV="bugfix.mydomain.com"
STAGE_ENV="staging.mydomain.com"
 
BAMBOO_HOME="/opt/bamboo/bamboo-home"
dist_dir="$BAMBOO_HOME/xml-data/build-dir/WEB-MYAPP/dist"
 
 
# ~~~~~~~~~~~~~~~~
#   Functions
#     
# ~~~~~~~~~~~~~~~~
 
usage(){
 
   cat <<EOF
    usage [-opts] deploy-webapp.sh
 
     -n [version number] (might be blank) (ex. 1.0.1-dev1)
     -r [released] (ex. true|false )
     -t [version type] (might be blank) (ex. dev, rc, blank for prod)
     -k [build key] 
 
EOF
 
}
 
deploy () {
 
   set -x
 
   env=$1
 
   cd $dist_dir
 
   box_list=$(eval echo \$"${env}_ENV")
 
   for i in $box_list
   do
 
    # Move new war file out and stop web services
    #
    scp $artifact_name tomcat@${i}:/var/tmp/
    ssh tomcat@${i} sudo monit stop tomcat_8080
    sleep 5s
 
    # Clean up any leftover Java processes (that were not killed by monit)
    # Move the new war file into the proper place
    #
    ssh tomcat@${i} killall -u tomcat java
    ssh tomcat@${i} mv /var/tmp/${artifact_name} /var/tomcat/apache-tomcat-6.0.16/webapps/my-webapp.war
    sleep 5s
 
    # Start up webapp
    #
    ssh tomcat@${i} sudo monit start tomcat_8080
 
   done
 
}
 
# ~~~~~~~~~~~~~~~~
#   Main
#
# ~~~~~~~~~~~~~~~~
 
# Get arguments (passed in from bamboo)
#
if [ $# -ge 1 ]; then
 
    while getopts :r:n:t:k: zz; do
        case $zz in
        n)   version=$2 ;;
        r)   release=$4   ;;
        t)   version_type=$6  ;;
        k)   build_key=$8 ;;
 
        *)   usage; exit 2 ;;
        esac
    done
    shift `expr $OPTIND - 1 `
fi
 
# If no version number, just exit
#
if [ ${#version} -eq 0 ]; then
 
   echo -e "(`date`) ERROR - no version number - exiting..."
   exit 1
fi
 
# Check if this is a release or not
#
if [ "${release}" == "true" ]; then
 
     artifact_name="my-webapp-${version}.war"
 
     case $version_type in
 
	#released non-production versions go to DEV and QA
        dev|rc)
              release_env="DEV,QA"
              ;;
 
	#released production versions go to STAGE
        *)
            release_env="STAGE"
              ;;
     esac
else
     case $version_type in
 
        #Un-Released non-production versions go to DEV
        dev|rc)
            release_env="DEV"
            ;;
 
        #UN-Released production versions go to BUGFIX
        *)
            release_env="BUG"
            ;;
     esac
 
fi
 
# Release code to requested environments
#
for i in $release_env
do
    echo -e "\t\t(`date`) Releasing to $i"
    deploy $i
done

Go With The Flow

Now that everything is setup, we’re ready to go through the basic development cycle workflow.

This is pretty straight forward with only a few things to watch out for…..

So let’s get started. Per our versions, we’re starting with iteration 1 of our webapp project.

Generally, we will be adding new features in our iterations based on User Stories that are entered into Jira.

As we close out Jira issues and commit code, Bamboo will build our unreleased dev1 version for us.

We can check the status of all version builds by going to the Jira Versions tab for our build plan. After the first checkin, the Jira Versions will look somethin like the following:

After our iteration is finished, it’s time to release dev1. This is a 2 step process.

First, go into the manage versions screen in Jira and click the release link next to the 1.0.0-dev1 version.

Second, go to the Jira Versions tab in Bamboo. We will now see the released dev1 version with a link that will let us do a manual build.

We need to kick off the build manually because Bamboo is now going to be building the un-released dev2 version when code commits happen. Thus, it is important to do this manual build as soon as you release the version in Jira to make sure that no commits happen after the release.

At this point, we just follow this same process for all of our iterations. When we are ready to release the final iteration version, we need to do one extra step: merge the dev versions into the first release candidate.

Merging will do a couple of things for us. It will allow users to see everything that has been included in the release candidate. It will also remove the merged version from the Jira Versions tab in Bamboo. This makes it impossible for someone to accidentally re-build an already released dev version.

You can still get to the old builds by going to the Completed Builds tab in bamboo.

To merge, you simply use the merge links in the Manage Versions section of Jira.

Once our iterations are complete and we move on to the first release candidate, the workflow remains the same… commit, Babmoo builds, release when ready.

When we reach the point of releasing the final release candidate, we again need to merge. This time we will merge all of the rc versions into the production version. From here, we just go along the workflow as normal and release the production version when ready.

Throughout the development cycles, you shee see the following:

Builds appearing in the Jira Versions tab
Un-released versions being deployed to the development server.
Released versions being deployed to the development and QA servers
Released versions being tagged in subversion
Un-released Production builds being deployed to the bugfix server
Released Production build deployed to the staging server.

If everything is good to go on the staging server, we can then manually deploy it to the actual production server. This is left as a manual process just to ensure that a human is watching the process and making sure it goes ok.

Finally, if there are emergency bugs that need to be fixed in production without a full development cycle, we can simply add a new version in Jira called 1.0.1

From there, we just do the normal process of committing code, releasing when ready, manually building the released version and manually deploying from staging to production.

And there you have it. However, there’s more……

Beware of Null Versions
We have our build set to pass with success if there are no versions returned from Jira. This is useful for dependency builds that need to complete within a larger build tree, however, this means a new development rule must be followed:

No code should be committed to a project without an unreleased version.

If code is committed, bamboo will see the change in the scm and try to run a build, but since no version will be returned by Jira, it will simply do nothing but look successful. This is not the optimal scenario and BJVER-6 aims to make this a little more fool proof.

It’s also a good idea to create a subversion commit hook that checks Jira for an unreleased version and fails the commit if it doesn’t find one.

I will post a link to the subversion pre-commit hook once I get it finished.

I hope this post was helpful.

Share this post:

Category: Uncategorized, development process | Comment (RSS) | Trackback

54 Comments

Marcin:

Good work on the integration, this could prove to be really useful for my project. What is the minimum Jira version needed for the Jira Versions Plugin to work?
August 5, 2008, 11:23 pm
Ray McDermott:

Great work on the design and integration. I think this will be an inspiration for many shops, including ours. Thanks.
August 6, 2008, 6:34 am
Daniel Ståhl:

The Jira Versions Plugin does not seem to work with bamboo version 2.1. The JiraServerManager class has moved to package “com.atlassian.bamboo.jira.jiraserver” instead of com.atlassian.bamboo.jiraserver.
August 6, 2008, 7:32 am
jdoklovic:

Marcin,

The JiraVersions plugin uses the Jira Soap Client that’s bundle with bamboo, and so it will work with the same version of Jira that Bamboo is compatible with.
Atlassian has tested with and advises using JIRA 3.12 or later, however, they say it might work with earlier versions.
You can read more here: http://confluence.atlassian.com/display/BAMBOO/Integrating+Bamboo+with+JIRA
August 6, 2008, 9:28 am
jdoklovic:

Daniel,

Thanks for catching the 2.1 bug. I didn’t have time to test since Bamboo 2.1 was just released yesterday, but I quickly got it fixed this morning.
I have posted version 1.1.0 of the JiraVersions plugin which is compatible with Bamboo 2.1 in the plugin library: http://confluence.atlassian.com/display/BAMEXT/JiraVersions+Plugin
August 6, 2008, 9:30 am
Nicholas Muldoon [Atlassian]:

Hi Jonathan,

This is brilliant, great write up!

Great to see you updated it so quickly for 2.1, hope you like the improved JIRA issue integration.

Cheers,
Nick
August 6, 2008, 7:36 pm
funnygirl:

+100. Respect.
August 7, 2008, 7:48 am
AutomateEverything:

How do tell it which environment to build to? I see the script does different things based on environment – but does Bamboo prompt the user when they do a manual build to specify an environment?
August 7, 2008, 8:27 am
jdoklovic:

AutomateEverything,

The shell script figures out which environment based on the version type and released flag passed to it by Bamboo.
so unreleased 1.0.0-dev1 goes to the dev server, released 1.0.0-rc1 goes to QA server, released 1.0.0 goes to stage, etc, etc. You can define the version types Bamboo will look for in the plugin.

Does that help?

- Jonathan
August 7, 2008, 9:03 am
AutomateEverything:

Yes – so basically – when you label, if you want to promote the build from dev to staging, you would relabel your 1.0.1-dev label to a 1.0.1-staging label and then manually build via Bamboo (changing the bamboo.custom.jiraversion.name to the label). The script does the rest. Is that right? I was hoping for a pretty screen with dropdowns, but this will do
August 7, 2008, 10:28 am
jdoklovic:

Yeah, basically the version name in jira controls what happens.
Bamboo can then pick up on the different release levels by using the “version types” you define in the plugin as well as the released status returned from Jira.
Then, it can pass those values to the build script and the deploy script.

When you want to promote a build from dev/QA to staging, you create a production version name in jira (in my case a version with just a number) and then release it in jira. From there, you need to do a manual build of that version in Bamboo from the Jira Versions tab. (not the regular manual build tab).
August 7, 2008, 12:04 pm
Tim:

“to promote a build … create a production version name in jira”
So creating new versions at the different stages and leaving all the old -dev, -rc, etc. versions in JIRA, rather than renaming them like AutomateEverything seemed to be suggesting?

I don’t suppose you’ve got some windows .bat/.cmd equivalents of your scripts lying around so I don’t need to translate them myself?
August 12, 2008, 7:21 am
jdoklovic:

Tim,

That’s correct. Generally, I setup all the versions for a full release cycle at the beginning of a project, and the last one will be the production version without a version type in it’s name. Then as we move through the dev cycle, we just release and merge versions as needed. You can also insert new versions at anytime in case you need an extra rc or something.

I don’t have a .bat or .cmd script for you, but I could probably whip up an ant script if that would help. Ant might be easier anyway since windows doesn’t have ssh/scp built-in.

- Jonathan
August 12, 2008, 8:24 am
dbox:

Hi, looks like tagging functionality below “Jira Versions Build Tagger” described above doesn’t work for me (any tags are created in SVN; everything is configured as in the article).

The same time the tagging functionality below
“What should completed builds be labelled as?” on the same page works as expected and tags are created in SVN, BUT for every single build which is NOT what I’m looking for.

How can I verify that “Jira Versions Build Tagger” action is run when building? Any ideas, hints?

p.s. I’m using prepost-build-command-2.1.0.jar, bamboo-tagger-plugin-1.0.0.jar and bamboo-jiraversions-plugin-1.1.0.jar with Bamboo version 2.1.1.

Thanks
August 22, 2008, 4:32 am
dbox:

Here is what I see in the log:

Error Tagging Version: com.atlassian.bamboo.plugin.tagger.svn.SubversionTagger.tagBuild(java.lang.String, java.lang.String, com.atlassian.bamboo.build.Build)

I suppose this is the root of all. I’ll try to figure it out…
August 22, 2008, 5:57 am
jdoklovic:

I’ve been trying to debug this issue… can you tell me if you are running a local agent or a remote agent?
Also, does the path you entered for the tags already exist in your SVN repo?
August 24, 2008, 4:59 pm
dbox:

I’m running local agent and tags path already exists in my SVN repo. Just rebuild 1.1.0 tag of JiraVersions locally with some more logging so the detailed exception is:

java.lang.NoSuchMethodException: com.atlassian.bamboo.plugin.tagger.svn.SubversionTagger.tagBuild(java.lang.String, java.lang.String, com.atlassian.bamboo.build.Build)
at java.lang.Class.getDeclaredMethod(Unknown Source)
at com.sysbliss.bamboo.plugins.jiraversions.tagger.BambooTaggerHelper.tagBuild(BambooTaggerHelper.java:40)
at com.sysbliss.bamboo.plugins.jiraversions.action.JiraVersionsTaggerAction.run(JiraVersionsTaggerAction.java:74)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:304)
at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
at org.springframework.orm.hibernate.HibernateInterceptor.invoke(HibernateInterceptor.java:117)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at org.springframework.orm.hibernate.HibernateInterceptor.invoke(HibernateInterceptor.java:117)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy50.run(Unknown Source)
at com.atlassian.bamboo.v2.build.events.PostBuildCompletedEventListener.performCustomBuildCompleteAction(PostBuildCompletedEventListener.java:68)
at com.atlassian.bamboo.v2.build.events.PostBuildCompletedEventListener.handleEvent(PostBuildCompletedEventListener.java:41)
at com.atlassian.event.DefaultEventManager$2.run(DefaultEventManager.java:202)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at com.atlassian.bamboo.build.pipeline.concurrent.NamedThreadFactory$1.run(NamedThreadFactory.java:32)
at edu.emory.mathcs.backport.java.util.concurrent.helpers.ThreadHelpers$1.run(ThreadHelpers.java:34)
at java.lang.Thread.run(Unknown Source)
August 25, 2008, 6:02 am
jdoklovic:

looks like there was an api change in the tagger plugin from 0.8 to 1.0.
http://developer.atlassian.com/jira/browse/BJVER-9
August 25, 2008, 9:33 am
jdoklovic:

I just released a new version that fixes the above issues and adds some new features…
http://confluence.atlassian.com/display/BAMEXT/JiraVersions+Plugin

http://developer.atlassian.com/jira/browse/BJVER/fixforversion/11952

- Jonathan
August 26, 2008, 3:00 pm
dbox:

I tried the last version of JiraVersions with the latest tagger plugin (version 1.0.2). Here is what I experienced:

DEBUG [pool-12-thread-1] [JiraVersionsTaggerAction] attempting to call tagger plugin
DEBUG [pool-12-thread-1] [BambooTaggerHelper] attempting to load tagger plugin from classloader
DEBUG [pool-12-thread-1] [BambooTaggerHelper] attempting to get tagger from taggerFactory
ERROR [pool-12-thread-1] [JiraVersionsTaggerAction] Error Tagging Version: 3
java.lang.ArrayIndexOutOfBoundsException: 3
at com.sysbliss.bamboo.plugins.jiraversions.tagger.BambooTaggerHelper.tagBuild(BambooTaggerHelper.java:46)
at com.sysbliss.bamboo.plugins.jiraversions.action.JiraVersionsTaggerAction.run(JiraVersionsTaggerAction.java:75)
at sun.reflect.GeneratedMethodAccessor335.invoke(Unknown Source)

Tagging still does not work…
August 27, 2008, 2:55 am
dbox:

The another problem I see in the log is:

ERROR [btpool0-3] [runtime]
get(releaseDate) failed on instance of com.sysbliss.bamboo.plugins.jiraversions.jira.VersionDisplayDecorator
The problematic instruction:
| ———-
==> ${version.releaseDate} [on line 28, column 202 in templates/jiraVersionsViewAction/jiraVersionsResults.ftl]
———-
Java backtrace for programmers:
———-
freemarker.template.TemplateModelException: get(releaseDate) failed on instance of com.sysbliss.bamboo.plugins.jiraversions.jira.VersionDisplayDecorator
at freemarker.ext.beans.BeanModel.get(BeanModel.java:223)
at freemarker.core.Dot._getAsTemplateModel(Dot.java:76)
.
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor412.invoke(Unknown Source)
.
Caused by: java.lang.NullPointerException
at com.sysbliss.bamboo.plugins.jiraversions.jira.VersionDisplayDecorator.getReleaseDate(VersionDisplayDecorator.java:47)
… 131 more
August 27, 2008, 2:59 am
jdoklovic:

sorry, both of those were just small issues. they are fixed now in a 1.2.1 release which is posted on the confluence site.
dbox: what version of Jira are you running?
August 27, 2008, 10:05 am
dbox:

Thanks Jonathan, I’m using Jira Enterprise Edition, version: 3.12.3
August 27, 2008, 10:19 am
dbox:

+1, Now it works!
August 28, 2008, 9:18 am
dbox:

Jonathan, I’m running Jira on a machine with Confluence installed. How should I configure default Jira server in the Bamboo Administrator??

When https:///jira (this is my Jira instance) is set as Host URL value the bellow error occurs:

2008-09-02 15:59:48,912 ERROR [btpool0-1] [ConfigureJiraServer] Failed to connect to the Jira Server
AxisFault
faultCode: Server.userException
faultSubcode:
faultString: No such operation ‘login’
faultActor:
faultNode:
faultDetail:
{http://xml.apache.org/axis/}hostname:linpo

No such operation ‘login’
at org.apache.axis.message.SOAPFaultBuilder.createFault(SOAPFaultBuilder.java:222)
at org.apache.axis.message.SOAPFaultBuilder.endElement(SOAPFaultBuilder.java:129)
at org.apache.axis.encoding.DeserializationContext.endElement(DeserializationContext.java:1087)

Some more details: Patch to the SVN repo and user authentication data are correct. The Jira server uses self-signed certificate, public certificate is imported into the existing Java keystore on Bamboo machine. (without this javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: subject/issuer name chaining check failed exception occurs)
September 2, 2008, 8:22 am
jdoklovic:

This is beyond the JiraVersions plugin. The Jira server stuff in the bamboo admin is shipped with bamboo and written by Atlassian.
I’d checkout the support forums and see if anyone can help…. Sorry, but I just don’t know too much about this issue.

http://forums.atlassian.com/forum.jspa?forumID=103
September 2, 2008, 8:52 am
Maxim:

I have tried to install the JiraVersions plugin on Bamboo 2.1.1. Then I click “test” button in a configuration screen of a plan tomcat answers me that there is no such page (/build/admin/edit/jiraversions/testJiraProjectKey.action) . Jira versions tab exists but plugin doesn’t seem to work Am I doing something wrong?
October 28, 2008, 10:27 am
jdoklovic:

Maxim,
Does the user you’re logged in as have Admin rights?
October 28, 2008, 12:35 pm
Maxim:

Sure. I’ve tried to log in as admin and then as user having admin rights for editing plans – the same result.
October 29, 2008, 1:47 am
jdoklovic:

what version of the JiraVersions plugin are you using?
October 29, 2008, 8:29 am
Maxim:

I am using JiraVersions 1.2.3.
October 29, 2008, 9:10 am
jdoklovic:

Maxim, can you please add an issue to Jira and attach your bamboo log file?
http://developer.atlassian.com/jira/browse/BJVER
October 29, 2008, 12:40 pm
Maxim:

Done.
October 30, 2008, 2:14 am
Joe:

Testing a JIRA key or adding a Type in a Bamboo build plan submits a form to /build/… depending on which action I’m doing. This causes a problem for us because our URLs are set up as host.int.company.org/bamboo. So the forms are posting to host.int.company.org/build rather than host.int.company.org/bamboo/build. The forms should post to build rather than /build so it’s relative to the current path. Could you look into this and see if my analysis is correct.
November 5, 2008, 9:45 am
jdoklovic:

Joe,

a similar issue was discussed as par of http://developer.atlassian.com/jira/browse/BJVER-16
It should actually be a separate issue though.
Could you please create a new issue for it?
November 5, 2008, 10:12 am
Joe:

Thanks for the help. I created issue http://developer.atlassian.com/jira/browse/BJVER-17
November 5, 2008, 2:26 pm
Tim Reynolds:

Nice post. Thank you for the info. Keep it up.
December 7, 2008, 3:02 pm
ayman:

how to hide the build from the unreleased versions.
February 1, 2009, 2:58 am
ayman:

how to hide the run build from the unreleased versions in bamboo.
February 1, 2009, 5:37 am
dudeguy:

It’s ok to have a comment.
February 1, 2009, 9:47 am
ayman:

i nee to know how to hide the run build from the unreleased versions in bamboo ASAP Plz.
February 2, 2009, 2:32 am
jdoklovic:

ayman,
currently the versions screen lists all versions and allows you to run the build for any of them.
Please submit a feature request to add the ability to hide the “run as..” button for specific version types.

add the feature request here: http://developer.atlassian.com/jira/browse/BJVER

thanks.
February 2, 2009, 9:33 am
Ed:

I have the same proble with ayman, when the jira versions are defined (unreleased) in Bamboo JiraVersion tab all these unreleased versions show Run Build link. The user that loged in to this Bamboo project have a build permission. So how to hide Run Build link from unreleased versions?
February 2, 2009, 9:54 am
ayman:

it worked with me but only if the user that is logged in dont hava admin previlage then run build link dont appeare .

thx
jdoklovic
February 3, 2009, 2:20 am
jdoklovic:

just so I understand…. The plugin is working properly in that, if a user does not have run build rights, the link does not appear, correct?

If it’s not working, please log a bug.

If it is working and you would like some other way to turn off the run build links (i.e. don’t show them for a certain version type), please log a feature request.

http://developer.atlassian.com/jira/browse/BJVER

Thanks,

- Jonathan
February 3, 2009, 9:40 am
aeames:

jdoklovic,

Our IT department is in the process of defining our release management process and stumbled upon this system. Excellent work.

Question: What would you think of having the ability to set a value attribute for the Version Type instead of using whatever was set as the pattern match? That way you could have the ${bamboo.custom.jiraversion.type} match multiple patterns (as one use case). Also the ability to specify a value to pass on a release (no key) would be helpful to some build systems.
June 8, 2009, 9:28 am
jdoklovic:

aeames,
I’m not sure I fully understand point 1, but the second point is a good idea.
At any rate, could you log both of these as feature requests here: http://developer.atlassian.com/jira/browse/BJVER

Please provide a little more info on point 1 in the feature request.

Thanks!

- Jonathan
June 8, 2009, 9:33 am
Yves:

jdoklovic,

Very nice post.

Is there a reason to do the deployment as a Post Build Command instead of in the main Build or in another, dependant, plan?

I also would like to do some automated functional testing (Selenium/Tellurium scripts) after the deployment has succeeded. Perhaps I have to do that in another Bamboo Plan with a dependency on the Build/deploy plan. Is that correct?

What are the differences between putting everything in 1) the same build, 2) in a build and a post build command, 3)in different plans with dependencies?

Thanks!

Yves
September 3, 2009, 3:48 am
tiago matias:

Hi,

I’ve been setting your example up. I’m trying to evaluate jira+bamboo to replace our in-house release management tool.

The problem is: if I set up 2 staging versions (1.0-staging and 1.1-staging) how can I check which closed (or resolved issues) does build 1.1-staging include ? Because, in the end, the client is going to ask for that “change log”

Another good thing would be to build based on a branch. For example, you have to release an emergency fix on 1.0-stating. And that is labeled on SVN. How would you build that branch? Do I have to create a new plan for the project?.

Or better still, imagine you build 1.1-DEV and check that it’s OK for Staging. You’d want to “re-build” it based on that tag, not the HEAD of the repository. Is there a way to do it without creating a new plan and setting the SVN URL to that particular tag ( svn://server/project/tags/1.1) ?

Just one suggestion, I think it would be best to create the tag before the build, and checkout the tag. That way you make sure that nobody commited anything to the repository during the time of the build.

Thanks!!
November 4, 2009, 2:16 pm
jdoklovic:

Hi Tiago,

problem 1 (change log): Currently the way to do this is to include JIRA issue numbers in your svn commit comments. You can also add a pre-commit hook to ensure every comment has a valid issue number. Then, JIRA and bamboo will be able to tell you the related issues in a commit. Finally, if those issues are marked with a “fixfor” version, you’ll be able to hook up everything you want.

problem 2 (branch building): there are many ways to handle this in bamboo. one way is to create plans for each branch that builds when code is committed, then create a plan for the trunk that is always built manually. This way you can make a bunch of builds during development on the branch and when you’re ready to go to staging, merge to the trunk and run the trunk plan.

problem 3 (building tags): CustomWare has a plugin that will allow you to build specific tags. I haven’t used it but it may work for you.
https://plugins.atlassian.com/plugin/details/5790

- Jonathan
November 4, 2009, 2:44 pm
sergiu:

Hi, I’d like to clarify how the bugfix releases should be handled…

After 1.0.0 is released, work will start on new features in 1.1.0. So new versions will be created, say: 1.1.0-dev1, 1.1.0-rc1, and 1.1.0; the bamboo build plan will start building 1.1.0-dev1, because that is the ‘first’ unreleased version, correct?

In the meantime we will need to fix some bugs in 1.0.0. Here the picture is not clear…

Normally the bug fixing occurs on new ‘release’ branch in SCM. If this work lasts about 2 weeks, to get some continuous builds, we will have to create another build plan for the new branch, and I guess associate this plan with same Jira project for which we need to create a new 1.0.1 version (in addition to the 1.1.* versions created after 1.0.0 was released). At first this 1.0.1 version is also unreleased in Jira, correct? How does the Jira versions plugin know that it needs to build 1.0.1, and not 1.1.0-dev1?

Or do we have to create a new Jira project for this, and start with 1.0.1

Can you clarify the sequence here?

Thank you
December 30, 2009, 10:51 am
Marcelo:

Hi,

Iam very insterting in can managment release, but i have problems with plugins. Iam used a Bamboo 2.5.1, then any plugin is compatible …

Do you have a date about plugins will are compatible with bamboo 2.5.1?

Can i help you? … iam very interting!!!
February 17, 2010, 9:23 am
Alessandro:

Hi,
This is probably the most useful article I’ve read in a while (especially because its exactly what I was looking for! ).

I had a question for you, I’m not an Ant guru by any means but I’ve worked out how to get our core library to compile. Now, I have 10 other projects dependant on that library. How do I compile the main library and then, once that’s compiled, get ANT to trigger the auto-compile of the other projects?
Thanks,
Ale
April 28, 2010, 7:34 am
jdoklovic:

@Alessandro:
If all of your projects are a part of a single application you can use the subant task or the ant task to call the other builds.
Usually subant is used for building subprojects. http://ant.apache.org/manual/CoreTasks/subant.html

If your projects are loosely coupled and should not all be part of a single master project, the build chain is usually handled by the continuous integration server. For example, bamboo can build a projects and you can tell it to kick off other builds if the first one is successful and so on.

- Jonathan
April 28, 2010, 8:53 am

Sysbliss Blog