Thursday 28 December 2017

JIRA Tutorial

This tutorial gives you an overview and talks about the fundamentals of Atlassian JIRA.

What is JIRA ?

At its very core JIRA is a software program that helps organizations manage their issues, tasks, processes, and projects. However, it is ‘smart software’ because much of the tedious stuff related to issues, or tasks, or processes, or project management, can be automated fairly easily. 
JIRA started life in Atlassian (the parent company) as a way to track issues related to software ‘bugs’. It wasn’t long before additional features were added and it grew into a project management program with the ability to ‘automate’ a lot of the work that is necessary but provides little value, such as emailing or phoning a work colleague when a task is done and ready to be handed off.

The Jira Architecture

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.
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 first glance. For this reason, we have summarized a high-level overview that highlights the most important components in the architecture, as shown in the following figure:
 
Web Browsers
JIRA is a web application, so there is no need for users to install anything on their machines. All they need is a web browser that is compatible with JIRA. The following table summarizes the browser requirements for JIRA:
 Browsers Compatibility
 Internet Explorer
 8 0 (not supported with JIRA 6.3)9.0, 10.0, 11.0
 Mozilla Firefox
 Latest stable versions
 Safari
 Latest stable versions on Mac OSX
 Google Chrome
 Latest stable versions
 Mobile
 Mobile SafariMobile Chrome

Application Services

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 Jira training, Workflows and Business Processes, E-mails and Notifications, respectively. Other services such as REST/Web Service provide integration points to other applications The OSGi service provides the base add-on framework to extend JIRA’s functionalities.
Learn Atlassian JIRA from Scratch and start using it effectively for Software Development. 
 
Data Storage
The data storage layer stores persistent data in several places within JIRA. Most business data, such as projects and issues, are stored in a relational database. Content 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 
Installation of JIRA would be covered as part of  JIRA Training.

1. Groups Versus Roles

OVERVIEW
The difference between JIRA groups and JIRA project roles seems to confuse many JIRA administrators. This chapter explains the differences and what each one is good for.
JIRA originally just had users and groups of users, and no project roles. Groups were pretty powerful — wherever you could do something with a user, you could generally use a group instead.
For instance, if you wanted to allow a specific user john.smith to change the Reporter field in a project’s issues, you could:
1. Create a new permission scheme with a description something like john.smith can change Reporter.
2. Next, add the john.smith user to the appropriate Modify Reporter permission entry in the new permission scheme.
3. Change the appropriate JIRA project to use the new permission scheme.
You could also do the same thing with a group:
1. Define a new JIRA group named Can Modify Reporters.
2. Add the user john.smith to the new group.
3. Create a new permission scheme with a description something like Added an extra group of users that can change Reporter.
4. Add the group (instead of the user) to the appropriate Modify Reporter permission entry in the new permission scheme.
5. Just as before, change the appropriate JIRA project to use the new permission scheme.
Both of these approaches now allow john.smith to change the Reporter field. So far so good, but there are two main problems with using JIRA groups like this: scaling and updating.
Scaling
If you want john.smith to be able to edit the Reporter field in some projects, and also allow a different user, jane.bloggs, to do the same thing in other projects, then you have to create two permission schemes, one for each user being granted this permission. If you then decide that they are both allowed to edit the Reporter in some shared projects, then you need a third permission scheme. With lots of users, this leads to an explosion in the number of permission schemes (and any other JIRA scheme that supports groups).
Keeping track of the difference between each of these permission schemes is tedious and error-prone, even with the scheme comparison tools (Administration→Scheme Tools), which are themselves deprecated in JIRA 6.4.
Updating
As time passes, users will likely need to be part of different JIRA groups. Only JIRA administrators can change the membership of JIRA groups. However project leads are allowed to make changes to project roles, and project leads usually know which project roles a user should currently be part of. Using project roles means fewer tasks for JIRA administrators.


Source: Mindmajix
Explore More courses Mindmajix

No comments:

Post a Comment