<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=825597734225432&amp;ev=PageView&amp;noscript=1">

The Changeable Road to Success: Inside Tempo's Cloud Development

Earlier this year, Björn Guðmundsson - the cloud development team lead at Tempo, took the stage at AtlasCamp 2017 in Barcelona, Spain to talk about Tempo's journey into the cloud as well as the challenges and opportunities his team faced along the way. Björn's talk was featured as one of the advanced technique sessions this year.

We recently caught up with him to talk about the new version of Tempo Cloud for JIRA to gain a better insight from the development side of things. This is his story.


The project's humble beginnings

This project officially started in January 2016 when a small team of developers from Tempo was invited to work with Atlassian in Gdansk, Poland to start a collaboration of adapting the Tempo product suite to a multi-tenant cloud architecture and the Atlassian Connect framework as the older app framework was being discontinued.

[callout class="tip"]A little understanding of the JIRA development world is needed to understand why we embarked on this journey. As Tempo’s solutions are sold as apps for JIRA, we adhere to both Atlassian's technology and advancements. In the previous framework, Atlassian hosted the apps on their servers. In the new framework, Atlassian Connect, apps are hosted by the company who develops them and communicates to JIRA remotely using REST.[/callout]

In November last year, Tempo Timesheets was first available to customer in its Tempo Cloud glory. The journey to the cloud was, indeed, a bumpy one as the team sailed against the wind — time was of the essence in this project and changed the way we worked for the better. The team was faced with many challenges such as AWS API wrestling matches, chanting rituals to the almighty Kubernetes gods, redesigning our application architecture, a culture shift within Tempo, and never ending stream of new concepts and terms.

Redesigning our application architecture

As the first steps were in fact taken 3 years ago when the Infrastructure team started to build a cloud-ready architecture to move our server product to “The Cloud”, we realized that it would be nearly impossible to adapt our product suite to a predesigned architecture. Which meant that our research so far had brought us to an architectural design that was a few steps beyond our initial needs. The architecture of our application was also not designed to impose limits on in-process calls to JIRA because of low latency. The consequences of this was that we would have to find ways to aggregate calls to bring data closer and eliminate waste.

Technology and architecture

First things first, choosing a home in the Cloud,

  • All the cool kids are using AWS (Amazon Web Services)
  • We tried Elastic BeanStalk and,
  • EC2 Container Service also.

We found out that the high-level services weren't a good fit for what we wanted. So instead of using AWS as a platform or managed services, we ran our own platform managed by Kubernetes on lower level AWS Services. That gave us more control and less downtime on deployment.

We have built a lot of tools and services that help us shell into clusters, do deployments, run tests and more on top of this infrastructure. All part of how we release today. Read more about our release strategy further down.

The architectural philosophy here was that all our tools are written as APIs so that we can continuously iterate.

Application and connection to JIRA

We started to identify every piece of technology that we used and was connected to JIRA, and attempted to convert into a list of contact points. From that point on we built a working container that can host all the portable technologies.

For the sake of the Cloud application we moved all non-UI components, i.e. system plugins bundled into Tempo plugins, into a container that runs in a single application container, thereby removing these inconvenient dependencies of being a separate unit since most of them are responsible for its own UI, REST resources, segregated business logic and its own database.

Information derived from JIRA such as authentication context, any communication and such was abstracted into a project we simply call Tempo-platform which is further segmented into a general API, i18n, project, user, cache, issue, event, security, and JIRA.

Communication with JIRA was delegated to another Django based micro service aptly named “The JIRA Service”.

Communication from JIRA is event based and is handled by the JIRA service, which pushes messages to the RabbitMQ broker. Services that need to process these messages can register to an event key and/or a queue on their own.

A culture shift: Becoming a service provider

Due to the iterative nature of building all the abstraction logic we also had to iteratively introduce this abstraction logic into the business logic, and make sure that we could migrate the data from JIRA to our Cloud. We had a lot of features to move or implement again, eliminate some and adding new ones to ensure we are constantly delivering more value to our customers.

The biggest change that took place?

Tempo is now a service provider.

The release strategy for Tempo's cloud development

As the new framework, Atlassian Connect, allowed for more customization and full control over production and deployment, we needed a new release strategy. Which meant:

  • Effective Quality Controls
  • A better branching strategy
  • A simpler versioning strategy

Our new way of doing things:


With a stable master, each one-off feature or bug branch from master goes through a relevant quality control (automatic and manual testing) as well as peer review and when approved is merged back to the master branch.

Every week we cut a release from the master branches that goes into regression testing, which is deployed to our staging environment that we use internally. The idea is that the changes get the necessary exposure to flush out most bugs.

The version number is just a simple integer, which means that all implicated repositories are branched from the master branch to a cloud/release/{n}.

All the issues in the release are labelled with the release and a list of them is visualized in Confluence and some notifications are pushed to Slack.

Collaboration with Atlassian

It bears mentioning that we could not have done this without the help of Atlassian and especially the JCE Team in Gdansk, Poland.

Björn would also like to take the opportunity to give thanks to everyone involved in this project. You guys are awesome and it has been a pleasure collaborating with you.


Subscribe to our blog

Get the inside scoop, previews, news and other fun stuff.