JIRA has always been a fun to use and easy to install software, and JIRA 5 is no different. In fact, JIRA 5 has improved on its predecessors by providing a more polished and powerful installation wizard, eliminating some of the old installation steps where users had to manually edit configuration files in a text editor.
In this chapter, we will start with a high-level view of JIRA, looking at each of the components that make up the overall application. We will then examine the various deployment options, system requirements for JIRA 5, and platforms/software that are supported. Finally, we will get our hands dirty by installing our very own JIRA 5 from scratch, with the newly improved installation wizard. In the end, we will also cover some post installation steps, such as setting up SSL to secure your new instance.
By the end of this chapter, you will have learned about the following:
- The overall architecture of JIRA
- The basic hardware and software requirements to deploy and run JIRA
- Platforms and applications supported by JIRA
- Installing JIRA and all of the required software
- Post-installation configuration options to customize your JIRA
Installing JIRA is simple and straightforward. However, it is important for you to understand the components that make up the overall architecture of JIRA and the installation options available. This will help you make an informed decision and be better prepared for future maintenance and troubleshooting.
Atlassian provides a comprehensive overview of the JIRA architecture at https://developer.atlassian.com/display/JIRADEV/JIRA+Architectural+Overview. However, for day-to-day administration and usage of JIRA, we do not need to go into details; the information provided can be overwhelming at the first glance. For this reason, we have summarized a high-level overview that highlights the most important components in the architecture:
JIRA is a web application, so there is no need for users to install anything on their machine. All they need is a web browser that is compatible with JIRA. Since JIRA 4, JIRA has made some major changes to its user interface, and JIRA 5 has continued to improve upon this to deliver a more responsive user experience. As a result, some of the older browsers are no longer supported. The following table summarizes the browser requirements for JIRA:
The application services layer contains all the functions and services provided by JIRA. These services include various business functions, such as workflow and notification, which will be discussed in depth in Chapter 6, Workflows and Business Processes and Chapter 7, E-mails and Notifications, respectively. Other services, such as REST/Web Service, provide integration points to other applications, and the OSGi service provides the base add-on framework to extend JIRA's functionalities.
The data storage layer stores persistent data in several places within JIRA. Most business data, such as issues and projects, are stored in a relational database. Contents such as uploaded attachments and search indexes are stored in the filesystem, in the JIRA_HOME directory, which we will talk about in the next section. The underlying relational database used is transparent to the users and you can migrate from one database to another with ease.
The JIRA installation directory is
where you install JIRA. It contains all the executable and configuration files of the application. JIRA does not modify the contents of the files in this directory during runtime, nor does it store any data inside; the directory is used primarily for execution. For the remainder of the book, we will be referring to this directory as JIRA_INSTALL.
The JIRA home directory contains key data files that are specific to each JIRA instance. There is a one-to-one relationship between JIRA and this directory. This means each JIRA instance must and can have only one home directory, and each directory can serve only one JIRA instance. In the old days, this directory was sometimes called the data directory. It has now been standardized as the JIRA Home. It is for this reason that for the rest of the book we will be referring to this directory as JIRA_HOME.
It is recommended that JIRA_HOME be created separately from JIRA installation. This separation of data and application makes tasks, such as maintenance and future upgrades, an easier process.
Within JIRA_HOME, there are several subdirectories that contain vital data:
|
Directory |
Description |
|---|---|
|
This directory contains data that is not stored in the database. For example, uploaded attachment files. | |
|
This directory contains the automated backup archives created by JIRA. This is different from a manual export executed by a user; manual exports require the user to specify where to store the archive. | |
|
This directory contains the backups that can be imported. JIRA will only load the backup files from this directory. | |
|
This directory contains the JIRA logs. | |
|
This directory is where the installed add-ons are stored. In the previous versions of JIRA, add-ons were installed by copying the add-on files to this directory manually, but in JIRA 5, you will no longer need to do this, unless specifically instructed to do so. Add-ons will be discussed further in later chapters. | |
|
This directory contains cache data that JIRA uses to improve its performance at runtime. For example, search indexes are stored in this directory. | |
|
This directory contains temporary files created at runtime, such as file uploads |
When JIRA runs, this directory gets locked, when JIRA shuts down, it gets unlocked. This locking mechanism prevents multiple JIRA instances from reading/writing to the same JIRA_HOME directory and causing data corruption.
JIRA locks the JIRA_HOME directory by writing a temporary file called jira-home.lock into the root of the directory, and during shutdown, it will be removed. However, sometimes JIRA may fail to remove this file, such as during an ungraceful shutdown. In these cases, you can manually remove this locked file to unlock the directory, so that you can start up JIRA again.