前言：在产研全链路流程上，协同最大的指标就是团队信息的透明化，即在清晰指标的指引下进行团队信息通明的日常研发工作，助力我的项目 / 产品胜利公布。基于此，研发过程是否卓有成效就成为咱们关注的另一重点因素。通常「研发过程」是指：代码到制品再到部署上线的全链路，这个过程是继续集成的重中之重。
本期次要围绕「研发过程」开展探讨，在具体分享实际之前，笔者想先和大家畅想探讨下，在软件研发全流程中，咱们须要怎么的 产品 和个性 来撑持咱们继续去谋求高效研发（本期次要围绕老本、效力，品质这块后续独自再做剖析）的指标，集体思考了几点内容（局部内容会在注释的实际分享中具体阐明），在此抛个砖让欢送大家一起探讨。
<u> 思考一 </u> 反对团队把实际和文化通过自定义配置形式积淀。
所有团队成员在应用产品性能的过程中，会耳濡目染依照团队心愿的实际路线进行。一方面，团队的研发是按既定路线进行的，研发效力是可预期的；另一方面，团队新人也能疾速融入到团队开发模式中，疾速融入团队文化。
<u> 思考二 </u> 在软件研发全链路中，应该具备高度自动化的能力。
研发全链路工作流中的各节点，通过高度自动化的能力，能实现以下指标：
- 除代码开发和项目管理事项信息录入外，尽量减少登录平台的手动操作；
- 主动精准音讯的推送，借助端的能力，让用户本地异步订阅查看研发和项目管理信息。
<u> 思考三 </u> 弱小且丰盛的端能力。
让研发成员可能在本地沉迷式开发，指标要做到不感知 DevOps 平台存在的状况下，无时无刻不在应用平台能力。
<u> 思考四 </u> 产品能力和状态应该可能高度自定义化。
想通过一种产品状态去撑持笼罩所有的行业是不事实的，一个 DevOps 平台研发团队，不可能深刻理解相熟各行各业的研发模式，更不可能去定义实际去引领所有行业的研发提效。平台能做和须要做的是：把平台底层根底能力做强、做灵便，让不同业领导者，在高效继续交付的实践疏导下，利用平台丰盛的根底能力和高度自定义配置能力，去构建属于本人行业的研发实际模式，最终通过行业研发实际模式积淀模版的可复制化，助力该行业整体研发效力的晋升。
<u> 思考五 </u> 平台须要深度联合低代码开发平台，让利用研发变得更简略。
<u> 思考六 </u> 借助 AI 的能力，辅助晋升用户代码开发、品质、平安、问题定位等利用研发过程效力。
<u> 思考七 </u> 联合大数据、AI、函数计算等技术个性，让研发效力度量、运维监控等观测能力变得更弱小。
- 通过私有云或者企业级大数据、AI 和底层云计算能力的对接，让研发效力度量、监控数据统计的老本变得更低；
- 通过函数计算以低成本的形式满足用户对研发效力和监控数据的灵便统计诉求；
- 通过低代码开发平台 + DevOps 平台底层 Tracing、Logs、Metrics + 函数计算 + 数据可视化，让用户可能疾速构建行业最佳实际的监控运维零碎，通过模版能够复制到其余行业用户。
言归正传，接下来我将次要从「研发全链路」登程，分享一下 Erda 团队具体的实际过程，心愿能给大家带来新的思考。
基于骨干的开发模式
在研发模式方面，Erda 团队采纳的是基于骨干开发模式（Trunk Based Development），绝对于骨干开发模式还有个性分支开发模式（Feature Branch Development），其典型的代表就是 gitflow 模式。两者都是软件届罕用的软件分支模式，各自有着各自的优缺点，抉择适宜本人的才是最重要的。Erda 团队抉择基于骨干开发模式的初衷，是想以继续集成的形式尽快公布版本，以及心愿通过骨干开发模式促成团队成为精英绩效团队。
Erda 团队基于骨干开发的指标：
- 每日有新代码合入主干，每日实现继续集成、继续测试
- 随时随刻可能提供可公布的版本，个性能够按需紧急公布上线
- 产品个性疾速实现验证，缩小试错老本
为了让团队通过骨干开发模式来实现上述的指标，有 两个实际要点 十分重要：
- 我的项目协同的高要求：工作拆分（参考迭代事项协同中的工作颗粒度倡议，尽量拆分到 1-2 天）须要足够小驱动 mr 变小，从而能从项目管理上反对产品个性疾速实现验证和试错；
- 研发品质的高要求：个性开发的快，不能是就义品质的快，所以在这个快的前提下，对于合入的个性代码要求就会变的更高，这里的要害就是开发须要确保代码品质，不要想着把品质交给测试团队来保障 (建设自动化流程对规定、规范、标准进行主动查看；单元测试；数据库标准等等）。
实际要点剖析后，接下来一起看看具体的实际步骤以及须要怎么的 DevOps 平台工具来撑持。
基于骨干分支的代码研发
通过我的项目协同把需要进行工作拆分，研发同学认领工作后即进入开发工作，开发的首要工作就是创立一个 个性分支（Feature/ 工作 ID）用于该个性的代码托管。OK，对于团队新成员来说可能动工第一步问题就来了 😓
Feature 的源分支是谁？
团队采纳的是骨干分支的开发模式，天然就是从骨干分支（Master）来拉取了，对于相熟团队开发模式的同学来说，基本就不是问题，新同学只有通过培训或者本人去 google 学习一下也就明确了。
团队的实际和文化诚然能够通过治理标准来进行束缚来实现，不过今人也云“堵不如疏”，是否可能把这些实际标准束缚在产品中定义？通过产品性能交互，疏导用户按团队的预约的实际路线进行。Erda 团队就是这样实际的，成果还不错！
代码开发到提测的整体流程
基于骨干分支开发的标准配置
Erda 团队的研发标准是在产品的研发工作流中进行定义配置，内容波及分支清单、分支策略和工作流配置，具体示意图如下：
Erda 产品 - 研发工作流配置示意图
具体以产品理论交互为主
工作流具体配置内容：
分支策略具体配置内容：
具体过程
- 研发同学在工作详情中，抉择利用一键抉择创立工作流。工作流创立后就会主动创立对应的开发分支（如 feature/XXXX，其中 XXXX 代表个性 ID）；
- 雷同利用雷同环境不同个性进行零碎长期合并部署自测。通过 Erda 平台提供开发环境下雷同利用不同个性分支的零碎长期合并的性能，让所有个性研发同学能够一起部署和冒烟测试，在不影响效率的状况下大幅缩小环境资源的压力；
- 通过研发自测后，工作流中能够一键发动 MR 合并申请，研发 TL 对合并申请相干分支 Code Review 后（因为工作工作流中事项和分支的关系绑定，Code Review 的时候能够清晰晓得本次合并申请的具体任务内容），个性分支主动合入主干分支，骨干分支通过定时 / 代码变更的触发器进行集成部署 + 测试，至此研发同学的个性工作状态也会主动实现。（上述个性正在开发中，目前以手动发动 MR 申请为主）。
基于骨干分支的每日集成部署
通过 Erda 平台来撑持我的项目级每日继续集成部署。通过我的项目流水线，构建各利用最新制品（基于各利用骨干最新代码）并集成为我的项目整体制品进行自动化的部署到对立的骨干测试环境（Erda 叫集成环境）。
部署的策略为每日 23 时，定时触发流水线运行构建、集成、部署 (其余我的项目也能够依据理论状况设定其余的部署策略)。
基于骨干分支的每日继续测试
自动化测试
- 用例治理
依据需要的 deadline，测试同学会基于研发同学的个性实现工夫，去安顿自动化测试用例（次要是是基于 API 接口的测试）和性能测试用例的作成。在研发同学个性分支合并到骨干分支后，测试同学会在原有的测试计划上追加新个性的自动化测试用例，已有的自动化测试用例回归确保之前个性的可用性。
- 自动化测试执行
那么每日继续测试如何触发？
即通过部署测试流水线中的 action，触发自动化测试计划的执行。
- 自动化测试后果告诉
自动化测试后果通过钉钉同步给研发团队。
手动功能测试
自动化测试并不能百分之百笼罩所有的产品个性，而对于自动化无奈笼罩的个性，就须要手动实现。功能性测试是须要实打实投入测试同学人力去一遍遍手动笼罩的，且不说必要性，人力老本可能就是麻利团队所不能容忍的。对于这样的场景，Erda 团队在手动功能性测试方面次要采纳以下策略：
- 针对迭代新性能须要手动功能测试笼罩，次要是测试团队对以后迭代的需要内容进行针对性的测试；
- 测试团队基于需要、工作的状态来判断每日新增的大略内容 (erda 测试团队甚至被要求关注开发提交的 MR/PR，对测试团队的要求是更高的）。
基于骨干分支的制品管理策略
通常意义上的「软件制品」次要是源码文件的汇合或者编译后的产物，次要包含 二进制包 和压缩包 两种模式。如果基于 Erda 平台，制品的概念上略微有点难以区别，咱们次要定义为蕴含部署一个利用所需的全部内容，包含镜像、依赖的 Addon 以及各类配置信息，最终的目标就是通过制品可能在任何一套 Erda 上进行环境级别的部署。
这里临时不去剖析和探讨制品的定义和具体的性能点（如对产品制品治理性能有趣味的同学能够分割咱们持续探讨），还是回归到主题，以分享 Erda 团队对于制品治理的实际为主。
语义化版本治理
首先在制品版本和类型的治理上，团队次要采纳的是「语义化版本」治理标准，次要波及以下几种版本类型：
- alpha：仅仅是研发自测通过，未通过测试的版本，不稳固的版本
- beta：阶段性测试通过，绝对稳固的版本
- stable：通过系统性测试，稳固的公布版本
版本和分支的关系
其次，制品版本和分支上做了强实际的绑定（次要通过研发工作流配置实现）。不论制品如何定义，必定是基于代码或者编译产物的根底，也就是说制品必定是从代码来的。所以 Erda 团队在实践中是把分支和制品类型进行绑定关联的，并且把这个以最佳实际积淀到 Erda 产品中，当然产品反对研发工作流的自定义配置来满足其余个性分支和制品版本类型的关联。
Erda 团队的研发模式是基于骨干研发的模式，所以分支和版本类型的关系如下：
如果采纳 Gitflow 能够参考如下：
版本和分支的配置
分支和制品版本的配置：在研发工作流中配置
次要过程阐明：
- 研发同学在 feature 分支上开发实现后，并在开发环境上实现自测，代码合入到骨干分支（Master）；
- 骨干分支（Master）通过每日定时触发器执行流水线，会主动构建生成【版本号 + alpha + 工夫戳】的制品；
- 迭代版本所有的个性代码都合入到骨干分支（Master），并且通过自动化测试用例及测试同学手动性能阶段性测试后，测试同学会从骨干分支（Master）上切出迭代版本的 Release 分支（分支名：Release/ 版本号 -beta+ 递增数字），工夫频率取决于团队的公布频率（Erda 团队的公布频率是每周，所以这边的工夫频率就是每周）；
- 当迭代版本进行到肯定周期后，产品个别会对外公布一个正式的版本（这个版本能够是下面一个迭代版本，也能够由多个迭代版本组成，这个取决于产品的版本公布打算，Erda 产品的一个大的 Rc 版本由 4 个迭代 beta 版本的个性组成），测试同学会从骨干分支（Master）切出 Release 分支（分支名：Release/ 版本号）进行全面测试；
- 测试同学通过 Release/ 版本号分支流水线构建部署该分支的 beta 制品，在通过测试验证后，测试同学会手动把该 beta 版本制品切换为 stable 版本，并且在制品中保护好制品的 ChangeLog 和制品标签，最终公布到 Gallery 提供的交付团队下载应用。
公布火车
概念和规定
公布火车，通常是指设定固定的公布窗口，具体能够按周或者按月固定一个工夫，在这个工夫进行定时公布，产品个性可能赶上这趟火车就公布，否则就须要等下趟火车。
公布火车的规定看似非常简单，只有固定工夫公布即可，其实不然，团队并不能通过一个公布火车的概念就能让公布变得高效，真正能驱动团队高效公布的还需从建设团队的公布文化开始，文化又依靠于公布规定的积淀：
- 定时定点发车。火车不等个性，回绝未经测试的新个性上车；
- 只公布高质量的个性。只有测试通过的个性才容许上车，即便研发曾经实现相干个性并且要求上线的时候，也要坚定回绝；
- 频繁公布火车，个性拆分的足够小。更快更小的公布可能让产品的品质更高、老本更低，频繁公布使每次公布的个性变小，呈现问题的时候定位和解决也会变得更明确和高效，当然公布的频率须要依据团队的研发和治理整体品质决定，不是一味地谋求快；
- 世界没有完满的公布，须要有明确的要害性能指标来决策争议个性的公布。
Erda 团队实际
基于以上的规定，Erda 团队的实际如下：
小结
不论从我的项目协同、研发全流程以及到最初的公布火车，其本质指标还是心愿可能以高效的形式去撑持应用软件继续疾速、高质量的更新公布，为了这个指标，每家公司都有本人的实际和见解，没有对和错之说，只有合乎企业当下利益最大化，可能布局企业的将来即可。本文只是以 Erda 一个团队视角进行了分享，欢送大家能够一起参加分享探讨研发提效的实际，独特促成整个行业效力的晋升，谢谢！
更多技术干货请关注【尔达 Erda】公众号，与泛滥开源爱好者独特成长～