新的软件开发流程学习总结

开工的第一周，我们小组开发工作流程有了新的变化，以前都是基于腾讯的 coding 作为代码管理平台以及版本任务的分配，现在是改成使用 Bitbucket 和 Jira，用 Bitbucket 管理我们的代码仓库，Jira 作为版本任务的分配以及发版。

Jira 更直观的看到版本任务完成情况，比如哪些任务没完成，任务关联的开发人员是谁。它可以和 Bitbucket 联动，在Jira 上创建一个任务，在这个任务可以关联代码某一个分支，这样代码 review 很方便，可以知道这个代码分支完成了哪件事。

变更后的软件研发流程

新里程执行的前提:

每一个需求都要提前上系统工具（Backlog)，不再是缺陷上记录，我们必须要自己还需要做多少，要不然每次都会临时。

研发任务需求管理:

测试人员与SM一起将PO涉及的需求定义转化为Epic，Task，SubTask等录入 Jira 系统，并将所有的 Task 全部记录在Backlog中。

开展Scrum Planning Meeting，这个会议会很长，将所有相关人员集中在一起，详细讨论需求，优先级，工作量，从Backlog中，挑出优先级高并且重要的任务，进入Spint Backlog。Sprint Backlog就是我们的边界，我们需要严守边界，不能在研发过程中出现 Scope Creep 的情况

开展Scrum Review Meeting 去验证当前Scrum 周期内，所完成的任务是否满足PO的要求。当出现不能满足的新需求，除去P0与P1时，需要优先进入Backlog，走下一个Sprint的流程。

代码管理机制:

每一个项目的代码仓库将存在两个默认分支，

- Master 分支：专门用来发布版本，每个版本

- Developer 分支：专门用来研发的分支，所有的Task与Bug的修改都需要以这个分支为base，Checkout出来。

Task/Bug代码流程：

1. 在项目管理工具上添加一个问题，并记录下来，指定迭代版本，并指定执行人；

2. 执行人，基于当前的问题，于所需要的项目中，从代码仓库的创建一个新的分支,在JIRA的任务上就可以直接创建代码分支；

1). 新分支的名字，<分支属性>/<问题ID>-<问题描述>

2). 执行人在新的分支上进行修改，完成后并提交到当前分支上；

3). 从问题分支向developer分支，提交合并请求；

3. 由项目指定人员，对提交的合并请求进行代码审核加review，没问题后，将代码合并到Developer分支。

版本发布流程：

1. 代码级别上：

- 从Developer代码提交Pull Request到Master分支；

- 通过Master分支的tag发布版本，并直接触发我们自己的CICD流程

- CICD的流程，对每一个微服务生成自己的Docker Image，Docker Image 的tag对应上代码Commit 的Tag。

2. 部署物本身：

- 通过CICD流程，对每一个微服务生成自己的Docker Image，Docker Image 的tag对应上代码Commit 的Tag。

- 在Deploy Repo中，修改版本的Helm Chart 形成一键部署版本。

- 将Helm Chart版本，自动化打包发布出来。

- 对大版本的Helm Chart只保留LTS版本，对正在研发的版本，保留所有的已发布版本的Helm Chart