Wrapping an Atlassian application in a package with a nice bow makes it easier to install via a configuration management tool. Building an RPM was a pain until we started using FPM, the Effing Package Management (https://github.com/jordansissel/fpm). The README includes required packages and installation steps across a variety of platforms.
Here is the command to run to build a version of Jira Software 7.0 into a RPM package:

jira_version=7.0.0
jira_software_version=7.0.0
echo "DOWNLOADING Jira ${jira_version}"
wget --no-check-certificate -P /tmp/ https://www.atlassian.com/software/jira/downloads/binary/atlassian-jira-software-${jira_version}-jira-${jira_software_version}.tar.gz
echo "CREATING Jira SOFTWARE RPM"
fpm -s tar
-t rpm
--verbose
--architecture noarch
--prefix /opt/atlassian/jira
--description "Plan, track, work. Enable development and IT teams to capture issues, plan work, and resolve requests. Spend less time managing work and more time building great software."
--maintainer "Atlassian"
--url "www.atlassian.com"
--directories /opt/atlassian/jira/atlassian-jira-software-${jira_version}-standalone
--name atlassian-jira-software
--rpm-init /vagrant/initscripts/jira
--version ${jira_version}
/tmp/atlassian-jira-software-${jira_version}-jira-${jira_software_version}.tar.gz

First this snippet lets you set the version of Jira and the Jira Software subversion (at the time of this writing it’s unclear if these numbers will always be the same or not) and then downloads it. Now, let’s break down the package creation…
-s tar – this defines the source as a tar file. You may choose to extract the tar and change this to dir if you want to include other files in this package installer.
-t rpm – for this example we are creating an RPM package, but you can also create DEB.
–verbose – I like to see the output of the file creation.
–architecture noarch – the tarball downloaded from Atlassian is not architecture specific, so we don’t restrict the RPM. You may choose to change this if you add additional files that make it specific to an architecture.
–prefix /opt/atlassian/jira – this defines the folder the RPM extracts it’s contents into.
–description “blah blah” – this gives a fancy description when you do “yum info”
–maintainer “Atlassian” – more yum info contents
–url “www.atlassian.com” – more yum info contents
–directories /opt/atlassian/jira/atlassian-jira-software-${jira_version}-standalone – this section defines folders that are “owned” by the package. If you were to erase the package these directories would go with it.
–name atlassian-jira-software – the name of the application in yum
–rpm-init initscripts/jira – this copies a file from the initscripts folder (local) into the RPM and then extracts it into /etc/init.d/. You can find a good example of this from Atlassian at: https://confluence.atlassian.com/jira/starting-jira-automatically-on-linux-211060709.html
–version ${jira_version} – this defines the package version, which we want to match the Jira version number.
/tmp/atlassian-jira-${jira_version}-jira-${jira_software_version}.tar.gz – this is the location of the tarball we downloaded earlier.
After creating these files, you can copy them to an existing yum server and then be able to install Jira as a package. A couple of notes about the packages we create and some steps you could add to extend this package:

  • FPM defines a release in the package name, even if we don’t provide one in the steps above. By default, all packages are created as Release 1.0.
  • We choose not to change ownership of the extracted folder or start the service since both of these tasks are handled by SaltStack (and could be handled by any of the configuration management tools).
  • We manage our versions using a symlink in the filesystem called current. When a new version is put in place, the current symlink is forced to the version being installed. FPM allows for these with options for after-install, before-install, after-remove, before-remove, after-upgrade and before-upgrade.
  • If you choose to use any of the optional scripts mentioned above, one cool feature of FPM is to allow templatized variables in each of those scripts using the options template-scripts and template-value KEY=VALUE. This would allow you to pass the version of the application into any of the package scripts.