接下来会以 提高用户价值的流动效率 为核心，列出一些具体的研发流程优化实践
代码入库前
代码入库之前的开发活动，主要包括编码、调测调优、静态检查、自动化测试、代码审查等。这是开发者编写代码的步骤，自然是提高研发效能的关键环节。
代码集成越晚发现问题就越晚。这正是产品上线的最后关头合并混乱，产品质量差、返工率高的一个重要原因。
规范化、自动化核心步骤
- 获取开发环境，包括获取开发机器、配置环境、获取代码等。
- 在本地开发机器上进行开发，包括本地的编码、调测、单元测试等。
- 代码入库前，把改动提交到检查中心（比如 Gerrit），再进行一轮系统检查，主要包括代码检查、单元测试、代码审查等，通过之后再入库。
对应的有三个实践：
- 提高开发环境的获取效率。把整个开发环境的获取，进行服务化、自助化。
- 规范化、自动化化本地检查。根据团队实际情况，找到合适的工具和配置进行这些检查，并让团队成员统一使用。
- 建设自动化代码入库前的检查流程。比如merge request代码审查、使用 GitLab 提供的 GitLab CI/CD 框架自动化运行各种代码检查工具
提供快速反馈，促进增量开发
提供快速反馈，进行增量开发指的是，能够快速验证已经完成的开发工作，说白了就是边开发边验证。
- 灵活使用各种 Linter 和测试。最常用的快速验证方法就是，提高运行静态检查和测试的方便性、灵活性。各种语言、框架都有自己的测试框架和 Linter，根据语言自行设置
- 使用实时检验工具。最常见的是，IDE 中的实时语法检查。我们可以花一些时间来配置 IDE。另外，有些工具可以自动监视文件系统的变化，文件有变化时自动重启服务。这对于开发者来说，非常便利。
代码入库到产品上线
三个持续
持续集成：在团队协作中，一天内多次将所有开发人员的代码合并入同一条主干，推荐Trunk Based主干分支模型
- 它能够帮助开发人员尽量早、尽量频繁地把自己的改动推送到共享的代码仓库分支上，进行代码集成，从而减少大量代码冲突造成的低效能问题
- 更快地服务客户，以更快的试错速度寻找到用户，提供真正对客户有价值的功能
- 产品发布到不同环境的过程中，我们会提前发现一些在开发和持续集成中没有暴露的问题
问题：如果有跨多个发布周期开发的功能，有两种处理方式，一是功能开关，但会引进更多逻辑，二是放弃持续集成，那就需要开一个新的功能分支开发（功能分支模型）。所以团队中使用哪种分支模型需要按下图进行判断：
持续交付：一种软件工程方法，在短周期内完成软件产品，以保证软件保持在随时可以发布的状态
目标是，对每一个进入主干分支的代码提交，构建打包成为可以发布的产品。对每一个提交，把集成后的代码部署到“类生产环境”中进行验证。如果代码没有问题，后续可以手动部署到生产环境中。
持续部署：将每一个代码提交，都构建出产品直接部署给用户使用
值得一提的是，跟持续交付一样，Facebook 的持续部署也不是纯粹的持续部署。因为代码提交太多，他们并没有每个提交都单独部署，而是采用类似持续交付的方法，把一段时间之内的提交一起部署。这种不教条的方式，是 Facebook 到的一个重要的做事方法
三个原则
基本原则 1：流水线的测试要尽量完整
CI/CD 流水线的测试只有尽量完整，代码和产品的质量才能有保证。所以，最主要的工程实践，就是在流水线中运行大量高质量的测试和检查。
基本原则 2：流水线的运行速度一定要快
- 使用并行方式运行各种测试来提速
- 投入硬件资源，使用水平扩展的方式来提速
- 使用增量测试的方式进行精准验证。也就是说，只运行跟当前改动最相关的测试，以减少测试用例的运行数量
- 让开发人员在本地也能运行这些测试，从而使用本地资源尽早发现问题
- 运行测试的时候，按照一定的顺序运行测试用例。比如可以先运行速度快的用例，以及历史上容易发现问题的用例
基本原则 3：流水线使用的环境，尽量和生产环境一致
- 软件包最好只构建一次，保证各种不同环境都用同一个包
- 使用 Docker 镜像的方式，把发布的产品以及环境都打包进去，实现环境的一致性
- 尽量使用干净的环境。比如，测试时，使用刚从镜像产生的系统；又比如，使用蓝绿部署，每次产生新的部署时，直接丢弃旧的环境。
