前言：在产研全链路流程上，协同最大的目标就是团队信息的透明化，即在清晰目标的指引下进行团队信息透明的日常研发工作，助力项目/产品成功发布。基于此，研发过程是否行之有效就成为我们关注的另一重点要素。通常「研发过程」是指：代码到制品再到部署上线的全链路，这个过程是持续集成的重中之重。
本期主要围绕「研发过程」展开探讨，在具体分享实践之前，笔者想先和大家畅想讨论下，在软件研发全流程中，我们需要怎样的产品和特性来支撑我们持续去追求高效研发（本期主要围绕成本、效能，质量这块后续单独再做分析）的目标，个人思考了几点内容（部分内容会在正文的实践分享中详细说明），在此抛个砖让欢迎大家一起探讨。
思考一 支持团队把实践和文化通过自定义配置方式沉淀。
所有团队成员在使用产品功能的过程中，会潜移默化按照团队希望的实践路线进行。一方面，团队的研发是按既定路线进行的，研发效能是可预期的；另一方面，团队新人也能快速融入到团队开发模式中，快速融入团队文化。
思考二 在软件研发全链路中，应该具备高度自动化的能力。
研发全链路工作流中的各节点，通过高度自动化的能力，能实现以下目标：
- 除代码开发和项目管理事项信息录入外，尽量减少登录平台的手动操作；
- 自动精准消息的推送，借助端的能力，让用户本地异步订阅查看研发和项目管理信息。
思考三 强大且丰富的端能力。
让研发成员能够在本地沉浸式开发，目标要做到不感知 DevOps 平台存在的情况下，无时无刻不在使用平台能力。
思考四 产品能力和形态应该能够高度自定义化。
想通过一种产品形态去支撑覆盖所有的行业是不现实的，一个 DevOps 平台研发团队，不可能深入了解熟悉各行各业的研发模式，更不可能去定义实践去引领所有行业的研发提效。平台能做和需要做的是：把平台底层基础能力做强、做灵活，让不同业领导者，在高效持续交付的理论引导下，利用平台丰富的基础能力和高度自定义配置能力，去构建属于自己行业的研发实践模式，最终通过行业研发实践模式沉淀模版的可复制化，助力该行业整体研发效能的提升。
思考五 平台需要深度结合低代码开发平台，让应用研发变得更简单。
思考六 借助 AI 的能力，辅助提升用户代码开发、质量、安全、问题定位等应用研发过程效能。
思考七 结合大数据、AI、函数计算等技术特性，让研发效能度量、运维监控等观测能力变得更强大。
- 通过公有云或者企业级大数据、AI 和底层云计算能力的对接，让研发效能度量、监控数据统计的成本变得更低；
- 通过函数计算以低成本的方式满足用户对研发效能和监控数据的灵活统计诉求；
- 通过低代码开发平台 DevOps 平台底层 Tracing、Logs、Metrics 函数计算 数据可视化，让用户能够快速构建行业最佳实践的监控运维系统，通过模版可以复制到其他行业用户。
言归正传，接下来我将主要从「研发全链路」出发，分享一下 Erda 团队具体的实践过程，希望能给大家带来新的思考。
基于主干的开发模式
在研发模式方面，Erda 团队采用的是基于主干开发模式（Trunk Based Development），相对于主干开发模式还有特性分支开发模式（Feature Branch Development），其典型的代表就是 gitflow 模式。两者都是软件届常用的软件分支模式，各自有着各自的优缺点，选择适合自己的才是最重要的。Erda 团队选择基于主干开发模式的初衷，是想以持续集成的方式尽快发布版本，以及希望通过主干开发模式促成团队成为精英绩效团队。
Erda 团队基于主干开发的目标：
- 每日有新代码合入主干，每日完成持续集成、持续测试
- 随时随刻能够提供可发布的版本，特性可以按需紧急发布上线
- 产品特性快速实现验证，减少试错成本
为了让团队通过主干开发模式来实现上述的目标，有两个实践要点非常重要：
- 项目协同的高要求：任务拆分（参考迭代事项协同中的任务颗粒度建议，尽量拆分到 1-2 天）需要足够小驱动 mr 变小，从而能从项目管理上支持产品特性快速实现验证和试错；
- 研发质量的高要求：特性开发的快，不能是牺牲质量的快，所以在这个快的前提下，对于合入的特性代码要求就会变的更高，这里的关键就是开发需要确保代码质量，不要想着把质量交给测试团队来保障 (建设自动化流程对规则、标准、规范进行自动检查；单元测试；数据库规范等等）。
实践要点分析后，接下来一起看看具体的实践步骤以及需要怎样的 DevOps 平台工具来支撑。
基于主干分支的代码研发
通过项目协同把需求进行任务拆分，研发同学认领任务后即进入开发工作，开发的首要工作就是创建一个特性分支（Feature/ 任务 ID）用于该特性的代码托管。OK，对于团队新成员来说可能开工第一步问题就来了
