Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,360,313
Community Members
 
Community Events
168
Community Groups

Setup a Booking System in Jira and solve your Test Environments Booking Conflicts

It’s going to be great!

It’s now over a week that you and your team could not sleep much, fixing the latest bugs (or let’s call them “show-stoppers”) for this critical business demo of your new app that should hopefully validate months of hard work!

The demo scenario is well oiled and the rehearsal, two hours before the official demo, is a success. The conference room is wide, the projection screen huge, and you can feel the excitement in the audience: finally the top management will discover the new platform!

And then - DISASTER - the server is DOWN

Wait, is it not today that the Ops team is supposed to upgrade operating systems of your Testing Environments? The answer is in your mailbox: an email received a week ago, still unread due to the golive preparation...

Demo failure

Test Environments are scarce resources

Let’s face it, most companies need (more or less) manual testing to ensure the quality of their releases. And Test Environments are often really scarce resources, because they are are hard and costly to build, configure and maintain end-to-end.

Test Environments conflict management

Scarce resources means high demand, and high demand means potential utilization conflicts that have to be smartly managed.

Based on experience, here is what small and large organizations across all kind of industries often put in place to manage Environments Bookings and avoid conflicts:

 

1. Shared Calendar

Some teams decide to go for a shared Calendar. It comes “for free” with Microsoft Outlook and Google Workspace, or in Confluence with Team Calendars. The solution is easy to implement, however there are important limitations, for instance:

  • How do you manage access rights? If only a few people have write access, they will quickly become bottlenecks.
  • How can you audit the changes happening in your Calendar? Can you get the history of change for each booking? Probably not.
  • How do you enforce the usage of a template? For instance, you need to make sure to know the target version to be deployed on the Environment for a specific booking.

 

2. Shared Spreadsheet

In every team I was on, there was this guy thinking that the solution to any problem was a well-designed spreadsheet. And it would probably take him a couple of hours to implement an Environment Booking System in Excel, Google Sheets or Sharepoint.

It may work for simple cases, but:

Excel file in use, open a read only copy

  • How do you publish the plan? On a shared drive, really?
  • How do you make sure that you are editing the latest version of the file, and that nobody deletes a booking request by mistake?

 

3. Dedicated TEM tool

Have you heard about dedicated Test Environment Management (TEM) tools? Most of them include a booking system for your Environments. However, they are still not the panacea for a couple of reasons:

  • They usually require months to be purchased, installed and configured. And then you still need to train the team for using them properly.
  • Integrating a standalone TEM tool with the rest of your landscape may be tedious, especially when you need to connect it to a mix of SaaS and on-prem deployment tools.

 

 

Does it sound that bad?
Possibly, unless you are already using Jira!
Read further for two additional options...

 

A simple solution with Jira

With setup only, you can configure your Environment Booking System in Jira!

People in need of an Environment can then create a Booking Request (also working with your Jira Service Management portal):

Jira Test Environment Booking Request

If there are conflicting Booking Requests on the same time slot, a warning message will be displayed automatically:

Jira Test Environment Booking Request with Conflict Management

An “Open the Timeline” button can link to an Advanced Roadmap view available in Jira Data Center and Jira Cloud. When the Booking Request is submitted, the relevant approver will be notified:

Environment Booking Request Details in jira

All those fields can be entirely customized, as well as your approval workflow:

Booking Request Basic Workflow in Jira

The setup explained above will take your Jira Admin less than an hour to implement:

  1. Create 3 new custom fields: Start time (date), End time (date), Environment (multi-select list)
  2. Create a new “Booking Request” Jira issue type
  3. Create an approval workflow like the one above
  4. Jira Server/DC: add a ScriptRunner Behaviour for the conflict warning banner
  5. Jira Cloud: add an Automation rule for conflicting requests auto-linking
  6. That’s it!

For more information, refer to this documentation (for the Environment field, use a standard multi-select list Jira custom field):

Environment Booking System with Jira Server/DC
Environment Booking System with Jira Cloud

 

Go further with Jira + Golive

Improve your Environment Booking System in Jira by installing our (paid) Golive Jira App available on the Atlassian Marketplace. You get additional features:

Environment Custom Field

Get a new type of Jira custom field replacing your Jira multi-select custom field, showing you only the list of environments relevant to your current Jira project:

Jira Booking Request Environment Custom Field

Options are coming from your Environment Inventory that stores important information like the status history, deployments history, specific attributes, etc.

Jira Golive Environment Hub with status and deployed versions

Booking Timeline

Golive comes with a Timeline specifically designed for your Booking System. You can publish it on a Jira dashboard (Timeline Gadget) or a Confluence page:

Jira Environment Booking Timeline

With this Timeline, it is super easy to get an overview of all Booking Requests and visually check if they are conflicting with other activities scheduled on your environments. Re-scheduling them with drag-and-drop will automatically notify the requesters.

For more information, refer to this documentation:

Environment Booking System with Jira Server/DC
Environment Booking System with Jira Cloud

 

 

Conclusion

Managing your non-productive Environments properly is key to your success, and there are 3 options to setup a Booking System:

  • Using a Shared Calendar (with its limitations)
  • Using a Shared Spreadsheet (with its limitations)
  • Using a TEM tool (with its price and lead time)

If you are already using Jira, lucky you! You get 2 additional options:

  • Configuring your Booking System in Jira
  • Improving your Jira Booking System with the Golive App

At Apwide, we have more than 7 years of experience with Test Environment Management and helped many worldwide companies like Nestlé or SwissRe to improve their processes and tools. We are happy to discuss your needs and help you choose the solution that will suit you the most.

7 comments

Did you mean to say "scarce" resources, rather than scared?

Like David Berclaz - Apwide likes this

Hi @Dan C

Unmanaged Environments can definitely be scary ;-)
Good point thanks, I updated it!

Cheers,

David

Have you seen Microsoft Booking? You can extend this so many other usecases

Like David Berclaz - Apwide likes this

Hi @Prasanna Bableshwar, thanks for your comment. Microsoft Booking or even a Shared Calendar could definitely help for a simple booking system. But it may be too limited if someone has to setup an approval process or advanced conflict management.

Thanks for the idea. As I understand the Booking request workflow, the IN PROGRESS state represents the time slot, while the requester uses the test environment, and the DONE state represents, when the requester stop using the test environment.

Who does the state from IN PROGRESS to DONE change? What if the resource is longer in use, than it was requested and approved? How do you know, if the resource is available again? 

Like # people like this

Hi @marton_lipcsik

You make a very good point here. Usually, as a Release Manager, I would update the booking dates in order to reflect what is happening in reality.

However, it could also be interesting to compare the plan vs the reality.
For that, I would recommend to use 4 dates in the booking requests:

  • Target Start Time
  • Target End Time
  • Actual Start Time
  • Actual End Time

In your Golive Timeline, you could create 2 calendars:

  • Booking Requests, based on Target Time
  • Actual Usage, based on Actual Time

So that you could display both on the same Timeline and do your analysis. This could be a great report to show in a Release Post-Implementation Review.

Of course, it will require someone to update those dates, or to put in place a mechanism for the requesters to checkin/checkout when they start and stop using the Environment. Workflow transitions on the Booking requests with post-functions updating the right fields could be a smart way of doing it.

What do you think about it?

Have a nice day,

David

Comment

Log in or Sign up to comment
TAGS
Community showcase
Published in Apps & Integrations

Apps for Confluence you won't want to miss: RSVP for September's Appy Hours

Calling all collaborators and Confluence users! Our Appy Hours event on September 29th features 4 presenters demoing functionality to superpower Confluence. Don't miss learning about these apps i...

118 views 0 9
Read article

Atlassian Community Events