如何构建高效自主的容器云交付平台？

>高效自主的容器化交付平台=敏捷工程理念 x 七牛云交付平台组件(云存储+大数据+容器云) 随着 DevOps 理念的普及，大部分公司已经尝试敏捷项目管理并取得一定的成果，但实际代码生产过程仍然是分角色的瀑布式交付，无法实时开发、实时测试、实时部署，但随着容器和大数据技术的到来，让每个企业都能拥有一套高效自主的容器化交付平台。 11 月 23 日，七牛云架构师实践日第 32 期以「容器技术的实践与分享」为主题，在成都成功举行。七牛云工程效率部负责人李倩，在会上为大家带来了题为《容器云交付平台—实现真的敏捷开发/测试/部署》的精彩分享。 **作者简介：**  李倩，先后主导多家 IT 企业分层自动化测试框架的落地实践，积累了大量自动化实战经验。2014 年入职七牛，从零开始构建七牛质量保证体系，推进与完善了研发体系持续交付和持续集成。先后负责存储、数据处理、直播等产品的质量把控，构建了第一支使用 go 语言为自动化框架基础支撑的质量保证团队。 以下是演讲内容的实录整理。 _____________ 大家好，简单介绍一下，我个人经历做了九年的软件开发和测试开发工作，其中包含四年技术管理经验，2014 年入职七牛在负责工程效率部，目前带领 40 人左右的团队为我们的研发团队提供质量保证，研发流程管理，持续交付平台等工程和质量服务支撑。今天就容器交付方面实践经验给大家分享一下。 ## 七牛云的业务场景  七牛云已经成立 7 年了，现在有 6 条产品线和丰富的行业解决方案，还有一些产品内部运营和私有化项目。体量是非常大，架构上我们基本是微服务化，主要是采用 go，也有其他语言栈，这就需要提供多样性的编译和运行环境。作为一个创业公司，我们的发布要求很高，要很快的响应客户的需求。 大公司和小公司对于 to B 的服务差异在于，小公司能快速应变，考虑需求合理性快速实现，以适应客户的业务，而在大公司里可能需要一个月甚至两个月。我们发布周期一天会有十几次的发布，也会有按时按需的发布需求。另外，我们的协作难度也比较大，有 400 多个研发同时写代码，进行上线、运维。有一些还要进行后续的跟踪和反馈，质量上难以控制。做云计算本质上是在提供「水、电、煤」给各个业务，对可用性和健壮性，质量方面要求非常高，这两年我们面向行业提供完整解决方案，会涉及更多的复杂场景，其中会涉及多产品服务的组合测试，自动化测试用例数量也是非常多的，要高效的运行同时满足高业务覆盖率是非常大的挑战。 ## 工程效率的挑战 在这样的业务场景下，按照角色总结了不同的挑战。  第一，开发同学面临多样化的编译、运行环境，自测难度高，分支合并频繁无法可靠发布。作为工程师，我们七牛要求每个人要对自己的代码负责，所以我们需要给大家提供测试的便利性以及关注代码发布质量的可控性。让开发同学有能力从保证代码的正确执行到去关注业务的正确性。 第二，质量方面，有限的测试资源，我们不可能完全模拟，我们有测试的独立机房，有限的测试环境下，怎样充分利用资源，怎样模拟更多的场景，这些都是要面对的质量问题。 在很多偏业务的公司里，测试看起来是阻碍公司快速上线但又不得不做的事情。那如何提供更快的反馈能力让 QA 同学如何更早介入、更早验证，做到实时测试，更快上线，这也是一个巨大挑战。另外，如何做到对整体质量的把握，对整个代码生产过程的质量管控都是要工程上关注的问题。 第三，运维方面，服务拆分后运维需要管理维护的服务数量级增加了数倍或者数十倍，运维架构复杂度提升，虽然服务可以独立部署，但是由于内部依赖，独立部署的微服务不可测、或者功能不能完整走通。我们虽然是拆开了部署方面提升了速度，但是拆了以后怎样保证在合的时候没有问题。面对这样的架构复杂，怎样提升运维的效果？ ## 解决的思路  下面介绍解决的思路。标准化，关于怎么样让团队更快项目迭代的内容我会省略，然后直接讲敏捷开发，关于全流程的质量保障是怎么做的。重点会讲怎么样把研发过程搬上平台，让开发过程不再是部门壁垒式的，而是真正大家在价值流动过程中看到自己的交互过程，以及提供的延展服务。智能化这块我也会省略，我们做了一些尝试，还是比较有效果的，后面会有一些数字给大家看。 **标准化**  首先介绍代码生产的过程。代码管理我们用的 github，做了比较完善的持续集成体系，工程师可以多次频繁的提交快速获得每一个代码片段的质量反馈，这里的反馈会包括单元测试，覆盖率合规，代码检查合规。另外 CI 过程耗时我建议 10 分钟以内，如果达不到这样的水平，要分析 UT 是不是写的有问题，是什么导致你的损耗，另外就是构建平台本身效率有没有瓶颈。这里 PR Auto Check通过，一般情况会有一到两个人做 code review。这里我非常建议大家重视 code review，这是工程师自我提升和追求极致非常好的方式和契机。code review 通过后，合并到 Develop 分支，会自动触发平台做持续交付。成熟度高的产品，如果这个测试通过，我们配置好的 hook 流程会自动流转到待发布的状态，一般成熟度的产品会有 QA 做业务验证和测试用例补充人工触发 jira 的状态变化，这里描述的是一个功能的完整交付过程。这个过程协同几乎是同步的，issue 粒度上开发交付什么测试就可以测什么，后续平台希望支持到 pr 能直接触发持续交付，这会将自动化验证能力进一步提前，进一步缩短代码到 ship 间的距离。  这是预发布到发布的阶段，之前的功能代码都测过。Develop 合并至 master，它就可以触发持续交付面向发布的验证，对接发布平台按需进行发布。 我们协作通过什么方式做起来呢？  是用角色的 Pipelines，面向角色和触发条件，我们会定义自测、集成、发布的 Pipelines 建立交付机制。真正的敏捷是他不再需要去按照准入条件是什么，在周四还是周五测，而是我们可以随时测，每日都可以测试，可以随时去补测试用例作为自动化验证的一部分。  流程里的涉及质量保障，我们的思路是面向不同的触发条件和交付目的建立质量卡口并建立自动化验证体系收集质量数据做分析。 **平台化** 平台化是今天介绍的重点。这个平台我们做了一年多，中间也经历了很多过程，从不成熟的容器化到容器化的状态，到现在可以规模容器化的状态。  这是一站式研发交付平台的能力的描述，支持混合模式测试环境管理。很多人在上微服务，但其实我们的微服务不全都是一把上的，可能是一个一个来上，基本思路先从无状态的上，再上有状态和基础应用。这种方式下，如何保证质量稳定，如何保证顺利容器化，我们也想了很多的办法。我们考虑必须支持混合的模式，现在我们是支持两个完整的环境，哪些内容容器化，我们就在容器化管理；哪些没有容器化，我们就以兼容模式来做管理，这样保证环境是持续进行更新的，整个研发体系的支撑也是持续更新的。另外我们提供产品和服务级别的编排，易于管理微服务关系和依赖，能够将微服务组装成完整的产品，并构建面向角色的持续交付流水线。我们主张开发测试运维一体化，所以会统一管理渲染关系和涉及到的模版。  交付工具链。我们目前一部分产品已经切到持续交付平台 2.0 版进行容器化交付，这跟产品阶段，业务形态，复杂度都有关系，通过评估我们会逐步迁移和支持。测试框架我推荐大家用下 ginkgo，在处理分布式和并发测试的时候，执行效率非常高而且维护起来很轻量，框架本身是 go 写的。其实大家不难看到我们并没有采用很多的工具，我认为工具在于你能不能用好，并且低心智负担的衔接起来，游刃有余的把流程真正梳理清楚纳入平台。  延展服务。我们会做很多服务嵌入到工作流里，比如持续集成过程里我们服务化收集单元测试，代码审查的质量数据。在持续交付阶段则支持集成测试与覆盖率服务。测试服务我们已经延伸到了各种环境场景，比如说交互的私有云、云存储，也可以定向跑验证灰度部署成功与否。另外我们也做了 Chaos 工程尝试，会拿很多破坏性的程序，看服务是否健壮。接下来会把这些的服务能力逐步纳入新的持续交付体系。 ## 微服务架构介绍  首先讲一下工程理念。大家一直会有疑问，微服务架构到底是什么东西？微服务到底是什么世界观？以下是我个人的看法，面对更多的场景和业务的时候，我们要处理自己团队规模的复杂度提升，系统高可用、高并发的要求，如何让更多人更为有效的开发更大体量业务的程序？大家发现微服务可以让更多的人参与到复杂体系的设计和交付上，我们根据业务架构拆分更合适的微服务通过接口约定实现高效协作。 微服务化是化零为整、化繁为简的过程，持续交付平台是提供组装和管控的能力。自动化的框架要稳定，并且自动化 Case 要能覆盖交付能力，这样可以真正到一定程度自助的持续发布、持续部署。  Spock 的整体架构不复杂，分 biz、service 和底层服务支撑。底层的 Service，我们用七牛云自己家的存储、大数据、容器云，也分别解决了不同的问题。比如说存储，我们会把交付的可用包和 log 放在云存储上做备份，用大数据产品提供实时日志分析和监控的能力。容器则是最最核心的底层，我们的容器团队提供了很稳定可靠的容器集群以及各种基础组件 app。  上图是平台工作流结果查看。右边有一个关联问题，下面会有对应的代码库以及服务内容，是一个基本的信息和构建。构建以后部署，部署会有产品信息以及部署的环境，以及经历什么样的测试，串联的项目管理、代码管理、环境管理与发布相关的所有信息、交互的管理，都会在这里去体现。  这是我们的质效系统，会去分析持续交付过程中的一些质量和效率指标，帮助我们识别质量和效率短板。这里的指标是其中一部分，这些指标是会根据每个季度，半年度，从众多量化指标中选择比较关注的急切去改善的放在这里，内部优秀团队评比和奖励也会参考质效数据，奖励也是会涉及交付链条中各个角色而不再是一个实体部门。 这里也跟大家分享下我的看法，所有的指标都不应该是评价人的绝对值，因为人的素养是多维的，不可能被完全的数字化评价，但是通过这些数据来反映一定的交付和团队协作能力，比如说返工率是一定程度体现返工和质量情况；单元测试和合规其实是代码基础质量的评估；事故反应全组对服务高可用最终努力的成果。 我们现在达到的水平是核心模块是 60% 以上，核心模块代码合规 80 分以上，持续交付通过率 85% 以上，集测覆盖率 E2E+API 达到 35% 以上，事故严重率逐 Q 下降1 0% 以上，构建效率 2-10 分钟，缺陷解决率是 82.97%。有一部分 QA 已经从测试开发变成了开发工具或测试服务的状态。  以上是我们平台实践成果的图，增长业务比例在下降，质量水平是稳步提升的。质量平台大概是从 2016 年初开始做的，也有一些指标因为不合理被砍掉，最终从 20 多个指标到 10 个左右，最终抽取的核心指标主要是跟工程的正向促进相关的。 谢谢大家。 __________ [](https://mp.weixin.qq.com/s?__biz=MjM5NzAwNDI4Mg==&mid=2652196015&idx=1&sn=b4aaafab8acf1fc3411468ea45cf1617&chksm=bd017a3a8a76f32c679c3dda9c0b1f2b1b7d103bcd6222ac427e5ac7aa9753d1c94d1bed1911&token=575288811&lang=zh_CN#rd)