Published on September 5, 2022 in

6 minutes read

Up to Eleven - Amplify Your Development Setup for Atlassian Server and Data Center

Christoffer Bromberg Director of Engineering

Published on September 5, 2022 in

6 minutes read

This post will give you a list of three simple recipes that will make sure you get the best combination of development tooling and application speed using Atlassian Jira and Confluence, on Server or Data Center. The recipes are self-contained and each one will speed you up while pursuing your goals. You'll learn how to tune your host product when using the Atlassian SDK and how you can tweak a stand-alone product installation to support your development and test workflow.

Are you an administrator, a power user, or a developer building on these applications? If so, you probably run Atlassian applications on your computer to get feedback on your questions. In reality, this feedback takes much longer to get than you might like. With a little tuning, you can level up your tool chain and spend more time on real work; whether you're exploring configurations, composing solutions, reproducing error situations, or building the next big thing.

There is a multitude of options for running Jira or Confluence on your computer: you can

Use the

Atlassian SDK
Install

Jira
or

Confluence
as a stand-alone product
Run a containerised

Jira
or

Confluence

I won't go into the containerised option here, although running the applications in a container can be an excellent choice if you want to learn some Docker background.

For your development or test requirements, you might need to run different versions of your application at different times – or even at the same time. This, and other factors, might lead you to choose the Atlassian SKD option.

Running Your Application with the Atlassian SDK

The Atlassian SDK is a set of custom Maven plugins and shell scripts that make running a development grade system a walk in the park. The SDK comes in different installer options and gives you a lot of power to explore solutions, development tasks, and CI workflows.

To run an Atlassian product, you can start a preconfigured Jira or Confluence instance using atlas-run-standalone with a single command, e.g. atlas-run-standalone --product jira --version 7.9.1. All you need is a working Atlassian SDK and a compatible Java installation. Maven will do the magic of pulling down the right software pieces and versions and run them for you. This might be all you need for a one-time shot, but it will get slow to run and hard to manage. If you're not careful, you might even wipe out all your precious data by blowing up or erasing the embedded database.

To use the Atlassian SDK in a more repeatable and declarative way, create a Maven pom.xml to manage versions and settings. Either create it for this sole purpose or use the pom.xml you maintain for your app already. This will require some knowledge in using Maven's infamous XML runes. Here's a basic working setup to run Jira 7.9.1 from a pom.xml as above:

... <packaging>pom</packaging>
    <build>
        <plugins>
            <plugin>
                <groupId>com.atlassian.maven.plugins</groupId>
                <artifactId>maven-jira-plugin</artifactId>
                <version>6.3.21</version>
                <configuration>
                    <productVersion>7.9.1</productVersion>
                    <productDataVersion>7.9.1</productDataVersion>
                </configuration>
           ...

Recipe 1: Turn Off the Development Mode

When you run Atlassian applications using the SDK, by default, atlassian.dev.mode is set to true which in turn enables a whole fleet of development tools. If you're not a developer, the odds are good that you don't need them.

To disable the development mode simply follow the steps below:

Approach

How to

atlas-run-standalone

start product with additional environment variable

ATLAS_OPTS="-Datlassian.dev.mode=false" atlas-run-standalone --product jira --version 7.9.2

atlas-run / atlas-debug

in pom.xml:

    ...
    <productDataVersion>7.9.1</productDataVersion>
    <systemPropertyVariables>
	    <atlassian.dev.mode>false</atlassian.dev.mode>
    </systemPropertyVariables>
    ...

A simple benchmark gives compelling reasons to switch off the development mode:

Loading the same "Open issues" page on the Jira instance I created earlier took around 14 seconds with development mode, but less than two seconds to load without development mode. This quickly adds up to a lot of time - your time. With this change, you'll spend less time waiting for pages to load, context switching - and altogether lowering your productivity.

This single switch turns your Atlassian SDK-powered host application from sloth-mode to cheetah-mode.

Recipe 2: Running a production application

The Atlassian SDK gives you a flexible starting point for your exploration, but also adds additional dependencies, like having the Atlassian SDK configured and using Maven together with the Cargo plugin to start your environment. This all amounts to a slower environment and more resource usage on your computer. Running a production grade system entails you downloading the Jira or Confluence from Atlassian and install and configure it yourself. This gives you all the options that an Atlassian admin has when running an Atlassian product, but also requires more configuration. Once you start the product, you have to go through setup configuration to select a database, user directory, initial content, and admin - or upgrade from an existing environment.

If you run a production application often, some automation is helpful. The setup dialogs are scriptable via HTTP, so you won't have to use browser automation.

The increased effort in starting up a new environment is countered by the increased flexibility and speed. It also removes the Maven and Cargo dependency. Even with the production application, you have the option to use an embedded database. Though it's convenient, if you're tech-savvy, I recommend using a real database instead. Preferably, use the type of database your shop uses for production. At K15t, we use Postgres for :all_the_things: RDBMS. For your local setup on a Mac you might want to try the https://postgresapp.com/ - or use a dockerized database. Using a real database not only makes the application faster, you will also enjoy using your favourite SQL tools against the database to experiment, report, and fix.

Recipe 3: Tune the Application Memory

To improve your user experience running Jira or Confluence on your computer, tune the amount of memory the Jira or Confluence may use. RAM is cheap, your time is precious. This recipe is valid for all options for running your application, although the ways to put it into effect are slightly different.

So without further ado, start the application with 2GB of RAM - so it does not choke on the simple things:

Approach	How to
atlas-run-standalone	Add the following option to run the application `--jvmargs '-Xmx2G'`
atlas-run / atlas-debug with pom.xml	Add the following config parameter to your pom.xml `<jvmArgs>-Xmx2G</jvmArgs>` inside plugin/configuration of your maven-confluence-plugin or maven-jira-plugin
Production application	Either start the application with a System variable definition, e.g. `CATALINA_OPTS="-Xmx2G" ./start-jira.sh`, or define that inside the bin/setenv.sh file - then you should define it at the end of the existing `CATALINA_OPTS` value to make sure that it takes precedence, e.g. `CATALINA_OPTS="${CATALINA_OPTS} -Xmx3G"`

You now have a running application with a quick front and back end; so go explore!

If you are a developer and want to debug your (or – what a pity – somebody else's) Java code, then simply append the JVM parameter -agentlib:jdwp=transport=dt_socket,
server=y,suspend=n,address=5005 to the parameters detailed above to allow for attaching a remote debugger to port 5005.

Recipe 4 - Use the QuickReload plugin

With the other recipes in place, your setup should already be quick enough for you to explore your ideas and even debug existing code. However, if you want to write Java code for an app, then your turnaround time – i.e. the time that lies between writing the code and running the code – is terrible. Currently, you would need to build the software artefact – i.e. your app's .jar or .obr file (probably using Maven) – and install it using the Administration console aka the Universal Plugin Manager. Sounds like a chore. What you need is the easy deployment method and more tooling provided using the QuickReload plugin.

This QuickReload plugin enables you to:

Quickly redeploy an app in development
Load changed web assets from development folders without redeploying an app
Switch web resource batching on (quick, but harder to debug) and off (slow, but readable JavaScript)
Access the database using SQL from within the UI of your Atlassian application

To get access to these features, install the plugin and configure it for the app or apps you're building. You can support different kinds of workflows through a shared configuration file or with ad hoc configuration through a simple REST interface – check the readme here. Whichever configuration suits you best, when the QuickReload plugin is set up, all you have to do is to trigger a build of your artefact by mvn clean package.

Got the automate :all_the_things: frenzy? Try containers instead. These can make your setups reproducible on other computers and add more flexibility. At K15t we use docker-compose to quickly spin up a realistic setup, even for Data Center, including a load balancer, application nodes, and databases. The topics you learn on the way will be valuable assets in today's DevOps world.

Build the Next Big Thing

Regardless of which way you run an Atlassian application, these recipes can dramatically improve your experience. Implement these recipes to increase your productivity now so you can focus on the real challenges in your organisation.

Share this article ✕