This article is the first of a series of three about managing JIRA instances inside the enterprise. This is based on resources from the Atlassian Documentation (here) as well as our knowledge as Atlassian Experts.
Setting up JIRA test environments
When we administer one or more JIRA instances, it is essential to have at least one testing environment set up (for each instance!). In most companies, we make a distinction between these different types of servers:
- Production: the server currently installed for all users.
- Staging: a server with an identical architecture to the production one, it allows you to test change procedures before applying them on the production server. It can also be useful to execute performance testing (for capacity planning or before a JIRA upgrade).
- QA (Quality Assurance): this server allows anyone to test changes such as core code modification, plug-in installation, execution of a script, etc.
- Development: server on which are tested all the specific developments made by developers (if there is any). Developers can also have a local instance on their computers.
Once these environments are set up, you need to establish a release strategy for new features or enhancements. These changes can be of different types:
- Modification of an existing workflow: you need to define on which server the modification will need to be tested before releasing it in production. You also need to decide who is going to be in charge of this modification: the JIRA Administrator or the requester of the change (to whom you would have given temporary administration permissions).
- Adding a new plug-in : who has the ability to install a new plug-in and on which server should they do it? Who is able to validate the release (and sometimes the purchase) of a plug-in? Etc.
- Plug-in development: How often the new features of this plug-in released? How are these communicated to end-users? What kind of documentation is expected? Where is the source code located? Who is doing peer reviews? What CVS tool is used?
- JIRA upgrade: On which server is the upgrade tested? Who is able to validate the upgrade procedure? What are the communication steps for end-users?
Ideally, you would need to answer all these questions before even having deployed JIRA. But don’t worry, it is never too late to establish you own release strategy.
Finally, you need to decide (and communicate about) how often you will update your environments. The more up to date your data is, the more relevant your tests will be to your production environment; but you should also keep the data long enough to allow long-term testing (e.g. impact of a plug-in growing data).
Update your JIRA test environments
To update a test server with the latest data from production, you need to follow these steps:
- Back up the <jira-home> folder from your production server and replace the one on your test server.
- Back up JIRA installation folder and replace the one on your test server.
- Back up your production database and import it in a newly created database.
- Edit <jira-home>/dbconfig.xml file to use your new database.
- Edit the <jira-install>/WEB-INF/classes/jira-application.properties file if the <jira-home> folder is located in a different place on your test server.
- Start your test server.
- Deactivate all your email servers (ingoing and outgoing).
- Edit the base URL of your JIRA instance.
- Edit the JIRA Look and Feel. Generally, we edit the color of the header to distinguish the different environments. You can also use the announcement banner for this purpose.
- Reconfigure Application Links if needed.
Test servers are there to secure your production environment, so do not underestimate this when deploying JIRA.
The next article of this series will concern the sizing of a JIRA instance: how can you evaluate the expected volume a year from now before having even installed the product?