作为软件行业的从业者对Jira的概念都不会太陌生，大家都应该在Jira上创建和操作过自己的任务。做为一个任务跟踪工具，Jira内置的workflow和管理员工具基本可以满足我们日常的工作。但是如何才能发挥出Jira的最大价值，结合企业自己的需求去挖掘Jira更高级的应用呢？我打算以一个案例，分为3期来深挖下Jira的高级应用方式。
Jira高级应用—设计篇
如何利用Jira来优化工作流程，提高工作效率
Jira高级应用—实战篇
手把手教你如何成为合格的Jira管理员
Jira高级应用—集成篇
如何通过调用Jira的RestfulAPI实现任务的全自动任务跟踪。
案例：
我们公司对Jira依赖程度还是很高的，基本每天一两千人在线使用，对于Jira的定位基本就是任务跟踪，依靠Jira的工作流完成任务的分发。我现在想做的是通过jira将软件的发布全生命周期管理起来，从研发提交git的tag到应用上线后的运行情况，统一由Jira做为数据中心和控制中心，将涉及到的所有人员串联起来，一起高效的完成发布任务。
第一步：根据企业自己的特色梳理标准的发布流程
这是我梳理出来的应用发布workflow
环节及相关人员：
0 发起申请（研发负责人）
研发决定要更新某个应用的版本，在git上提交tag。
1 等待构建（Jenkins自动构建）
Git触发Jenkins的任务对本次软件包进行编译
2 环境部署（业务运维）
云平台上启动一个实例，将新版本的软件包部署上去，并准备好运行环境。
3 测试验证（测试负责人）
对新版本的功能进行验证，对老功能进行回归。
4 灰度发布（业务运维）
按很小的比例替换掉线上的服务，一般替换1-2台
5 灰度观察（测试负责人）
观察新版本1-2台机器的运行情况，一半观察1小时
6 全量发布（业务运维）
将新版本全量替换线上的老版本
7 全量观察（测试负责人）
观察线上运行情况，一般观察4-8小时。
8 上线成功（研发负责人）
研发负责人确认本次上线是否达到预期
9 故障（业务运维）
新版版在线上运行一段时间后出现故障，需要解决
10 灰度回滚（业务运维）
灰度发布或者灰度观察不通过时，需要将灰度的机器回退到老版本
11 全量回滚（业务运维）
全量发布或者全量观察不通过时，需要将所有线上机器回退到老版本
12 上线失败（研发负责人）
本次软件发布因为各种问题，没有成功。
核心参数
版本相关：
git中项目名，git_tag
人员相关：
研发负责人，业务运维负责人，测试负责人
时间相关：
发起申请时间，构建完成时间，测试验证完成时间，灰度发布完成时间，灰度观察完成时间，全量发布时间，全量观察完成/上线时间，Reopne时间/故障发现时间，故障解决时间，灰度回滚完成时间，全量回滚完成时间
结束状态：
上线结果（成功，失败）
上线失败原因（构建失败，部署失败，测试失败，灰度发布失败，全量发布失败，因故障回滚， 废弃）；
发起方式：
人工，系统自动
第一阶段达到的目的：
1让整个研发、运维、测试团队熟悉产品发布的workflow
2 先手动使用起来，当然设计上要求人工填写的东西越少越好，例如状态、时间点、人员转发等都需要自动完成，只需要人工点击不同的按钮决定workflow的下一步走向就好。
3 workflow运行一段时间后就会收集到各种结果和时间信息，基于这些信息就可以做统计报表，可以作为人员工作量饱和度和工作效率的考核依据。
4 可以根据报表中反馈的各环节的效率情况，决定如何对workflow进行优化。
统计参考价值
1 因编译和测试不通过导致jira任务的失败，可作为研发代码质量的参考；
2 因观察未通过导致jira任务的失败，可作为测试质量的参考；
3 回滚率反应团队整体工作能力的参考；
4 单位时间内完成应用升级的个数可作为工作量饱和度的参考；
5 各环节中间时长可作为工作效率的参考。
第二步：发布流程如何实现
这一部分将放在下一篇博文中，重点介绍如何实现第一阶段的设计，其中重要涉及到：Jira新项目的创建、workflow的绘制、页面排版、插件安装、自定义字段、自定义问题类型、权限控制、环节提交校验等。
第三步：如何实现自动化
为了提升生产力，利用Jira的RestfulAPI我们进一步将工具与Jira打通，这样就可以实现软件发布全生命周期的自动化运转。例如研发提交Git后会自动创建Jira任务，Jenkins构建完成后会自动提交到下一阶段，集成测试完成后自动提交到灰度阶段，甚至是上线成功后告警系统自动发现故障后会将Jira任务转移到故障阶段等等，总之就是将人工干预的比例降到最低。
以我们公司的自动化程度，预计可以做到80%-90%，如图
蓝色的环节是可以自动化实现的环节，紫色的部分代表自动化工具和对应的生命周期。
自动化如何设计？如何开发Jira的客户端代码？ 我也将会在后续的博文中与大家一起分享。