Deploying JIRA in the Enterprise – Part 3 – Configuration in Subversion and Deployment using Bamboo

This is the 3rd part in a series of posts on Deploying JIRA in the Enterprise. The last part covered Packaging using the RPM Maven Plugin. This post will focus on how to store the environment configuration in Subversion and using Bamboo for deployment.

As I have gone over in my last post, the reasons why we use a technology are often based on many factors. The same can be said for the choice to use Subversion for storing environment configuration. At my previous company, Red Hat Satellite was standard for configuration management and deploying RPM packages. There are many other tools that can provide the same functionality but I am using Subversion for two main reasons:

  • it is a supported production environment
  • it was fast to implement

What are we storing in Subversion? My rule is simple – only store environment specific files. For JIRA this could include some of the following files depending on how your environment is setup:

  • dbconfig.xml – the database configuration
  • server.xml – the tomcat configuration
  • – jira config options
  • logo.png – logo for different environment
  • – different JVM requirements

The structure in Subversion is a folder per environment with a path of folders to the files from /apps/foo-jira. For example, dbconfig.xml for Production would be located at Production/jira-home/dbconfig.xml which would map to /apps/foo-jira/jira-home/dbconfig.xml. Ofcourse, the path could start at / or any other path if that makes sense for your deployment environment.


This method does mean that any changes to a configuration file need to be updated in each environment. I would prefer to have a more elegant solution that substitutes variables into template files like in a Chef cookbook or similar but for the limited changes required to these files, Subversion works fine.

So, we have our RPM package and we have our environment configuration in Subversion. Let’s have a look at how Bamboo can tie this all together.

Firstly, lets have a look at Building the RPM. It will actually be a very simple plan – there will just be one Stage and one Job.


The first task for the Job will checkout the package source from subversion – this is a standard Bamboo task. The second will run the “mvn package” command. I tried to use a Maven Task but I couldn’t find a way to configure the task to run via sudo as I need privileged access for Maven to call rpmbuild. Instead I used the Custom Command Task and I run “sudo mvn package”. This task builds the Maven project and generates the RPM.


The Shared Artifact functionality defines where the RPM will be picked up from for use in other tasks – in our case the deployment.


Bamboo has a neat new feature called Deployment Projects. Although you could previously use Build Projects for deployment tasks, the new Deployment Projects enhances the management of deployments by introducing specific functionality suited to deployments such as defining environments and releases. For my example, we are going to use the Integration environment.


Once a successful build has been made, we setup Bamboo to automatically trigger a deployment to our Integration environment. It also creates a release for this deployment using a specific naming convention.


Lets move onto the Tasks of the Integration environment deployment plan. The first task cleans the working directory, the second picks up the RPM via the Shared Artifact configuration generated from the Build Plan.


Next we stop JIRA and uninstall the existing rpm. I am using some basic shell scripting to list the existing rpm packages and find the one containing “jira” to uninstall.


We need to cleanup some remaining application directories and temporary files. Then its time to install the new rpm package.


We export the configuration from Subversion and update some permissions on the fly as the export command in Subversion doesn’t seem to support the executable flags.


Start JIRA and we run some tests of basic functionality.


And that is it – the deployment is complete in the Integration environment!

The build takes 10-15 minutes and the deployment around 4-5 minutes. Timing will obviously vary depending on environments and the amount of testing that you perform. Once the build is completed and released, we can deploy the release easily to any other environment.

That completes our deployment process.

Deployment Architecture

Ofcourse this is not perfect and there are many different ways to implement deployments but it does work quite smoothly. Here are a few points of review to note:

  • You may be wondering, why use RPMs at all? Why not check out the package contents and use scripts to copy and permission the files where you need them – its basically the same as using an RPM. I must admit that it will make the whole process faster but RPMs do have an advantage in that they provide a backup in case Bamboo and/or Subversion is not available. Plus packages are more final – they can be signed and secured to ensure integrity as well.
  • It would be nice if it was possible to easily template or share tasks between environments in Bamboo. I think Atlassian are working on this already and  definitely would help to ensure consistency of deployments.
  • When I am actually building a new package, I usually prototype and test my changes on my Development environment without updating the package first, then I update the package with the changes build and deploy to Development and Integration, test and promote to Staging and then Production. It doesn’t make sense to continually package for smaller changes.

Ok, I think thats all for this series. Hope you found it interesting and if you have any questions, please let me know.

the jira guy


Deploying JIRA in the Enterprise – Part 1 – Setting the Scene

Last week I presented at the London Atlassian User Group. The title of the presentation was “Deploying Atlassian Tools in the Enterprise”. You can view the slide set here. I tried to keep the presentation on the general side but following on, I thought I would dive a little deeper into the detailed implementation for those who are interested.

I am not going to go over the whole introduction part of the presentation in detail but to quickly review…

  • In my experience, the challenge of deploying a large number of application instances drove my teams to look for better ways to manage deployments.
  • Its not just about large numbers of instances, it can help any environment with having a controlled way to manage application environments.
  • The approach that you take will depend on the environment that you work in. Utilise the infrastructure and knowledge that you have within your team or organisation.
  • This process is not just applicable to JIRA or Atlassian tools – it can be used for other application deployments.
A real world example of the number of instances of Atlassian application instances managed by my team

A real world example of the number of instances of Atlassian application instances managed by my team

For most Atlassian applications, there are two main parts of the deployment – the application (binaries, configuration, etc) and the data (database, attachments, temporary files, etc) . I am not going to go into the data part in detail during this set of posts but focus on the application deployment. For the application deployment, there are three components that we will break down:

  • Packaging using the RPM Maven Plugin
  • Configuration stored in Subversion
  • Deployment Method using Bamboo
Application Deployment

A summary of the application deployment process

So, watch out for Part 2 – I will start on the detail into the Packaging with the RPM Maven Plugin.

the jira guy