How to implement a Staging to Production process in Jira
Making configuration changes to a Jira environment is not always simple, and can even be a risky undertaking. Risky because if you make a change and something goes wrong, then you can quickly find yourself with a lot of unhappy Jira users.
Reduce this risk by using a Staging to Production process
To avoid this fate, it’s highly recommended you first test any Jira configuration changes you plan to make in a test or Staging Jira environment. As a result, you can check they will work as planned and not crash your system.
There is however, a drawback to this approach. Your efforts are doubled as you need to make the changes twice, once in a Development environment before making the same changes again in your live Production Jira instance. This can be done manually but if you are making a significant amount of changes a lot of your time can be eaten up. In addition, it’s very easy to miss something or make an error when repeating the changes for a second time.
Project Configurator for Jira: giving you the best of both worlds
With Project Configurator for Jira you can test your configuration changes in your Development environment before easily implementing them in Production. Crucially, by using Project Configurator you can copy these changes across to your Production environment significantly quicker and with a reduced chance of errors.
It's not uncommon for Jira Admins to be making configuration changes on a daily basis, therefore the accumulated time savings can be huge. With this repeatable, reliable and streamlined process in place, you can rest easy knowing your Jira configuration changes are not going to crash or break your live Production Jira instance. Plus it won't have taken you all day!
Did you know?
Jira Data Center users can also use Project Configurator, for their Staging to Production process, often with even greater benefits. This is because the chances are your Jira will have more ‘moving parts’ in need of regular updates or alterations, increasing the volume and frequency of these changes.
Sounds great. How do I get started?
1. Set up your second Jira instance
To implement this process you’ll need at least two instances of Jira. One as your main Production instance, this is the one all your users will interact with on a daily basis. The second is a Testing or Staging instance. An optional third environment can be used if you want an additional Testing environment in which to perform testing, perhaps one you would give access to regular Jira users to experiment with.
Did you know?
You can get your (additional) Jira instance for free! If you have a commercial and academic server license (not available for cloud or server starter products), then you are also entitled to additional test or Development Jira licenses. This guide by Atlassian will help you access these licenses.
With your additional licenses, you can set up your Staging and/or Testing Jira environments. For detailed information on how to do this please see this guide from Atlassian.
2. Use Project Configurator to streamline the Staging to Production process
Once you have this architecture in place you can begin making changes in Staging. To “promote” (also known as “copy”), these changes across to your live Production instance, you’ll need to install Project Configurator on both of these Jira instances. Don't worry though, you only need a commercial license for the Production instance.
3. Start promoting changes into Production
You’re now ready to begin promoting changes between Staging and Production. To see how this process works in action take a look at this demo video.
Something not mentioned in this video, but for those looking for a more comprehensive process for recording changes. It is possible to retain the details of any imports performed with Project Configurator. Use the 'Download' button on the final import screen to download a record of the import.
This allows Jira Admins to treat Jira configuration ‘as code’. ‘Configuration as code’ is a concept that allows Admins to store a record of configuration changes in a similar fashion that a software developer would store their code edits in a Version Control System (VCS), such as Atlassian’s Bitbucket. This extra step is great for storing backups, for rolling back changes, or for auditing purposes.
4. Read our documentation for more information
Next, we would suggest reading through this step-by-step guide to help you with your first Staging to Production configuration promotion using Project Configurator.