技术团队开发与发版规范

迭代

1. 公司层面的迭代周期是 1 个月（跟 KPI、绩效挂钩），产研团队将 1 个月划分成两个小迭代，月初由产品和技术共同制定本月的需求列表（其中产品需求主要由产品主导，技术协助评估，技术需求由技术团队自己制定），这些计划列表构成每个团队和个人的月 KPI 指标，月末回顾完成率与完成质量，综合考虑评估每个团队和个人的 KPI 情况；
2. 月计划列表中的需求项根据重要性分为高、中、低级别，级别越高需要越优先完成，其占团队和个人 KPI 比例也越高；
3. 一个月分为 S1 和 S2 两个迭代，原则上每个迭代两周，在需求和任务分配时会明确指定其所属的迭代以及 deadline（提测、上线）。一般 S1 需求的提测时间（如果需要测试人员参与的话）在每月的 12 - 15 号，上线在 16 - 20 号。S2 需求提测一般在 18 - 24 号，上线在月末之前；

需求

1. 从需求类型上分为产品需求和技术需求。产品需求由产品提出（需求来源：客服、运营、用户），产品经理跟进；技术需求主要针对系统技术层面的优化，由技术人员提出、技术经理跟进；
2. 从需求接收方式上分为迭代需求（计划需求）和临时需求（绿色通道需求）。迭代需求月初由产品、技术通过评审会议确定放入月迭代列表中，作为产研团队、小组以及个人月 KPI 的重要依据。临时需求是月中由产品或其他需求方临时提出的、紧急的（一般是走绿色通道的）需求，产研团队根据目前任务饱和度决定是否要调整迭代需求列表（即划掉某些优先级较低的需求）；
3. 未经评审的需求放在需求池里面（主要是产品人员关注），评审通过并决定要在本月开发的放入发布计划里面（设计、产品、研发、测试等都会关注）；
4. 需求评审：小的需求评审一般是产品 + 相关技术人员参与，中大型的需要技术经理、测试人员甚至包括产品总监、技术总监的参与。需求评审大体分为产品评审和技术评审两个环节，产品评审由产品人员内部进行，主要考察产品层面的可行性，产品评审通过后进入技术评审，至少要有一名技术人员参与，主要考察技术实现可行性；
5. 跨迭代的需求一般需要拆分成多个子需求，分迭代实现；
6. 需求要拆分成若干个任务分配到具体的责任人（策划、设计、研发、测试）。其中技术任务由技术经理拆分并分配到技术人员（也可能是技术人员自己认领的）；
7. 技术任务分配原则：由技术经理和相关开发人员共同讨论解决方案并评估工时（人天），一般技术经理会根据每个人的工时饱和度 + 熟悉度综合考虑任务分配；

开发

1. 开发人员接收到任务后，自己根据实际情况 + 需求优先级安排开发；
2. 开发人员和需求处理人需及时变更相关任务和需求的状态，确保需求能够及时流转；
3. 团队在每日站会碰头，每个人阐述自己昨日工作、今日计划、整体进展。站会建议控制在 15 分钟以内；
4. 针对每个需求，开发人员需要从 master 拉取独立的分支开发，不可在同一个分支上开发多个需求，因为这样会导致多个需求相互影响，无法独立发版；
5. 对同一个项目的同一个需求，不同的开发人员建议都使用同一个分支开发（如前后端人员），避免相互合并代码的麻烦；
6. 创建开发分支：

	- git checkout master
	- git pull --rebase
	- git checkout -b feature-songlin-coupon-list
	- git push -u origin feature-songlin-coupon-list

1. 同一个需求涉及到多个开发者（甚至是跨团队）时，需要有一个主负责人。主负责人负责协调大家进度，统一提测、上线事宜；
2. 当某个项目发布生产并合并到 master 分支后，该项目的其他开发人员应当及时将 master 最新代码合并到自己的开发分支；

提测

1. 某个需求的所有方面都开发完成并自测/联调通过后，由需求主开发负责人统一写提测邮件；
2. 提测邮件内容：
   • 标题：【提测申请】需求名称
   • 收件人：测试组
   • 抄送人：研发组、相关产品人员
   • 正文：
     1. 概括说明本需求内容；
     2. 对应的需求链接；
     3. 项目（git 和中文名称）、分支；
     4. 开发、产品人员列表；
     5. 需测试的功能点提示列表（特别是隐藏功能点）；
     6. 其他注意事项说明；
3. 提测后，主开发负责人需要及时变更需求状态，改为“已提测”，相关开发人员需要及时变更自己的任务状态；
4. 提测后，相关开发人员可着手处理其他任务，但需要及时关注测试动态，对于测试提出的 bug，需第一时间解决，或者跟测试沟通紧急度来协商解决时间。原则上，应当在一天内解决。不可因 bug 长时间未得到解决而影响测试进度进而影响整个项目进度；
5. 测试人员测试通过后，会回测试通过邮件，开发人员收到此邮件后，需及时准备预发布；

预发布

1. 主开发负责人收到测试通过邮件后，需及时准备预发布事宜。
2. 从最新的 master 分支拉取 release 分支：

	- git checkout master
	- git pull --rebase
	- git checkout -b release-20200313.01 # 如果当天已经有其他发版了，就接着往后编号，创建的分支不可与已有分支冲突
	- git merge --no-ff feature-songlin-coupon-list # 合并自己的开发分支
	- git push -u origin release-20200313.01 # 推送到远程仓库

3. 在提测邮件的基础上写预发布邮件：

   • 标题：【预发布申请】需求名称
   • 收件人：运维组
   • 抄送人：测试组、研发组、相关产品人员
   • 正文：
     • 告知运维，测试已完成，申请发布预发布
     • 项目：项目名称（git 仓库名称）
     • 分支：release-20200313.01
     • commit: 308d0bf831acb149a0dc5e348f83cef25adafd0a（目前我们采用分支发版策略，没有使用 tag 策略，所以同时要提供 commit）
     • 以上“项目、分支、commit”，如果涉及多个项目，按照发版顺序依次列出
     • SQL 语句（如果有。如果很多，需要以附件提供。需提示 SQL 执行风险）
     • 其他事项说明
   • 例如：

   hi，运维：
   测试通过，麻烦发布到预发布环境验证。

   1.财务结算系统（负责人：张三）
   分支：release-20200313.01
   版本：e4371a569affe13862561b7aa3d5b939c9216aa7

   2.券系统（负责人：李四）
   分支：release-20200313.02
   版本：9aca2d369826fd294b77fc23499d43654525212f

4. 运维发布后，由测试人员测试。

生产

1. 测试人员在预发布测试通过后，会回复测试通过邮件；
2. 主开发人员收到测试通过邮件后，需及时编写上线申请邮件：
   • 标题：【上线申请】需求名称
   • 收件人：运维组
   • 抄送人：测试组、研发组、架构组、相关产品人员、其他利益关系人（如运营）
   • 正文：
     • 告知运维，预发布测试完成，申请上生产环境，自评发布风险（低、中、高）
     • 如果相对于预发布环境的 commit 有变动，则要重新在此说明（原则上不允许）
     • SQL。如果很多，则以附件提供。评估 SQL 执行风险
     • 如果有多个项目，说明发版顺序
     • 回滚方案
     • 其他注意事项说明
3. 上线申请邮件需要技术经理审批，高风险发版需要研发总监审批。技术经理需要审核分支代码（如是否 master 最新代码、是否有明显的错误等）、发版流程、SQL、发版是否冲突，并评估发版风险，给出发版时间建议。一般低风险可以在白天非高峰期发布，中、高风险需要在晚上 11 点以后发布；
4. 上线后，开发和测试人员需及时验证，并密切关注外部反馈，有问题及时回滚；
5. 上线成功后，由各项目负责人将发版的 release 分支代码合并到 master，并在群里告知团队成员；

附

参照Git 分支管理实践