WePack —— 助力企业渐进式 DevOps 转型
本文为 CODING 高级产品经理俞典在腾讯云 CIF 工程效能峰会上所做的分享。文末可前往峰会官网，观看回放并下载 PPT。
大家好，我是 CODING 高级产品经理俞典。DevOps 对于大家而言应该已经不是一个陌生的概念，它为研发团队带来了更快的交付速度、响应变化和更好的团队协作方式，帮助企业实现几天到几周内交付和部署软件。在 DevOps 流程中，大家可能更容易关注到代码、流水线、测试、发布等工具带来的效能升级，那么我们在构建什么、测试应用的来源是什么、发布什么？——这三个问题的答案都是「制品包」。
软件开发中的制品管理就如同传统制造业中的货仓管理，它连接着产品的生产和发布两个阶段。前几天我简单统计了一下 CODING 研发团队自身的制品数据，在一天中，整个团队推送了 6000 多个制品，同时产生了 1 万多次制品拉取操作。制品不仅数量大，还因为开发语言不同、面向的环境不同有着不同的属性，需要分门别类的管理。而制品的推拉稳定性、安全性与信息准确性决定了整个产品的生产质量。那么围绕企业级制品管理面临的各种复杂问题，我今天为大家介绍 CODING 自主研发的企业级制品管理服务——「WePack」的设计理念和落地实践。
说到痛点，大家可以和我一起来对你所在的团队的疼痛指数做一个评估。首先是疼痛指数最高的一类用户：我们之前遇到过很多的用户，因为整个研发团队有 Java、C++、前端等不同技术栈，生产的制品类型也各有不同。很多用户使用传统的 Ftp 或者 SVN 仓库来管理软件压缩包，自己搭一个 Nexus 来管理开源的第三方 Maven、Npm 依赖。随着容器镜像的普及，研发团队逐渐产生了一些 Docker 镜像需要管理，于是用户再自己搭了一套 Harbor 来管理镜像。
这些系统各有各的一套管理体系和账号体系，给运维人员带来了较高的管理成本。制品的管理尚且没有打通，和其他 DevOps 模块的打通就更是难上加难。因此集中管理制品是企业用户建立 DevOps 制品管理体系的第一步。
很多用户意识到了这个问题，因此开始基于 Nexus 这样的开源制品库自建，或者采买 JFrog 这类统一的制品管理平台来管理制品。此时集中化的管理又带来了新的问题：这些工具虽然提供了统一的账号、权限管理功能，让我们能够统一管理所有的团队制品，但随着企业产品规模的扩大，集中在一起的制品如何划分管理权限成为了问题。比如这时一旦有新的项目诞生，或者临时项目、外包项目出现，制品管理员就需要重新为整个企业的用户组，配置这些新项目的各种权限；没有项目隔离的制品管理也会产生安全问题，这将给运维团队带来很大的负担，让制品管理成为 DevOps 流程加速的瓶颈。
当我们解决了前面两点制品管理的单点问题后，新的问题来了：由于制品管理承上启下的属性，需要和上下游的工具进行信息与功能调用的集成。很多企业在 DevOps 的每一环选择了不同的工具，那么就会需要进行若干次的集成与对接。许多企业选择购买如国外的 Azure、Gitlab， 或者国内的 CODING DevOps 这样的一站式产品来解决多次集成的问题，好不容易打通 DevOps 工具链，但是又出现了新的问题。
我们在面对很多私有化的客户时，都提到了对于制品安全扫描功能的需求。无论是出于国家安全监管规定，还是企业自身的信息安全诉求，DevSecOps 的概念出现了。
有的客户购买了 Black Duck、Checkmarx 这样功能强大的安全工具，可以扫描出各种漏洞，并提供多维度的统计报告，但是这个报告只停留在安全工具系统中，最多可以展示在 Jenkins 的插件中。如何把这些漏洞拆分到对应的项目团队去解决，为这个报告找一个负责人，并且追踪报告内漏洞的解决情况？这些工具其实都没有提供解决方案。这是安全工具和 DevOps 工具链割裂而造成的问题，同时因为这样的割裂，我们很难建立起一个自动化的管控流程来限制安全问题的右移。
还有一个关键问题是这些安全工具扫描出的漏洞很难被修复。我们无法回避大多数研发团队的安全能力都是有限的这一现状，可能一个团队有 100 个研发，只有 1 个安全人员，他无法兼顾到整个团队引入的安全问题。并且目前安全工具提供的漏洞信息和解决方案还是相对专业，可能一个普通的开发都难以理解安全软件提供的修复建议，他按照建议进行了修复，其实也没有比他更专业的人员去验证结果，而英文信息也加大了这一过程的难度，因此修复安全漏洞比发现漏洞难得多。
围绕这些层层递进的痛点，我们希望提供给用户一套完善的制品管理解决方案，因此诞生了企业级制品管理服务——「WePack」，接下来我将为大家介绍 WePack 的设计理念。
我们在设计 WePack 时，首先考虑的便是制品管理最基本的痛点——集中管理的问题。我们希望 WePack 不单是做到制品类型的统一，还可以统一管理企业内部自研的第一方构建包、第二方的平台基础制品包、以及来自外网的第三方开源组件，保证自研制品在研发、测试、发布的生命周期信息得到记录，而第三方制品的来源与使用信息都可以在 WePack 系统中追溯，以此建立起企业唯一的可信制品来源。
同时，由于企业制品管理对于精细化权限、项目资源隔离的诉求，WePack 沿用了 CODING 经过用户验证的权限管理体系。普通的制品管理工具，比如 JFrog Artifactory、Nexus 的用户管理体系。企业下若干个项目组共享所有制品资源，制品仅通过仓库隔离。面对扩张的项目管理需求，用户就需要靠增加节点来实现项目权限隔离。最近这些工具也意识到了多项目管理的问题，推出了 Project-based 的产品能力，但项目的个数却受到付费等级的限制。WePack 继承了 CODING 项目的管理层级，为用户提供了命名空间的管理层级，命名空间也可以理解为项目或者研发团队，可以用于管理不同的用户组，给这些用户配置不用的制品操作的权限。系统内的用户可以随时加入或退出命名空间，且命名空间的个数也没有限制，企业因此无需担心临时项目和外包项目的管理成本。
WePack 目前的权限粒度精确到了仓库层级，企业管理员可以通过设置仓库可见范围和用户组，对指定仓库的制品操作权限实现精细化的控制，满足企业复杂的权限管理诉求。我们同时也在规划将这一权限粒度再细化到制品层级。
介绍了 WePack 基本的设计理念后，可能有些熟悉 CODING 的朋友会产生一个疑问，无论是公有云还是私有部署版的 CODING DevOps 中已经有了制品管理这一个模块，为什么还要单独设计一款私有化场景下的制品管理单品系统呢？我们主要有以下三个方面的考虑。
首先，CODING 制品管理可以帮助用户实现基本制品管理功能，连接上下游 CI/CD，汇集信息，打通整个 DevOps 流程。而对于软件开发、测试、生产等多环境隔离的用户，他可以选择部署多套 Wepack 在多个环境，通过制品同步功能将各个环境打通。或是制品需要分发到多个地域的用户，在每个环境或是地域部署一套 CODING 显然是不合适的，而 WePack 可以帮助他们实现各个环境、地域的制品集中管理。
另一方面，许多用户如果已有自建的 DevOps 工作流，WePack 也能提供很好的开放能力，帮助用户将制品管理模块和自建的工具便捷打通，实现信息的汇聚。
最后，制品其实和代码一样，是企业的核心资源，无论是公有云还是私有云，都可能需要这样的一套系统，在相对隔离的环境单独存储制品资源。
接下来我将会详细介绍 WePack 的功能设计。首先是一些制品管理的基本功能：WePack 目前已经基本覆盖了主流的制品类型，可以实现多种类型的制品统一管理。并且不同于市面上大多数制品管理工具只提供制品文件结构信息，WePack 还展示了制品自带的描述、标签、大小、Readme 等元数据信息，在制品被推送到 WePack 中时，就能展示制品信息。在制品的版本管理上，用户可以通过灵活的版本管理策略，设置制品版本是否可以被覆盖。在第三方依赖包的管理功能支持上，WePack 提供了制品代理功能，可以将外网的公共制品代理到系统内，配合制品扫描的功能保证开源组件的安全性和可操作、可追溯。
对于上文提到的多环境、多地域的管理诉求，我们提供了制品同步功能来实现制品的跨环境、跨地域流转。制品同步功能支持将系统内的制品推送到远程仓库，也可以将远程仓库的制品拉取到本地仓库中。详细的实践案例将会在后文说明，也可以加深对该功能的认识。
WePack 支持灵活对接各种对象储存产品，也支持用户对老旧制品进行清理，释放储存空间。值得一提的是我们已经支持了 Docker 版本的不停服物理删除。
最后一个基本功能是制品扫描。我们在扫描能力上选择了和腾讯安全的专业团队进行合作，由他们提供不同的安全底层能力的支持，这使得我们的安全能力具备很强的准确性与专业性，满足对安全有较强诉求企业的制品管理需求。
这是 WePack 的基本功能，接下来我将介绍 WePack 在 DevOps 工作流上的一些应用。WePack 除了元数据外，还提供了制品属性的功能，任何信息，例如代码、Commit、构建环境信息、测试是否通过信息、质量检查信息等都可以被记录到制品中。同时 CODING 的制品推送插件，除了可以帮助用户通过 CODING CI 将制品推送至 WePack 制品仓库中，还会自动将构建环境中的信息写入制品管理系统中，同时我们也提供了 Jenkins 插件来支持该功能。
那么提到质量管控的流程，无论是 CODING 中的制品管理还是 WePack 系统中，我们都开通了制品扫描模块，用于当前环境开源组件的漏洞扫描。我们在制品扫描功能中，加上了流程管控的能力，可以在扫描结果出来的当时就禁止有问题制品的下载，这样便只有安全的、通过检查的制品才可以流入下一个环节。此时如果开发发现依赖的组件拉取失败，就可以追溯到失败原因，去解决有问题的制品。得益于我们打通了漏洞的发现与制品流动的流程管控，可以实现有效地管控安全问题的右移。
在制品的质量、安全职责的问题上，我们避免了将制品扫描这个功能独立于 DevOps 流程之外，而是隶属于整个 WePack 团队/项目的管理层级。我们可以给一个命名空间的项目组，或者一个制品仓库配置一个扫描方案，也可以基于一些筛选规则配置一个扫描方案，制品的负责人便可以只关注他权限范围内的制品漏洞结果，做到谁的问题谁来解决。
那么我们在功能设计上，如何帮助研发团队更好更方便地去修复安全漏洞？首先在漏洞信息中，用户可以定位到漏洞所属的依赖组件，通过我们提供的依赖分析功能，用户可以找到有问题的组件被哪些生产制品所依赖，以此去定位修复漏洞入口。同时为了避免开源漏洞不准确、商业用户缺乏中文支持、信息不够透明等问题，我们与腾讯安全以及联合实验室进行了合作，腾讯安全的专业运营团队基于通用的安全漏洞库进行了安全研究，也会将他们的研究成果贡献至例如 NVD 之类的开源漏洞库中。根据他们的研究成果，腾讯安全建立了一个自研的软件开源漏洞特征库，大幅降低了漏洞的误报率，同时提供了中文的漏洞信息、漏洞组件修复版本信息等等。
我们的制品扫描引擎在解析出制品依赖后，会访问漏洞库的服务，输出制品扫描报告，然后再写入 WePack 系统中。在优化漏洞信息后，我们希望避免用户一次性关注到太多不重要的漏洞，因此定义了漏洞的修复优先级。除了像 CVSS 提供的安全等级，腾讯安全还结合了漏洞的动态安全等级，也就是说现在是否有公开的漏洞利用 POC 披露，来定义该漏洞现在是否优先推荐用户修复。这样用户可以去优先关注真正对研发环境有威胁的漏洞并进行修复。以上便是 WePack 的基本功能。
接下来我将用两个案例来演示 WePack 的落地实践。首先是在金融行业的落地实践案例。该客户有很强的管控规定，希望他的研发环境不能访问外网，但是又希望能代理外网的一些开源组件，所以我们帮助用户建立了一个网络隔离区，在其中部署 WePack。开源组件可以从这里代理到网络隔离区的 WePack 系统中，并在此处被扫描，通过扫描的制品才能进入研发测试环境。同时客户在其生产环境也部署了一个 WePack，与其他环境相隔离，通过我们提供的制品同步功能，使其在研发测试环境产生的可以被发布的制品，能够被推送至生产环境进行发布。
第二个案例是在游戏行业，该客户的游戏软件包需要分发到多个地域，因此我们帮助他们在海外的多个节点部署了 WePack，通过制品同步的分发功能，他们生产的制品包可以被分发到多个 VPC 里的 WePack，通过不同 VPC 的生产集群去拉取制品进行跨地域部署。
以上便是两个具体客户的落地案例。关于 WePack 的未来规划，主要分为两个方面：首先在安全管控能力上，我们希望能提供给用户更细粒度的权限管控能力，能够帮助用户实现资源粒度的权限控制。同时我们也会继续深化安全能力合作，不断提升制品安全检测与管控能力。第二点是我们希望能够将信息收集和打通功能做得更加完善，让 WePack 与企业的研发管理诉求相结合，中转研发 - 构建 - 质检 - 发布信息流。同时我们也会提升上下游工具和部署平台兼容能力，满足企业的多样化工具链与多种部署需求。
