深度好文｜探寻云原生时代应用研发新模式
引言：伴随着基础设施技术升级，应用研发环境也从最初的传统 IT 架构、虚拟化 & 容器化架构演变到现在的云原生多云架构。“应用研发新模式”本身就是一个比较大的话题，我们也不敢说一个人或者一个团队就能把这个话题聊透彻。但随着应用研发基础架构环境的演进，应用研发模式一定是在不断地调整和创新。
今天我们大胆把话题抛出来，聊聊自己的一些想法，和大家一起探讨、共创云原生时代应用研发模式后续的演进路线。
DevOps 平台现状和痛点
（应用研发架构演进路线）
本文暂将应用研发架构的演进路线归纳为四个阶段（如上图），传统 IT 架构和虚拟架构下的应用研发，相信大家都比较熟悉，DevOps 的概念在这两个阶段几乎没有激起什么水花，所以这两个阶段我们就不展开阐述了。
伴随容器技术的出现（特别是 Docker 和 Kubernetes，后续简称 K8s），让 DevOps 概念火了一把，也在实践中开始快速落地和普及。容器能够封装微服务整个运行时环境的特性，天然就适用于微服务构建、发布和运行，让原本缓慢前进的 DevOps 得到飞速发展，开源社区也涌现了很多优秀的开源产品（比如 Jenkins、GitLab 等），大家通过这些开源产品能够快速搭建自己应用的持续集成环境，因此市场上也如雨后春笋般冒出许多 DevOps 相关的产品。
现阶段中的 DevOps 产品通过 Docker 和 K8s 确实帮助用户解决了资源管理、微服务环境构建和持续集成的复杂、效率低等问题，但是伴随公有云等 Infra 基础设施持续高速发展，人们对于应用研发的效率追求也会有更高的要求，对于 DevOps 产品也不会满足停留在当前阶段（微服务应用的持续构建部署），那么如何在 DevOps 现阶段的版本基础上进一步提高研发效率和质量呢？我们还是一起通过梳理当前研发过程中面临的痛点出发吧！
痛点 1：多云资源如何统一管理，解绑云厂商？
在公有云、私有云等多元化的云环境下，大家手头往往都有两套或者多套云资源，如何让这些割裂的云资源统一进行管理？如何基于一个平台让应用快速进行跨云迁移、发布？比如：开发在私有云，生产在公有云等这些问题伴随资源环境多元化问题会越来越突出。
痛点 2：复杂微服务组合如何快速进行环境构建、持续集成？
当前 DevOps 对于单个微服务的环境构建和持续集成问题已经基本解决。但对于企业级软件研发交付团队来说，错综复杂的微服务组合而成的项目如何进行统一的环境构建、部署和交付，目前仍解决得不太彻底，只能让各应用的研发成员都参与到构建、部署的整个阶段。以上复杂的过程容易引起问题不说，效率成本上也是个大问题。
痛点 3：研发效能如何进一步提升？
在当前主流的 DevOps 产品中，代码、构建、部署全流程自动化触发执行的特性基本都是得到了比较好的解决，但是随着研发管理的深度、精细度要求越来越高，需要研发同学维护的数据也随之不断增多，管理维护项目数据的项目管理工作量也在不断增大，效率和成本这组矛盾如何得到妥善处理？
新一代 DevOps 不仅应有效解决上述痛点，还应具有测试安全的左移、研发效能度量等更多开放性能力，这个全新的时代需要有更全面、更创新的特性。
新一代 DevOps 的特性
多云管理
多云管理并不是简单指通过 K8s 集群来实现资源的调度管理，如果仅仅是统一资源调度那本身是 K8s 集群的特性。
通过应用部署环境配置去关联集群，确实可以实现环境之间的隔离、环境之间快速迁移的能力，就如上面提到的：开发测试在本地私有云环境，生产可以通过同一套代码能够快速发布到公有云；还有就是业务在一个集群，数据处理可以在另外一个集群，实现业务和数据分离，两者互不影响，这些都可以通过集群管理来实现。
既然说了这么多都是和集群相关的，那么和多云管理有什么关系呢？
首先，我们对 K8s 集群的节点管理，希望可以一个平台上统一便捷购买/释放主流公有云厂商的资源节点。
其次，现在公有云上都有容器相关的服务提供，平台只需要调度管理这些容器服务即可，所有容器服务的对接管理（包含但不仅限于容器服务的购买、释放、扩缩容等）都需要在平台完成。
再者，公有云上其他的云服务都可以通过平台进行购买直接使用，无需用户不断切换登陆到各公有云的控制台，最后进行云资源的统计分析、资源成本的运营分析，帮助企业在资源方面进行降本增效。这些都是多云管理的范畴之内。
Erda 目前在 K8s 集群管理、公有云服务对接管理方面都是做得比较好的，大家可以体验使用，对这部分内容感兴趣的同学欢迎联系我们，一起沟通、碰撞想法。
项目级持续集成
目前，对于单应用的持续构建部署，DevOps 的业界产品基本都是达成共识的，对于单个微服务应用构建部署的自动化完善程度较好。
但是对于企业级项目研发过程，我们一起来回想看看，比如：单应用内不同任务需要拉多分支来进行开发（基于主干开发的模式可能没有这个问题），受开发环境资源的限制，不同任务开发同学要不断进行线下沟通合并代码发布开发环境（或者测试环境）进行测试，过程中可能存在谁的代码分支有问题导致整个环境不可用的现象，oh my god！
项目级的联调部署就更复杂了，首先需要配置项目环境，其中包含了项目级的参数配置以及大家公用的项目级中间件准备部署；其次是复杂的微服务编排信息维护，这些繁琐的项目级维护管理动作，往往会导致项目部署过程中出现各种阻塞，比如项目共同的中间件准备阻塞，上游服务的部署和健康度也会影响或阻塞下游服务部署和测试等，这些问题会让项目部署更加困难化。
既然已经分析出问题的所在，那么我们一起来看下 Erda 的解决之道。
Erda 坚持以应用为中心，在单应用的研发过程中，基于任务分支开发的模式下（这里说明一下，Erda 产品本身的研发团队是基于主干开发来实现每日集成的），研发同学只要保证自己分支质量的基础上，随时可以发布到开发环境进行测试和验证。
那么细心的同学肯定会发现如果开发环境只有一套，相同应用下有其他研发任务分支的同学该怎么办？这里就先透露一下 Erda 接下来即将规划的功能：大家只管发自己的分支部署，分支之间的临时合并后部署的事情，就交给 Erda 平台来完成吧😄。
项目级构建部署的问题，Erda 通过项目级流水线、制品、环境部署（其实是环境准备和部署两个环节）三个重要特性来解决的。
首先，在应用通过代码持续构建部署到开发/测试环境，实现了代码到服务的全流程自动化。
其次，项目中共用的中间件进行了统一管理。这里的中间件不仅覆盖了平台内置丰富的中间件服务，还提供了公有云上的存储类中间件，甚至还支持通过自定义中间件的方式来管理对接用户自己部署维护的中间件。这些中间件在 Dice.yml 中可以一键部署，实现真正项目级的中间件管理，彻底解决用户依赖中间件的烦恼。
前面提到了代码到服务的全流程自动化，其实制品到服务也是这个全流程中的一个环节。应用研发同学在开发环境冒烟测试通过后，测试同学可以基于应用制品可以组合成项目制品，通过项目制品 + 环境配置，可以快速在测试环境上部署测试（基于主干开发的话，这些步骤都是可以全自动化完成），测试同学通过自动化测试和手动测试确保项目质量达标后，就可以一键发布项目制品，后期项目交付实施同学可以基于此制品到客户环境上进行快速交付或升级应用。
研发流程的自动化
上述的代码到服务、制品到服务的全流程当然是在研发全流程自动化中进行的。除此之外，在优雅解决研发效能度量数据采集的同时，还要让我们的研发同学尽量少做一些维护工作，比如：需求任务拆解后，任务的状态、备注是否能够自动流转，不需要刻意地登陆到平台去进行维护就能完成。研发同学在进行沉浸式本地开发的同时，就能完成相关工作。
这个也是 Erda 当前重点在解决的事情，研发角色在统一平台进行高效协同的认知角度可能也会适当调整一下。不同研发角色的协同数据在统一平台，具体的协同可以由多元化的端能力来完成，让用户在不感知平台的情况下，无时无刻不在使用平台的能力，比如：通过 ChatOps，让信息及时触达到用户后，用户可以在实时通讯 APP 中快速处理，处理后的数据会返回平台进行统一计算分析，伴随用户在实时通讯 APP 的处理，相关 Issue 事项的备注、截止日期、状态等属性信息也在同步进行自动化流转处理。
研发流程自动化还可以体现在 Issue、代码、测试、环境实例之前的全方位自动化，通过 Issue 和代码分支的绑定，研发同学本地提交/合并代码后就会自动触发相关 Issue 状态流转、代码自动化构建部署、自动化测试、项目制品合成、制品 Changelog 的自动生成等全链路的自动化。
以上仅仅罗列了新一代 DevOps 的部分特性，对于其他特性，都应该围绕效率、成本和质量这个铁三角展开，去创造更多有意义、有价值的新特性。
本文只发表了一些个人对于 DevOps 演进的部分观点，相信其他小伙伴肯定有更好的的想法，如果大家对于本话题感兴趣，欢迎联系我们一起深入探讨。我们将定期组织小伙伴围绕相关话题进行持续讨论推进，期待更多小伙伴的加入！
我们致力于决社区用户在实际生产环境中反馈的问题和需求，如果您有任何疑问或建议，欢迎关注【尔达Erda】公众号给我们留言，加入 Erda 用户群参与交流或在 Github 上与我们讨论！
