Command Line Clients to Manage Atlassian Software

Atlassian software such as JIRA and Confluence not only let user interact with them with a web interface: they both expose an API which can invoked remotely via JAX-RPC or SOAP protocols. Such an API is ideal if you need to batch execute some work on an instance or if you want to build a client of your own around it. Nowadays, with the help of modern IDEs and frameworks, it's pretty easy to build a JAX-RPC or SOAP client. The excellent Netbeans, for example, will build a Web Service client for you in just a couple of clicks: more than once I wrapped such a client inside some shell scripts just for their ease of use and for automation's sake.

Nevertheless, if what you need is just a wrapper around these remote APIs, you may consider using the Atlassian Command Line Interfaces instead of building your own client. Atlassian Command Line Interfaces are shell scripts about a Java client and the only requirement to run them is having Java in your $PATH which, probably, you already have. Their syntax respects the typical UNIX shell script conventions and you'll really feel at home with them.

There is an Atlassian Command Line Interface for almost every Atlassian product on the market:

• Bamboo Command Line Interface
• Confluence Command Line Interface
• Crowd Command Line Interface
• Crucible Command Line Interface
• FishEye Command Line Interface
• JIRA Command Line Interface

If you're using more than one product, consider downloading the Atlassian Command Line Interface bundle instead:

• Atlassian Command Line Interface

Happy scripting and enjoy a better experience with your Atlassian products.

Changing Confluence attachment storage

By default, Confluence will store attachments in the attachments subdirectory of its home directory but Confluence not only supports local file systems as attachment storage: it also supports database storage. The only drawback you should be aware of is obvious: database required capacity is going to increase. But not more than you would anyway be using in the local filesystem.

Advantages of using database storage are ease of administration as far as it concerns backing up and restoring a Confluence instance. Using your database to save files will also shield you from problems that might arise from invalid characters in file names for the file systems you're using to host the Confluence home directory.

To change Confluence attachment storage, just go to the Administration Console, open the Attachment Storage panel and select the storage type you want:

Take into account that you can switch to database attachment storage any time you need it: even though your Confluence instance is already storing attachments in the local file systems, Confluence will perform a migration of the attachments to the new storage and will soon be back online.

Backing up JIRA and Confluence taking advantage of ZFS snapshots

If you're running an instance of JIRA or Confluence (or many other software packages as well) you probably want to make sure that your data is properly and regularly backed. If you've got some experience with JIRA or Confluence you surely have noticed the bundled XML backup facility: a scheduled backup service which takes advantage of it it's even running by default in your instances.

The effectiveness of such a backup facility depends on the size of your installation but the rule of thumb is that it's a mechanism that does not scale well as the amount of data stored in your instances grows up. In fact, XML backup was thought for small-scale installations and is not a recommended backup strategy for larger scale deployments.

In the case of JIRA I still continue to run automated XML backups since they do not store attachments in them but as far as it concerns Confluence, I always disable the automated XML backup and rely on native database backup and attachment storage backup. The database backup must be performed with the native database tools such as pg_dump for PostgreSQL. The backup of your instance's attachments will depend on the type of storage in use. If you're storing your attachment in the database, your attachments will be backed up automatically during your database backup. If you store your attachments in a file systems, as it's the case for both JIRA and Confluence default installations, there's plenty of tools out there to get the job done such as tar, pax, cpio and rsync (to name just a few). Each one of these have advantages and drawbacks and I won't enter in a detailed discussion: it suffices to say that none can beat a Solaris ZFS-based JIRA or Confluence installation. 

Since ZFS inception I've been taking advantage of its characteristics more and more often and snapshots are a ZFS killer feature that will considerably ease your administration duties. Whenever I install a new instance on a Solaris Zone, I set up a ZFS file system for hosting both the database files and JIRA or Confluence home directories:

# zfs create my-pool/my/db/files

# zfs create my-pool/jira/or/confluence/home

Taking a snapshot of a ZFS file system is a one-liner:

# zfs snapshot file-system-name@snapshot-name

In an instant your snapshot will be done and you will be able to send it to another device for permanent storage. ZFS snapshots, combined (or not...) with another tool such as rsync, will incredibly simplify backing up your files and, also, maintaining a cheap history (in terms of storage overhead) of changes in case you need to roll back your file systems (and hence the data stored in your application) in case you needed it.

Take into account that, to recover a single file from a snapshot in case your original pool crashes, you will need to ZFS receive the snapshot in another pool for files to be accessible. That's why I still rely on a scheduled rsync backup together with ZFS snapshots just in case, although with a much lower frequency than in the pre-ZFS epoch.

Adding Google Analytics tracking code to Confluence

If you're using Atlassian Confluence as your content management system and you'd like to collect statistical information about its web traffic, Google Analytics is probably the tool you're looking for.

Google Analytics is an extremely powerful and flexible tool: I'm using it to monitor the web traffic to the sites I own and I'm very happy with it. Getting started with Analytics is very simple: just install the tracking code in the pages whose web traffic you want to monitor.

If you're using Confluence it's pretty easy to do: Confluence uses a flexible templating engine and modifying a page layout for a given space is straightforward indeed.

If you want to monitor all of the web traffic to your Confluence instance, though, the best option is using the Custom HTML option in Confluence Administration Console. Custom HTML lets you define fragments of HTML code to be inserted in the following positions in the generated page:

• At the end of the HEAD tag.
• At the beginning of the BODY tag.
• At the end of the BODY tag.

Just insert your Google Analytics tracking code in the appropriate place, which is usually at the end of the BODY tag and you're done! Your Confluence web traffic statistics are now being collected by Analytics.

If you're willing to experiment, Google has recently launched an asynchronous version of its Analytics tracking code which improves load times and accuracy, amongst other benefits. More information can be found here.