视频访谈： 七牛云宫静：研发组织实施CICD 需要注意些什么？

• 下载
• Android app

宫静： CICD是一个流程上的实践，我们把代码开发、到代码部署、到最后的交付，进行持续地迭代和交付，在这个过程中对原来的团队产生的影响是这样的：开发不再只关注他在开发这部分的实现，他需要保证从代码开发实现、到单测、到测试、到构建部署，到最后的分发发布，这样整个流程的覆盖。按照我的理解，CICD对整个团队文化的影响是，每个人对产品研发的整个流程都要全部参与进去，不再是只局限在自己的角色上。比如我是一个开发，我只做实现，我不再关注部署和测试；或者我是一个测试，我不关注开发实现，不关注部署，我只关注执行；或者我是一个运维，我对前面的所有流程都不了解，我只执行最后的运维步骤，而CICD就是把整个团队有效地集成在一起，通过一个流程持续地迭代发布验证，这样的话，整个团队就能更高效地展开合作。

宫静： 我们目前的确也遇到了多分支并行的情况，也就是说我们需要对不同的业务场景做不同的版本管理。在这种情况下，我们依然可以做CI的实施，但是要经过专门的设计，在每个分支所运行的软件，它的版本管理需要做统一的管理，比如需要规划每个分支的依赖是什么样的，要把整个路径都管理起来。如果没有这样的管理，从构建到部署到测试都是混乱的。在版本管理的基础上，我们还要把代码和测试有效地集成起来，也就是说，不光是代码到测试，是代码到配置、到测试、到部署，都要有效地集成起来。一份代码在这个分支上，它对应的配置在哪里，是什么版本，在这个分支上测试的版本在哪里，都需要管理起来；在这个分支上，代码部署的版本依赖也需要统一的管理。如果我们没有做好这些基础设施，是没有办法做CICD实施的。当我们把这些整理清楚之后，再针对每个分支做整体的实施，通过版本管理去理清楚我们实施的部署构建，到底依赖圈是什么样的，这样就可以做一个正确的实施。

宫静： 这件事情的推动我理解是包含两个层面的：第一个层面是意识上的贯彻，我们需要对开发人员贯彻“单测也是代码开发的一部分”这个意识，从上而下去贯彻这个意识的同时，我们也需要对这项工作提供流程上的支持。也就是说，我在计划一次开发任务的时候，就已经把代码实现、单测实现、测试这些任务都一起计划进去了，对任务或项目做评估的时候，是包括了代码实现和质量保证的，这样对开发来讲，他就不会认为单测需要额外的付出，而是认为这是他应该要做的事情。这也是七牛一直在贯彻的思想：开发即测试，开发要保证所有代码的质量。另外一方面，当我们要做单测的时候，还需要提供一些基础设施上的支持。比如怎么做单测，可能我们之前没有贯彻这个意识或没有推动这个环节的时候，开发是没有这样的意识的[基础知识或者没有这样的意识]，或者他们没有这样的基础，不知道怎么做单测能更快、更好、更有效地覆盖，而这就需要靠团队之间的最佳实践分享，或者我们把一些公有、通用的实践抽取出来作为一个服务提供给大家，这样去推动开发可以有一个有效的路径知道应该怎么做这件事情可以达到更好的效果。第二个层面是度量的体系，在我们贯彻了意识、告诉他们需要这么做，并且告诉他们应该怎么做之后，我们还要衡量你到底做得怎么样，这是我们质量效率体系中的一环，就是单测这一环，我们会收集单测数据进行分析和度量。

宫静： 目前我们会在持续集成的过程中，把单测这个环节集成进去，也就是说当一份代码在Check in到代码仓库的时候，会自动触发，单测可以自动执行，在执行之后，我们再做数据的打点、采集、收集和上传，最终会上传到我们的质量效率平台进行数据分析。

宫静： 我们有一个七牛容器云服务，在这上面构建持续交付的时候，我们可以利用容器化技术本身的特性所带来的便利。比如，容器可以把编译运行环境进行打包和封装，那我们在代码提交的时候，就已经有一个一致的容器Docker file去描述它在什么样的环境下做编译。这样一来，当编译环境比较复杂多样的时候，就可以有效地避免冲突，以及不同环境之间相互影响的问题，比如说我跑到[跑到]不同的Build System，可能Build出来的结果是不一样的，通过容器去把它封装起来。另外一块是运行环境，也是类似隔离封装的作用。运行的时候还有一块就是资源的有效利用，我们在部署测试环境的时候，因为资源有限需要合理规划，容器从底层到上层做封装，又可以在物理机上面并发跑起来的时候，我们就可以对物理资源做最有效的规划[规划和计划]和计划，通过一些底层的容器编排系统，比如说像Kubernetes，去把我们的容器编排起来，最终达到产品整体的部署和运行效果。

宫静： 我们在做整体的持续集成和持续交付流程的时候会有相应的策略。持续集成流程的每个环节，都有准入和准出的条件，当代码提交到代码仓库，或者是创建一个新的Pull Request的时候，就会触发持续集成这个流程。进入这个流程会有不同的环节，比如编译，部署测试环境，然后集成测试环境，这些环节在什么时候可以正确触发，什么情况下开始触发，触发的结果是怎样的，都需要验证通过后才可以进入下一个环节[进入下一个环节继续往下流]继续往下流。如果验证不通过，也就是准出条件没达到的情况下，持续集成会直接失败，然后就会涉及到回滚的过程，持续集成失败的时候我们也制定了相应的策略，比如紧急情况下直接回滚，非紧急情况下，我们有一些hotfix、patch的流程可以让整个持续集成的流程继续迭代，这样可以保证主要分支的代码是稳定可靠的。

宫静： 以我的理解，在原来没有这样一个平台的时候，开发可能做的事情就是写代码、提交代码、然后做一下代码审核就结束了，但是有了这个持续集成平台之后，他们写完代码提交的时候会发现触发了自动验证，需要去察看验证结果是不是通过，比如单测的覆盖率[比如说单测的覆盖率]有没有达到一定的指标，一定的度量标准，编译部署有没有通过，编译部署如果没有通过，出错在哪里？每自动触发一个环节，开发都需要去一步一步验证，保证他的Check in是合法有效的。对于测试人员，我的理解是，测试人员对整个代码开发和研发流程是可以提前介入的，他在代码提交的那一刹那就可以知道这个产品的代码质量怎么样。因为我们有持续集成去迭代了，那么测试人员在提前介入之后，已经做了一些有效的验证，这个时候测试人员可以更多地关注更复杂的测试场景的设计和测试方案的实施上面。同时我们在之前的持续交付[之前的持续交付]流程中已经有了收集数据度量这块，测试人员就可以更关注整个流程上代码的质量怎么样，产品的质量怎么样，可以对整体产品质量效率进行评估。运维人员的话，目前通过持续交付平台，运维人员可以提前做一些验证，因为整个流程是持续发布的，那么代码在正式发布到线上之前，还需要有准入条件，运维在准入操作之前可以看到预发布的状态或者测试发布的状态，这可以有效帮助他在发布前了解发布状态。

宫静： 这个可能要从我们的架构设计实现和我们以后的方向两个方面来讲。首先，我们现在的架构是建立在七牛云的容器云服务上，我们的持续交付平台跟容器服务是深度集成的，包括我们在持续交付、持续集成、持续部署的每一个环节，都深度集成了容器环境的管理。比如我们的持续交付、[]持续部署，是部署到我们的容器环境中去进行验证，这样可以有效地把容器化方向在我们的CICD产品上体现出来，所以我们的持续交付是基于容器实现的，会有容器化方向的优势。另外一点就是，我们的持续交付平台的工作流Pipeline完全做到了模块化可定制，可以一键开启或者禁用，当不同的人员有不同的操作需求，比如开发只想做开发调试，或测试只想跑集成测试，或有时候想运行完整流程的时候，都可以定制自己的流水线。

宫静： 从架构层面来说，在我们设计容器环境的时候，是需要做进一步的Review的，我们会在Review当中去发现现在的产品在微服务模式的实施是不是足够合理。如果不够合理，比如说一些边界定义不清楚的时候，那么在平台上部署整个产品会比较复杂，因为一个服务可能内部依赖另外一个服务，依赖复杂度是成指数增加的。因此我们在做容器环境的架构设计的时候，需要去理清楚这些关系，如果我们发现架构设计有不合理的地方，就需要推动产品把服务治理这一块提升起来。在适应架构复杂度上面，我们也做了一些探索，比如在Kubernetes原生的容器服务管理之上，我们又实现了一个产品结构的管理，我们对产品进行了层级划分，最小的粒度是一个服务，简单来讲，[提前至“你可以认为……”]你可以认为它就是一个运行的容器，如果容器之间有逻辑关系，我们会把它给放到一个服务组里面，同一个服务组可以统一进行规划；而不同的服务，如果有一层两层三层这样的先后顺序，我们就把它们放在不同的服务组；服务组之间会先后启动，我们先保证第一层服务起来了，再把第二层服务，也就是对第一层服务有依赖的这些服务启动起来，然后再启动第三层服务，达到完整的产品结构的编排。

宫静： 这个可能要看整个产品或者是整个流程，有没有达到CICD的成熟度。第一点也是最简单的一点，看你的代码是不是有需求去做持续的CICD[持续的CICD]，如果本身你的企业软件是一年迭代一次，一年发布一次，那就没有必要，只需要保证在发布前，软件的测试质量通过验收就可以了。但是如果像我们现在比较多的情况需要进行快速发布和快速迭代，需要持续地对外发布变更，那这时候就可以考虑是不是有必要在我们的研发流程当中实践CICD。在实践的时候，我们同时要保证是，第一就是我刚刚讲的，我们确实有这个需求；第二，我们有没有CICD的前提条件，比如，开发和测试是不是有一些结合，测试的成熟度是不是能支持快速的迭代和验证，持续集成最主要的一步是持续的迭代发布验证，如果连自动化测试都没有，或者没有有效的单测、集成测试、回归测试等验证手段，测试成熟度不够高，部署的自动化程度不够高，那根本没有办法把整个流程串联起来。这时候可能首先要考虑把这部分自动化的框架和 工具 、用例先准备好，等我们在日常的工作中已经可以用它进行自动化验证的时候，就可以把整个CICD流程很自然地驱动起来。

InfoQ: 以上就是这次的采访问题，感谢您接受我们的采访。