项目开发到部署，流程总结

开发

第一个阶段就是开发的阶段，首先要考虑的是做哪些功能或者调整 BUG 的顺序，根据任务的紧急程度进行划分

需求安排

紧急程度

应有个整体的需求清单的列表， 并且使用严格的紧急程度来区分

• T0 非常紧急的 BUG 类问题 (严重影响用户体验和使用的)
• T1 明确规划上线时间的新增需求或者功能
• T2 用户提出的建议优化修改
• T3 一些新的方向和领域的探索 (例如新技术，webGPU，webGL，C++构建渲染库，团队需要学习和研究的方向)

辅助工具

如: redmine , jira, teambition,等等任务管理管理的工具

就目前公司的情况而言，我觉得启用企业邮箱是一个可以实行的方向, 需要一个自动即时能通知相关人员有任务分配到自己 目前我司使用的 Jira 可以正常发送邮件到员工的私人邮箱，最好是可以对接到钉钉或者企业微信

代码合并

为了保证代码的质量和稳定，要求合并代码的人员必须完整的review每一次的代码提交, 这个必然会增加代码合并人的工作量，建议从工作量上面进行调整。 对专门负责review的人员，减少其开发任务，来保证每次 BUG 的修改和新功能的添加都是至少经过两个开发人员的考量。

Tag 建立

对于 Tag 的建立，也就是版本的建立 除了初期的规划的版本的发布和时间节点。中途肯定也是会穿插一些紧急的 BUG 修复的发布。 如果所有任务都如期完成，顺风顺水。那么一切按正常发布即可。

正常发布

开发完成后，开发初步自测，自测完成创建 tag，开发给测试人员提供changelog, 测试人员进行集成测试和回归测试。

• 测试通过，作为release正常上线发布
• 测试不通过，将此 Tag 标记为测试不通过，提交T0的修复任务，第一时间修复相关问题。然后再次增加版本号，重新建新的 tag 进行正常发布的完整流程

紧急发布

对于严重影响用户体验和用户使用的BUG, 应当出已经发布了release的最新版的代码拉出一个修改的分支，修改完成后，抛弃还未测试的tag, 将包含这次提交的代码作为新的tag，按顺序增加版本号。 然后进行正常发布流程。完成后，需要将之前release那个版本号标记为不稳定的。

紧急发布会打乱原本的已经在进行到一半的tag的测试环节。明显会增加各个部门的工作量。但是一旦正常发布能够稳定后，出现紧急发布的情况应该是非常非常少的。甚至可能没有。

以上是针对可以快速被解决的紧急修复。如果是需要长时间来进行代码修复的。那么最好的方案是回退上一个稳定版本。 将该 BUG 在后续的版本进行修复。

测试

单元测试

对于公共库和辅助函数等方法，写好单元测试用例，保证基础函数和方法的稳定性。后期如果有相关改动的话，也更容易发现是否被引用的地方造成影响。可以让代码的后期维护可控性有较大的提升。

集成测试

回归测试

主要测试需要进行的部分，对于测试人员已有的测试用例，针对 changelog 添加新的测试用例后，整体进行跑一次测试用例。 当然如果代码模块拆分的话，可以减少测试人员的回归测试用例的数量。需要针对模块的进行单独建立测试用例。 更推荐实现自动化测试方案，利用机器来测试对应模块，减少人员手工测试过程中产生的误操作。

部署

自动化

自动化部署，主要是针对jenkes等构建工具，配合上git hook进行自动化发布。 对于master分支应该是针对release后的最新代码才会合并到master分支。利用release的最新发布或者master分支的变化来出发正式环境的自动trigger构建任务并且自动发布。

安全相关

运维人员需要考虑服务器的安全问题和代码可能出现的安全问题。 例如生产环境不应该出现sourcemap文件。对于服务器的防火墙的相关配置和设置应该是有规划的。 减少使用root账户进行服务的启动和部署。各个服务的启动和用户权限的划分有明细的规定。

一票否定

即便是完全通过测试的版本，待发布的 tag 中。如果有任何产品或者测试，遇到任何新的异常，即便是非常小的异常。 也许要停止该版本的发布，直到找到该问题的根本原因，或者是该问题确定被解决。或者在一定的数量级别上，该问题无法复现的情况下， 该版本可以继续发布。

特殊情况 特殊处理