开工的第一周,我们小组开发工作流程有了新的变化,以前都是基于腾讯的 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
本文分享自 pythonista的日常 微信公众号,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体同步曝光计划 ,欢迎热爱写作的你一起参与!