需求已经记录在JIRA里面，在排期批量发版的情况下，存在如下场景：
1.发版日期根据定期常规发版安排已经确定，每隔双周或者三周发版，在春节，国庆节时以及特殊时期也有间隔4周的安排。以上无论如何安排，目前在多数金融企业，发版日期得到提前确定。
2.在排期计划时，把故事/需求（下文用故事）排入对应的日期版本。
3.临近发版日，锁定需求范围。
4.一个故事可以需要修改1个或者多个应用（指独立部署单元，比如Java里面的war包），部署指定的应用到不同目的的测试环境，进行各种类型测试，也有多个应用联合部署一起测试。
5.更加临近发版日，各项新功能测试通过，代码封版。
6.最后阶段待发布需求对应的全部应用大联合测试。
7.得到待发布全部应用清单，按合规等要求，进行需要的发布审批。
8.确认各种测试全部通过后，申请具体应用投产发布，配套提供相关测试报告为主的各项材料。
9.生产环境运维团队执行投产发布操作。
10.开发团队在技术上验证投产。
11.产品经理团队在功能上确认生产环境上线。

期望：以上步骤尽可能自动化，减少手工操作，规避人为失误。
JIRA原生的版本状态只有2个：未发版和已发版，在版本范围锁定和封版时不能限制版本对应变化。因此值得扩充其功能。

基于JIRA的版本管理-方案

要达成1/5当中高度自动化并且能够结合源代码工具采用PAFlow（类同AoneFlow，但版本分支缺省只有一根，测试发版都在该版本分支）进行管控，具体场景演进如下：
1.在JIRA里面设置整体版本号，不设置应用版本号，也就是说这里区分二级版本：整体版本和应用版本。因为应用有多个，故事可能需要多个应用，所以如果故事上设置应用版本的话，需要设置多个版本，这太麻烦，而且这些应用版本都是同时发布，是没有必要的。
2.在JIRA里面将故事设置到版本后，当故事启动编码时，检测对应的版本分支是否已经建立，如果没有，以版本号为名建立版本分支；以故事的JIRA KEY为名建立故事分支。
3.只允许故事（或者包括及其下属子任务）的经办人提交代码。在故事提交测试时，确保故事分支合并到版本分支，并且留下code review记录。
4.对版本进行状态机管理，当版本到达范围锁定后，不允许新故事启动。
5.当版本到达封版后，禁止代码提交。这里管控对象细致到应用，由于封版后测试，在多应用开发下，难以保证同步，更加难以保证同步解封。
6.对应用当前版本出具测试通过报告，该应用版本状态流转到“测试通过”。
7.版本经理进行检查，该应用版本对应故事都测试通过，有相应报告，检查无误后，流转该应用版本状态到“待上线”。自动遍历该应用版本对应所有故事，如果故事上所有应用版本都待上线了，跟踪该故事到“待上线”。
8.生产环境运维组进行投产发布，发布后自动通知相关人员，自动流转该应用版本状态到“已投产”。
9.开发人员进行线上校验，跟踪版本状态到“投产验证”，自动遍历该应用版本对应所有故事，如果故事上所有应用版本都投产了，跟踪该故事到“完成”。
10.所有应用版本状态得到展示，确保跟踪到“完成”，供版本经理进行检查。
以上操作里面有复杂的两级版本状态管理，还有与代码分支管理联动，这些都超出了JIRA的功能范围，因此需要一个新工具来处理这些。这个新工具需要链接JIRA和源代码工具，并且开展版本管理。

DevOps基于JIRA的版本管理-新工具首期故事

根据以上方案，新工具成为JIRA和源代码工具（实例中是Gitlab）之间的桥梁。
为了对接，在JIRA上配套首期故事有：
1.新增如同JIRA原生component字段的应用字段

2.在特定JIRA空间里面模仿component字段设置应用字段，以让故事能够选择一个或者多个应用。因为故事以业务功能角度识别，可能需要一个或者多个应用来实现
在JIRA-Gitlab连接工具（以下简称JG）上，配套首期故事有：
1.注册JIRA空间，让JG知道监控那个JIRA空间和对应的Gitlab库（补充说明：JIRA空间里面从应用字段选项列表可以得到应用列表，根据应用代号可以在另外一个工具里面查询得到其Gitlab库地址）。
2.得到指定版本的待发版应用清单，得到有如下字段的列表：应用名称，版本号，关联故事清单，比如：
应用AB，系统X_191017，带JIRA Key的故事清单。
注意这里的版本号系统X_191017是整体版本号，里面含有多个应用，这个版本号与应用组合在一起才是精确标识了指定应用版本。

3.得到指定应用版本的信息，包括有：

  • 其中的故事清单
  • 计划提测时间，实际提测时间，计划/实际封版时间，计划/实际发版时间等等
  • 当前状态
  • 实际精确版本清单，未来可以链接到具体测试

等等。