JIRA系统的设置和使用

1.1 JIRA系统安装

JIRA的官方网站：http://www.atlassian.com/software/jira/overview。

在官网上下载JIRA安装文件，在服务器上安装（提供30天试用版本），安装前需要指定数据库，具体安装过程不再赘述。

安装完成后运行第一次的向导，主要是设置管理员，JIRA名称，http服务端口及URL，邮件服务器等基本信息。

1.2 系统基本设置

以管理员身份登录成功后，需要进行系统设置，点击右上角Administration，提示用管理员身份进行管理。

1.2.1 通用设置

系统的基本信息虽然在安装完成后的向导中进行了设置，但是还可能在后期进行调整，打开导航栏System->General Configuration，可以设置系统标题，语言属性和一些issue细节设置等。

1.2.2 邮件配置

任务管理系统最重要的在于实时提醒功能，在任务状态改变时，任务分配给相应人员时都要有邮件提醒，下面就对JIRA中的邮件配置进行介绍。

以管理员身份登录，单击导航栏System->Mail选项对邮件选项进行设置。

显示5个页签，最重要的就是Outgoing Mail页签，设置默认的SMTP Mail Server选项，这里我们在本机建立一个Mail Server，设定完host name，smtp server，超时时间以及用户和密码后，可以用Send E-mail页签进行邮件发送测试，以测试邮件服务器设置是否成功。

1.3 建立JIRA工程

基本的设置完成后，那么就加入要管理的工程。在管理页面中，单击导航条上的Projects，会显示出所有的工程列表，在工程列表右上方有Add Project按钮，即可加入Project，并设置Project Lead信息，加入工程后显示该工程中的基本信息：问题类型，版本，组件，角色工作流等等。

1.4 JIRA Issue基本配置

JIRA项目中的大部分配置都采用Schema的方式（除简单的角色，模块等信息），方便配置在项目之间共享配置，下面对JIRA中的详细配置进行简单的说明。

1.4.1 Issue types

JIRA项目中的问题类型，使用的default issue type schema中，存在着Bug，Improvement，New Feature，Task，Sub-Task等类型。我们建立的项目中需要自定义一些基本类型，在此就新建一个单独schema关联该项目使用（这样就不会影响其他项目的默认schema）。

在导航栏中选择Issues->Issue Types，进入Issue types列表：

在Issue Types选项卡中，选择右上角的Add Issue Type，建立一个全新的NC Improvement Rule，设置Type为Standard（Sub-Task类型比较特殊，本文未涉及到）。

在Issue Type Scheme选项卡中建立NC Improvement Rule Scheme，编辑并设置成该scheme中仅有一种Issue Type：NC Improvement Rule，并将该Scheme关联(associate)至第一步新建的工程上，这样该工程中就仅能创建出这种类型的Issue。

1.4.2 Workflows

工作流定义了在本JIRA项目中用户从提出问题到解决问题的整个流程，在导航栏中选择Issues->Workflows，进入Workflows列表，会展示所有的workflow状态并按照是否active分类。

JIRA中提供了对于工作流的图形化界面编辑器，可以方便地进行workflow的编辑，加入额外status，定义全局transition等操作，这样我们就可以完整地构造出工作流了，下图就是JIRA中的工作流编辑器展示：

列表中会显示当前使用的Workflow Schemas和该schema关联的workflow，本项目中我们根据自定义的问题类型NC Improvement Issue的处理流程特殊设置一种工作流，并关联刚刚新建的项目中。

JIRA中提供的工作流编辑器以图形化的方式方便用户进行流程定义，状态增加等操作；在增加完成后，需要进行schema定义，为相应的issue关联对应的workflow。

注1：在编辑流程状态连线的Transition时，不仅要指定对应的transition destination(目标状态)，而且还需要指定transition view，指定状态转变时弹出的view。

注2：工作流编辑完成后的状态其实为draft，需要手动进行publish操作。

Workflow Schemes中会显示当前工作状态中的所有workflow scheme，可查看当前状态，分配的相关Project，关联的Issue Type和workflow等，

1.4.3 Screens

顾名思义，Screens就是问题类型中屏幕显示界面，但是在Screens中不同于以上的是有3个不同的页签，导航栏中Issues->Screens。

在Screens中定义页面，页面中可设置该Project相关field scheme中定义的所有字段，以对话框形式显示，这些页面可以在某些流程中直接被引用（参照4.2.2中Workflows的transition view），也可以在某些operation发生时被调用（参考下一节Screen Scheme）。

在Screen Scheme中可定义Issue operation与screen的关联，比如create, edit, view issue时显示的关联Screen；其中会默认存在一个Default Issue Operation，不能被删除，作为未设置的operation默认Screen。

在Issue Type Screen Scheme中进行设置每种issue对应的Screen Scheme类型，以及该screen schema在哪个Project下被使用。

我们自定义的issue type schema，screen schema，fields schema都要在项目管理页面上配置，这些都是以Project粒度配置的，参照右上角的Use a difference xx schema。

1.4.4 Fields

在JIRA中还可以对Issue的显示字段进行定义，不仅可更改默认字段的显示，还可以增加自定义字段并设置类型，导航栏Issues->Fields：

Custom Field中可以加入自定义的字段，会显示Wizard，选择自定义字段类型，设置字段名称及描述，管理项目，设置查询模板等，并将其关联至Screen。

Field Configuration是对每个字段配置使用方案，每种不同的Field有着不同的Screens（显示在哪个页面）和Operations（设置编辑，隐藏，必输等）。

Field Configuration Schema中建立Issue type与Field configuration之间的关联，即设置某种Issue type关联某种Field configuration，个性化Issue的Field显示状态，关联至Project上。

1.4.5 关联关系总结

设置完工程中的上述条目后，我们对JIRA项目中的这几种类型进行总结，以便能够更加清晰地了解JIRA中各模块之间的关系，关系图如下：

首先，对于每个工程，都存在四种类型的Scheme：Issue Type, Workflow, Screen Configuration, Fields Configuration，这四种类型之间的关系又是交叉的。

Issue Type Scheme决定了该工程中存在的Issue Type；Fields Configuration中定义了Issue Type与Field Configuration之间的一一对应关系，Field Configuration中对该Issue Type中可能会存在的Field进行定义；Issue Screen Configuration Scheme中定义了Issue Type与Screen Scheme的对应关系，而Screen Scheme更关注细节，对该Issue Type的每种Operation都指定对应的Screen；Workflow Scheme中定义了Issue Type与Workflow对应关系，Workflow由Status（状态）和转换（Transition）组成，转换的过程可以设置Screen。自此，整个工程的体系就大致讲明白了。

1.5 JIRA用户设置

在完成了JIRA问题的定义之后，进行User设置，使得权限和工作流相结合，控制用户的行为。

1.5.1 Users

1.5.2 Groups

用户组在权限等操作过程中发挥着重要作用，每个用户可以属于多个用户组。

1.5.3 Roles

除了用户组之外，JIRA系统还可以定义Role来进行权限控制，这就相当于又增加了一个管理维度，同样，每个用户在不同的项目中可以拥有多个不同的Role。

1.6 JIRA权限设置

权限是系统中界定用户行为边界的重要概念，JIRA系统中的权限也是以Scheme的方式进行管理的，JIRA中分为Global Permission和Project Permission Scheme两种不同的权限类型。

1.6.1 Global Permission

全局权限是对于整个JIRA系统而言的，全局权限中可设置的行为较少，打开导航栏Users->Global Permissions显示出当前的全局权限页面，全局权限在当前JIRA版本中仅有7项，仅能通过Group的方式进行添加。

1.6.2 Permission Schemes

而Permission Schemes则属于JIRA中与Project相关联的，打开导航栏Issues->Permission Schemes就可以显示所有的权限Scheme列表，并对其中的每项权限可进行简单设置。

JIRA中所有的权限行为比较确定，单击某个Scheme就可以显示当前所有权限行为，并进行显示，Grant permission就可以为某类用户动作分配相应的权限。可以看到分配权限是比较自由的，可选用户既可以按照Group, Project Role，也可以按照具体某个用户或Reporter, Assigner分配。

1.6.3 Workflow中的Validators

前面两节中介绍的行为都是在JIRA中已经定义好的权限进行控制，如果在工程中自定义的工作流如果想要进行权限控制，该如何进行操作呢？这就要用到Workflow编辑器中Transition的Validators进行验证了，在Status的连线Transition的编辑器中，选择Validators标签，增加Validator进行权限验证即可满足这样的需求场景。

1.7 JIRA通知设置

1.7.1 Notification Schemes

JIRA系统会在某些行为发生时，给相应人员发送通知，告知其某个问题状态的改变，具体设置在导航栏Issues->Notification Schemes，建立相应的Scheme并分配至Project上。

单击某条Notification Scheme就可以对其通知类型进行设置，在JIRA系统发生的指定事件被触发时，通知相关用户（发邮件），Notification Scheme同样也是关联Project中的。

1.7.2 Workflow中的Post Functions

前一节中介绍都是在JIRA中已经定义好的事件发生后发生的行为，如果在自定义Workflow中想加入额外的通知机制该如何处理呢，这个需求与权限模型中所讲的比较类似，这就要用到Workflow中的PostFunctions进行自定义事件通知了，同样是在Status之间的Transition上选择PostFunctions页签，就能够看到当前所有已经定义的事件，还可以加入自定义编辑的事件进行处理。