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 的每一环选择了