因为是本地开发，所以没太在意成本这块（之前估算过翻译这块总共也就几十刀，后面因为本地数据变了所以实际花费更多）。我忘记是自己手动执行还是 AI 自己执行的脚本（一直都是--dangerously-skip-permissions ，大概率是 AI 的锅，毕竟它无法反驳）。然后第二天就带娃出去旅游了。

旅游回来后，本地代码无法运行，然后发现 Google Cloud 前面一天花费了 2200+刀，但因为绑定的是虚拟卡没这么多钱，所以扣款失败被停了服务。心疼的不行，给 Google Cloud 写了邮件，表明是无心之举，然后 Google Cloud 也很慷慨，给了一半折扣，需要付 1100+刀。

今早重新绑卡做了支付，项目未半而中道崩卒的感觉。

也算给大家个经验

1. Google Cloud 默认只支持提醒，如果想超过额度停用服务，需要额外的编程处理，并不太友好。
2. 代码调用三方付费服务的，混着 AI 一起运行要小心，自己才是第一责任人🤡

{ "rc": 10001, "msg": "部分商品没有库存", "data": { "out_of_stock_ids": [ 1, 2, 3 ] } } 

还是抛出下面这样的自定义异常？

class BaseBusinessError(Exception): rc = 500 msg = 'Unknown error' data = None def __repr__(self): return f'<Error {self.rc}: {self.msg}. data: {self.data}>' def __str__(self): return self.__repr__() class ShopOutOfStockError(BaseBusinessError): rc = 10001 msg = "部分商品没有库存" data = None def __init__(self, product_ids: list): self.data = product_ids 

如果采用异常方案，调用方没有自定义异常类的定义怎么办？如何反序列化？是不是要共享异常的定义代码给所有调用方？要是调用方是其它语言呢？

这篇博客 下的这句：

查询方法不建议抛出 checked 异常，否则调用方在查询时将过多的 try...catch ，并且不能进行有效处理。

中的 checked 异常是什么意思？是否可以理解为查询方法不抛异常。比如，查询某个数据没有权限，直接返回空，而不是抛一个没有权限的异常。

Cloud Studio 是基于浏览器的集成式开发环境（ IDE ），为开发者提供了一个永不间断的云端工作站。用户在使用 Cloud Studio 时无需安装，随时随地打开浏览器就能使用。云端开发体验与本地几乎一样，上手门槛更低；具有极强的开放性，第三方平台通过我们提供的 SDK ，则可以方便地集成 Cloud Studio 云端开发能力。

简介

本次内核升级：Cloud Studio 内核版本从 v1.71.0 升级到了 v1.73.1。主要包含如下亮点：

• HTML 实时预览 - 实时预览 HTML 文件。
• 合并编辑器改进 - 文本和合并编辑器之间的转换更容易。
• 工具栏自定义 - 隐藏 /显示工具栏操作。
• 以树视图显示搜索结果 - 在列表或树视图中查看搜索结果。
• 终端快速修复 - 纠正命令拼写错误。
• 搜索包含 /排除文件夹 - 快速设置要在树视图中包含 /排除的文件夹。

HTML 实时预览

在 html 编辑区点击显示预览即可打开预览，支持动态刷新。如何下图所示：

合并编辑器改进

在有冲突的文件中将自动显示一个“在合并编辑器中解释”按钮，方便文本编辑器切换为合并编辑器。如下图所示：

点击“在合并编辑器中解释”按钮后，效果如下：

隐藏工具栏中的操作

您现在可以隐藏工具栏中的操作。右键单击工具栏中的任何操作并选择隐藏该操作的菜单。隐藏的操作会被移动到“...”更多操作菜单中。隐藏后，也可以从更多操作菜单那里触发被隐藏的操作。如果要恢复被隐藏工具栏操作项，请右键单击工具栏按钮区域并选择“重置菜单”。要恢复所有被隐藏工具栏操作项，请从命令面板 ( ⇧⌘P ) 运行重置所有菜单。隐藏工具栏中的某一个操作，如下图所示：

以树视图显示搜索结果

您现在可以以树视图方式查看搜索结果！只需单击“搜索”视图顶角的列表 /树图标操作，即可在列表视图和树视图之间切换。如下图所示：

终端快速修复

当 Git 命令输入错误时，快速修复会建议使用类似的命令。如下图所示：

搜索包含 /排除文件夹

在搜索视图搜索结果区域的树视图中右键单击文件夹时，上下文菜单中现在有两个新选项。如下图所示：

写在最后

上面只列出的部分相对重要的更新内容，本次更新在工作区、编辑、终端、源代码控制、调试、笔记本、语言、扩展点等各个方面都有了很大的升级。因此，新版内核将给您带来全方位的体验提升。欢迎个人开发者、企业、第三方平台使用或者集成 Cloud Studio产品，也欢迎给我们提改进意见。

研发过程中，如何直观且准确地获悉代码提交后的质量状态？ 引入持续集成，可以自动化的对代码进行代码检查、单元测试、编译构建、甚至部署与发布，大幅提升开发人员的效率。

腾讯云 CODING 推出 CI 3.0 ——云原生构建，是一款基于代码仓库的构建工具，采用全新的设计理念。可用于持续集成、持续部署、持续交付、远程开发。面向云原生，提供功能、性能、配额三重升级，旨在为 DevOps 践行者带来更简单、更流畅、更高效的构建体验。

优势亮点

简单——Pipeline as Code

通过仓库根目录中的 .coding-ci.yml 文件，使用开放式、可读性友好的 YAML 语言，声明整个持续集成流水线。既可以使开发人员阅读、编写与复用流水线更加方便，又可以纳入代码仓库管理体系，像走查代码一样变更流水线配置，增强流水线的可控性与可追溯性。

流畅——基于 DOCKER 生态

1. 支持指定任意 Docker 镜像作为构建环境。
2. 使用 Docker 作为流水线插件，支持任意语言编写，可直接使用业界已有的 Docker 插件。
3. 流水线中支持运行原生 Docker 命令，支持任意编排 Docker 服务以满足自动化测试等需要启动依赖服务的场景。

高效——基于 OverlayFS 的高性能方案

传统的 CI 流水线中通常无法兼顾任务的并行与效率，尤其是面临代码仓库或构建缓存异常庞大的场景。基于领先的 OverlayFS 缓存瞬间复制技术，即使是上百 GB 容量的代码仓库，云原生构建也能够在秒级完成代码克隆，同时在并发数持续扩大时确保性能不衰减。

快速开始

step1:创建代码仓库

云原生构建能力基于代码仓库中的 .coding-ci.yml 配置文件，因此需在 CODING 团队中提前创建一个代码仓库。进入项目后，点击左侧菜单栏左侧的“代码仓库”中的右上角按钮进行创建。

step2:新增配置文件

在仓库根目录中增加名为 .coding-ci.yml 的配置文件。该配置文件用于描述了当仓库发生一些事件时，应该执行什么操作。一个简单的配置文件参考如下：

配置文件含义

当有任意提交推送至 master 分支时，将触发一个名为 echo 的阶段。在此阶段将运行在 script 步骤中所定义的脚本输出命令。

更多用法请参考官方文档：https://ci.coding.net/docs/

step3:提交配置文件

在终端中运行 git push 命令，将配置文件推送至代码仓库中。

step4:查看构建结果

代码推送后将按照配置文件中的定义触发云原生构建。访问代码仓库中的“云原生构建”，查看构建结果。

在构建日志中查看构建阶段运行详情。

解锁云原生开发的全新境界

云原生构建不仅仅是一个流程，它是一种改变开发方式的哲学。希望通过腾讯云 CODING CI 3.0 的云原生构建能力，释放开发者潜力，提升研发团队的协作与交付效率，开创更加灵活、高效的开发新时代。

为什么需要保证 企业源代码安全

随着时代的发展，各行各业的企业或多或少都会与软件源代码打交道，借助软件系统更好地提升企业办公效率，而软件的源代码也自然成了一种企业新型资产。如何确保企业源代码不外泄，成为了各个企业特别关心的痛点问题。这个问题存在已久，各个企业根据自身的情况提出相应的解决方案，而随着云端开发这种新型开发模式的兴起，让企业源代码安全又多了一种成本更低、效率更高、相对又更安全的方案。

云端开发如何保证 企业源代码安全

早期，我接触了一些军工企业，他们对源代码安全这块要求非常严格。他们是通过技术手段，外加严格的人事管理确保源代码的安全。例如网络进行物理隔离，内外网数据交换必须要经过一个严格的“摆渡机房”进行操作。同时，所有的计算机接口都加了监控报警，不允许接不被许可的 U 盘等。进入办公场所的人员也不允许带手机这样的电子设备。

对一些安全要求没有那么严格的大多数公司来说，大部分还是通过在员工电脑上安装各种监控软件、网络安全隔离等方式进行安全保证。

可以发现，一般情况，对安全要求越严格，往往成本越大。因为内外数据交换，往往是很频繁的（特别是外面的数据往公司内流动）。如果没法做到自动化，自然就会让员工在处理这些事情上特别低效且繁琐。每个员工都需要 IT 支持，并花费一到两天的时间安装配置这些软件和网络（小公司又很难有这样的基础设施）。尤其现在很多公司把非核心业务外包给一些合作伙伴公司，合作伙伴的员工可能无法方便访问甲方企业的内网环境，安装监控软件又很繁琐。如何解决这些问题又成了企业的一个新痛点。

而 Cloud Studio 云端开发平台借助于云端开发这种架构的天然优势，可以成本更低、效率更高、相对又更安全地解决上述问题。

首先，Cloud Studio 云端开发天然保证了企业的源代码不落地。所有的源代码都保存在远端开发环境中，在开发者本地电脑上不会存在源代码。另外，企业通过一些特殊的安全性更高的七层网络协议代理方式打通外网的访问。同时，通过禁用下载、网页水印、复制加密等方式确保企业源代码做到真正不落地。

Cloud Studio 网页水印 复制加密和禁止下载能力

网页水印

当我们开启了网页水印功能后，通过我们的 Cloud Studio 打开任意一个工作空间，您会发现编辑器上面多了一层水印，通过水印可以防止员工通过截图的方式泄露源代码。效果如下所示：

复制加密

当开启代码复制加密功能后，代码文件下载也会被同步禁止，这时候您会发现，您对编辑器内的所有文本的复制，粘贴到外部后，自动变成了密文，而粘贴到编辑器内部其他位置是正常的明文，通过复制加密可以防止员工通过复制的方式泄露源代码。效果如下所示：

禁止下载

默认我们提供的编辑器是支持文件的上传和下载能力。当我们禁用下载功能后，则不会看到下载代码文件的功能，这样就可以防止员工通过下载的方式泄露源代码。效果如下所示：

通过该在线编辑器，可以使用编辑器 UI 进行如下操作 ：

1.打开指定目录或者文件；

2.安装 /卸载 /查询编辑器插件；

3.创建新文件；

4.DIFF 和合并两个不同的文件等操作。

编辑器 UI 交互方式，虽然已经足够使用，但是 Cloud Studio 还提供了一个内置的编辑器命令行工具：cloudstudio 。这个命令名称较长，所以还提供了一个简短的别名叫：cs 。如果使用过 vscode 编辑器提供的 code 命令，那就能无缝切换到 cloudstudio 命令的使用，cloudstudio 和 code 命令几乎一样。通过这个编辑器命令行工具，也能实现上述编辑器 UI 交互方式的一些操作。命令行操作方式在一些场景中相对更加方便快捷。同时，还可以结合 shell 脚本做一些自动化的操作。

执行如下命令查看帮助信息：

cloudstudio -h# 或者 cs -h 

执行如下命令打开指定文件或者目录：

cloudstudio /foo/bar# 或者 cs /foo/bar 

执行如下命令管理插件：

# 安装插件命令 cloudstudio --install-extension vscode.csharp@1.2.3# 查看已安装的插件命令 cloudstudio --list-extensions# 卸载插件命令 cloudstudio--uninstall-extension vscode.csharp@1.2.3 

执行如下命令创建一个文件：

cloudstudio --add bar# 或者 cs --add bar 

执行如下命令打开指定文件并定位到文件内容行列位置：

cloudstudio --goto /foo/bar:10:20# 或者 cs --goto /foo/bar:10:20 

除了上面这些常用的命令，编辑器命令行工具 cloudstudio 还有更多高阶命令，还可以通过 cloudstudio -h 帮助命令查看详细信息。

前言

Cloud Studio 是基于浏览器的集成式开发环境（ IDE ），为开发者提供了一个永不间断的云端工作站。用户在使用 Cloud Studio 时无需安装，随时随地打开浏览器就能使用。云端开发体验与本地几乎一样，上手门槛更低；具有极强的开放性，第三方平台通过我们提供的 SDK ，则可以方便地集成 Cloud Studio 云端开发能力。

简介

本次内核升级：Cloud Studio 内核版本从 v1.73.1 升级到了 v1.76.0 ，引入了一些令人兴奋的新功能和改进。以下是一些我们认为您可能会感兴趣的亮点。

可移动的 Explorer 视图

现在可以将 Explorer 视图容器（ Ctrl+Shift+E ）移动到二级侧边栏或底部面板中，以进一步自定义您的工作区。

Markdown Header Link 建议

如果您需要链接到另一个 Markdown 文档中的 header ，但不想输入完整的文件路径，可以尝试使用 workspace header completions 。只需在 Markdown 链接中输入“##”，即可查看当前工作区中所有 Markdown headers 的列表，然后选择一个即可。

恢复默认布局

如果您想从自定义布局命令恢复默认值，可以通过触发命令或使用自定义标题栏中的布局控件，然后使用布局控件右上角的恢复箭头按钮恢复默认值。

面板对齐

现在，您可以直接从面板上下文菜单调整面板对齐方式，就像面板位置一样。

自定义资源管理器的 自动显示逻辑

此版本引入新设置 explorer.autoRevealExclude ，如果启用了自动显示（ explorer.autoReveal ，默认为 true ），此设置允许您配置哪些文件在资源管理器中自动显示。autoRevealExclude 设置使用 glob 模式来排除文件，类似于 files.exclude ，也支持通过 when 子句进行兄弟匹配。默认值不包括 node 和 bower 模块：

{ "explorer.autoRevealExclude": { "**/node_modules": true, "**/bower_components": true } } 

隐藏视图容器的徽章

与通过右键单击视图容器隐藏视图容器的方式类似，现在也可以隐藏容器上的徽章（显示在活动栏、面板和侧栏中）。徽章通常显示特定视图容器的数字、图标或进度指示器，例如，源代码管理视图的待处理更改数。

后话

上面只列出的部分相对重要的更新内容，本次更新在工作区、编辑、终端、源代码控制、调试、笔记本、语言、扩展点等各个方面都有了很大的升级。因此，新版内核将给您带来全方位的体验提升。欢迎个人开发者、企业、第三方平台使用或者集成 Cloud Studio 产品，也欢迎给我们提改进 Cloud Studio 意见。

GitHub 仓库推荐

• Awesome Open Source Applications - 收集了各种开源应用程序，包括 Web 应用、桌面应用、移动应用等。Cloud Studio 一键运行

• Free for Dev - 收集了各种免费的开源应用程序和工具，包括 Web 应用、桌面应用、移动应用等。Cloud Studio 一键运行

• TodoMVC - 收集了各种前端框架的 Todo 应用程序，包括 Angular 、React 、Vue.js 等。Cloud Studio 一键运行

• Flask Mega-Tutorial - 使用 Flask 框架构建 Web 应用程序的教程和示例，涵盖了用户认证、数据库、表单、邮件等方面的内容。Cloud Studio 一键运行

• Django Girls Tutorial - 使用 Django 框架构建 Web 应用程序的教程和示例，涵盖了模型、视图、模板、表单等方面的内容。Cloud Studio 一键运行

• RealWorld - 收集了各种 Web 应用程序，包括前端、后端、全栈等。Cloud Studio 一键运行

• Hacker News Clone - 使用 React 和 Firebase 构建的 Hacker News 克隆应用程序，可以帮助你学习和实践 React 和 Firebase 的使用方法和特点。Cloud Studio 一键运行

• Node.js Chat Application - 使用 Node.js 和 Socket.io 构建的实时聊天应用程序，可以帮助你学习和实践 Node.js 和 Socket.io 的使用方法和特点。Cloud Studio 一键运行

• Machine Learning for Humans - 使用 Python 和 Scikit-learn 构建的机器学习应用程序，可以帮助你学习和实践机器学习的使用方法和特点。Cloud Studio 一键运行

• TensorFlow Examples - 使用 TensorFlow 构建的机器学习应用程序，包括图像识别、自然语言处理、语音识别等方面的内容，可以帮助你学习和实践 TensorFlow 的使用方法和特点。Cloud Studio 一键运行

轻松点击链接，体验 Cloud Studio

Tech news

**No.1 [ Google 在其 I/O 大会上发布了新项目、新功能和新等待名单] **

#1：Bard 向所有人开放，并进行了一些升级

Google 宣称它在编写代码方面表现得更好。一旦您有了代码，您可以将其直接导出到 Google 的 Colab 笔记本或在 Replit 上部署。

Bard 还将获得访问工具的权限。如果让它为您写一封电子邮件，您将能够将草稿发送到您的 Gmail 并在那里继续。Instacart 、OpenTable 等的集成即将到来。

#2：生成式 AI 无处不在 Google 将其新的 Duet AI 集成到文档、幻灯片和 Google 表格中。还在 Gmail 中引入了一个“帮我写”功能，可以根据您提供的上下文草拟和重写电子邮件。

#3：PaLM 2 已发布，将配备不同大小的模型以满足不同用途 Google 的下一代语言模型现在正在为 Bard 提供动力，以及一组初始合作伙伴，包括 Wendy's 应用。

#4：Google 承诺提供更多定制和微调模型的方法。 包括设置我们自己的强化学习反馈循环。在 Vertex 中进行提示、微调和部署 LLMs ，这是 Google 用于创建和托管生成式 AI 模型的开发者平台。、

#5：Google 将为所有 AI 生成的内容添加水印 Google 演示了一个图像示例，但许多 AI 巨头也已经为文本探索了水印。这些举措背后的目标是促进生成式 AI 更负责任的格局。

#6：最后但同样重要的是 - “对话式 UI ”即将进入 Google 的核心搜索体验。如同 Google 所说的，“搜索快照”即将到来。这将对 SEO 的未来产生重大影响。

**No.2 [数据所有权已经成为 ChatGPT 话题中的热门话题，而且越来越热。“未经同意的内容”是下一个大警钟] **

近期，华盛顿邮报发布了关于谷歌网络抓取数据集的深度调查,该数据集已知被用于训练谷歌的 T5 、Meta 的 LLaMA 以及可能还有更多。其中，他们发现了数百个令人震惊的例子：大多数新闻网站、个人博客（包括 Medium ）、创作者平台（包括 Patreon 和 Kickstarter ）等，都是在未经同意的情况下用于训练大型语言模型。

回顾一下意大利对 ChatGPT 的禁令 ： 他们现在已经给 OpenAI 一个关于数据隐私的待办事项清单，包括发布关于其训练数据的声明，并加强其使用我们的数据来训练未来模型的法律依据。尽管基础模型提供商（如 OpenAI 和谷歌）可能面临困境，但这是另一个关注用户或其公司使用的工具的数据隐私和所有权条款的原因。而且对于 AI 用户，预计随着竞争和争议升温，用户会希望能够轻松地在模型提供商之间切换。

福利专区

Cloud Studio 免费时长提升到 3000 分钟，欢迎大家扫码参与 Cloud Studio 第二弹征文~

** [免费试用 CS ] **省时又省力

Cloud Studio 是基于浏览器的集成式开发环境（ IDE ），为开发者提供稳定的云端工作站。在使用 Cloud Studio 时无需安装，打开浏览器即可快速启动项目。底层资源自动弹性扩缩，极大地节省成本，低代码开发省时又省力：

● 基于 Web 端的代码编辑器，包含代码高亮、自动补全、Git 集成、终端等 IDE 的基础功能，同时支持实时调试、插件扩展等，提升开发、编译与部署工作效率 ;

● 支持远程访问云服务器，为腾讯云 SCF 行业用户提供开发-测试-部署完整闭环的云原生开发体验 ;

● 自研多款插件以满足开发需求，例如协作插件、自定义模板插件、预览插件、部署插件等，助力施展编程潜能。

点击链接免费试用：Cloud Studio - 开启云端开发模式 WebIDE

每月赠送 1000 分钟免费额度。

一、参与方式

1. 注册 /登录腾讯云账号，腾讯云开发者社区 PC 端页面右登录 - 腾讯云按钮发布文章，文章标题前需加上 [玩转 Cloud Studio ]

1. 将发布的文章链接贴在活动页面评论区，作者还可以社区新上线「自荐功能」，欢迎大家体验 - 腾讯云开发者社区-腾讯云及分享文章链接至各平台。

二、奖励规则

** [好文有礼] **

** [分享有礼] **

分享活动海报长图到微信朋友圈集赞，并保留至活动获奖名单公布日 6 月 16 日。添加腾讯云开发者社区小编微信号：yun_assistant ，将截图发给小编进行抽奖。小编将抽选出 20 位用户送出精美礼品一份。

** [扫码加入活动群，接收更多福利活动] **

三、征文规则

文章标题前加上 [玩转 Cloud Studio ]

文章内容为 Cloud Studio 相关，选题方向包括四大方向：

①在线编程技巧和经验分享：参与者分享在使用 Cloud Studio 过程中总结的编程技巧和经验，例如如何提高编程效率、如何解决常见的编程问题等；

②开发工作流程和流程自动化：参与者通过 Cloud Studio 来实现云端编程，再无缝衔接至 CODING 完成开发工作全流程，分享使用自动化工具带来的高效开发体验；

③使用 Cloud Studio 进行特定编程语言开发：参与者可分享如何在 Cloud Studio 中使用特定的编程语言（如Python 、Java 、Node.js 等）进行开发，并提供实际的例子和代码段。Cloud Studio 操作方式截图；

④技术布道：以 Cloud Studio 为编程工具，开放主题，参与者可以进行多维度研发技术经验分享。

● 文章内容应为作者原创，需区别于单纯的教程操作说明，并且为首发和手动发布在腾讯云开发者社区，历史文章和同步文章不参与此活动。一经发现侵权行为，取消活动参与资格。活动杜绝严重灌水以及恶意刷量（包括但不限于阅读量、点赞数等）行为，一经发现将取消获奖资格。

● 文章内容字数不少于 800 字，且要求文字通顺、图片清晰、代码规范。

● 文章必须是新发文章，即发布于2023 年 4 月 24 日（含）之后。

● 所有符合征文活动要求的参与文章，作者可以点击文章页「自荐上首页」按钮，即有机会获得腾讯云开发者社区首页热门推荐。

● 参加征文活动的文章作者拥有著作权，腾讯云开发者社区拥有使用权

四、评审规则

最终得分：文章影响力 80% + 专家团评分 20%，文章影响力由热度（阅读数）、受认可度（官方推荐）以及互动量（点赞数、收藏数、评论数）加权计算。届时将有腾讯产品团参与评审，主要按照以下维度评分：

● 产品创新性

● 实用性

● 可借鉴性

● 代码规范度

● 与云计算能力的结合

五、特别注意

①以上奖项不可重复获得（分享有礼奖不计在内），重复会进行顺延（如果同时获得其中 2 个奖项，将取最高排名所在的奖项类别），1 个作者的多篇文章入选，将取数据最高的文章进行评选；

②工作人员核对符合此次活动获奖资格后发放奖品；

③腾讯云开发者社区有权根据自身运营安排，自主决定和调整本活动的具体规则，具体活动规则以活动页公布规则为准。

六、参考范文

● Cloud Studio 内核大升级 - 极致体验 - 腾讯云开发者社区-腾讯云

● Cloud Studio 搭建网站新姿势 - 腾讯云开发者社区-腾讯云

除了包含代码高亮、自动补全、Git 集成、终端等 IDE 的基础功能外，Cloud Studio 还同时支持实时调试、插件扩展、远程访问云服务器、适配多种环境，可以帮助开发者们迅速完成各种应用的开发、编译与部署工作。

现在 Cloud Studio 每月还有 1000 分钟的免费时长赠送，入股不亏，走过路过不要错过。 https://cloudstudio.net/

本文转载 CodeSheep 。 作者受邀参加 Techo Day 腾讯技术开放日线上活动，收获颇丰，有感而发。

前言

上期 Techo Day 腾讯技术开放日活动讲的是「轻量级工具」，这一期主要讲的是「云原生」。

在所有课题里，个人比较关心的是 CI 设计这个课题——CODING CI 3.0，比传统 CI 好在哪里？

传统 CI 的问题和痛点

CI 的概念

CI 全称 Continuous Integration ，名为「持续集成」，传统的 CI 含义指的是代码仓库只要有代码变更（或者说有人想推代码入库），就会自动执行预先设计好的检查、防护流程，运行一系列构建、测试、部署等流程，并最终告知每一步的运行结果，确保人提交上来的代码没有问题后，才有机会将新代码合并到主干分支，而主干分支无论何时都一定是正确可运行的高质量版本，可以随时交付客户使用。

持续集成的词面意思其实某一程度上也道出了该做法思想的精髓：即小步快走，持续地去做代码集成。

不得不说持续集成在现代软件研发流程中，扮演了十分重要的角色。

平时的工程中，总有一部分工作是相对机械化，易出错的（例如打包、部署），我们可以把这部分工作交给机器来做。让持续集成构建计划进行自动化的单元测试、代码检查、编译构建、契约测试，甚至自动部署，能够大大降低开发人员的工作负担，减少许多不必要的重复劳动，持续提升代码质量和开发效率。

传统 CI 问题和痛点

聊到 CI 系统，那不得不提的就是 Jenkins 了，它是一个使用广泛的持续集成工具。

但是不少团队或项目使用 Jenkins 系统的目光还局限于在 Jenkins 上建各种各样的 Job 来完成 CI 任务，所以依然存在不少痛点，典型的比如：

1. 配置繁琐且不灵活，尤其是对于新拉分支的 CI 部署比较麻烦，配置的可扩展性和可复用性有待提高。

2. 传统的 Jenkins Job 难以灵活高效地并行（包括 Job 间、节点间、任务间、甚至任务内等各个维度的并行），所以任务执行效率有待提高。

3. 传统的 Jenkins Job 日益失控的趋势让我们措手不及，Job 太多，CI 脚本太离散，维护成本实在太高了，而且很危险，一旦 Jenkins Server 挂了，一切都 Game Over 了，需要重新搭建了。

4. 如今很多的业务上云了以后，如何对云端代码快速构建一个高效的 CI 系统也成了一个必须要面对的问题。

什么是 CODING CI 3.0

CODING 持续集成是 CODING DevOps 的子产品，其全面兼容 Jenkins 的持续集成服务，支持 Java 、Python 、Node.js 等主流语言，并且支持 Docker 镜像构建，图形化编排，高配集群多计划并行构建全面提速您的构建任务。支持主流的 Git 代码仓库，包括 CODING 代码托管、GitHub 、GitLab 等等。在构建依赖拉取方面，使用专用网络优化包括 Maven ，NPM 等主流镜像源，保证拉取速度，进一步提升构建速度。

而如今在这次的活动上，腾讯云又推出了全新的 CODING CI 3.0 。

CODING CI 3.0 是腾讯云面向云原生打造的全新 CI 平台，基于 OverlayFS 的高性能 CI 技术，为持续构建应用、灵活定制流水线提供高效、稳定的服务保障。

所以接下来就来聊一聊这次发布的 CODING CI 3.0 的一些特性和优势。

CODING CI 3.0 特性和设计

通过 YAML 文件声明流水线

YAML 格式的声明式配置文件相信大家都不陌生，各种企业级项目里用得比较频繁。

而此次的 CODING CI 3.0 同样支持通过通过 YAML 配置文件的方式来声明并快速拉起一条流水线，非常便捷，并且易于理解：

master: push: - docker: image: node:14 stages: - name: 依赖安装 script: npm install - name: 测试用例检查 script: npm test 

比如上面这个案例描述的流程如下：

• 声明了在 master 分支在收到 push 事件时（即有新的 Commit 推送到 master 分支）的时候；
• 会选择以 node:14 Docker 镜像（ opens new window ）启动的容器作为构建环境；
• 依次执行任务 npm install 和 npm test 。

另外，由于该 YAML 配置文件和项目源代码一样都作为仓库文件，一起被托管和版本控制，所以完全遵循 Pipeline as Code 的思想，这样后续不管是 CI 流程的协作以及版本追溯都非常易于进行，而且也更利于实现 CI 配置的复用。

这样一来，设计 CI 流程=设计声明式配置代码，所以也非常符合程序设计的思维。

基于容器技术的 CI 设计

我们都知道云原生时代非常典型的一个代表技术就是容器了，同理云原生时代的 CI 设计也必须兼容和支持容器技术。

CODING CI 3.0 基于 Docker 技术生态，对构建环境、存储、插件进行抽象，更彻底地支持 Pipeline as Code 。

当然这里有多个层面的设计思想。

1. Docker image as env

用户可以通过在配置文件里直接指定使用所需的 Docker 镜像，甚至是 Dockerfile ，就可以指定 CI 流程中所用到的一些基础构建环境。

• 通过 Docker 镜像来指定构建环境

• 通过 Dockerfile 来指定构建环境

2. Docker image as plugins

同时 CODING CI 3.0 也支持在配置文件中使用 Docker 作为流水线插件，支持使用任意语言编写插件，从而扩展更多的功能。

同时其也支持直接使用 Docker Hub 上已有的容器插件，目前支持的生态有：Drone Plugins 等。

3. Native docker support

第三个层面就是原生 Docker 服务的支持，包括直接执行各种 Docker 命令以及脚本。

具体来说，一是支持在流水线上直接执行 Docker 命令，另外也支持在流水线上直接使用 docker-compose 编排服务。

基于 OverlayFS 的高性能方案

在上文中也提到，传统的 CI 流水线中一个很麻烦的问题就是任务的并行和效率，尤其是当代码仓库非常庞大的时候。

这时候在拉起多条 CI 流水线时不可避免地就会出现速度慢和效率低的问题。

针对这个问题，在传统的 CI 实践中也有一些常见的解决方案，比如：

而这次推出的 CODING CI 3.0 则是通过基于 OverlayFS 的高性能方案来解决这个问题。

其本质上是使用缓存，然后主要通过 OverlayFS 技术实现缓存的“瞬间复制”。

这里通俗来理解就是，第一次执行没有缓存的时候，所有流程走完一遍，执行 git clone 命令，把整个仓库克隆下来；但后续的 CI 流水线，只要发现机器上有这个仓库的代码，就可以先通过 OverlayFS 技术复制一份缓存来用，然后在缓存的基础上进行 git fetch 操作，因此每条 CI 流水线都能很快启动。

这样一来，即使是上百 GB 容量的仓库，也都可以在秒级完成代码克隆。

如下图所示，当 clone 方式从 git worktree 切换到 OverlayFS 瞬时复制方案后，带来的效果就是代码的准备时间大幅度缩短，从而提高效率。

CI+ 远程开发

我们都知道传统的本地开发模式有着很多缺陷和不足，突出表现在以下几点：

• 仓库多，环境无法相互隔离；
• 开发环境复杂多样，每个人都需要重新配置；
• 切换办公机 /远程办公后，重新配置环境麻烦；
• 克隆代码和构建速度慢；
• 本地机器性能有限，影响开发效率。

所以此次 CODING CI 3.0 带来的一项很重要的能力就是支持远程开发服务运行在 CI 上。

即推出了一套基于 CODING CI 的远程开发方案，随时随地一键启动开发，无需繁琐的操作，就可以为开发人员打造出一套现成的环境，从而可以享受无比流畅的编译构建以及开发测试体验。

而且不同的人拿到环境，只需要改一下配置，就又可以迅速拉起一套 CI 开发环境，所以非常方便高效。

而用户只需要通过浏览器或者类似 VS Code 这样的终端软件即可参与远程开发。

一旦有 Git 事件或者 Open API 触发了 CI 流水线，CODING CI 就可以自动创建工作区，并且启动远程开发服务。

总结

另外此次 Techo Day 腾讯技术开放日活动所有的资料和课件都整合成了一份《腾讯云云原生工具指南》，里面详尽介绍了涵盖 CODING CI 3.0 、遨驰分布式云操作系统在内的腾讯云热门产品技术原理，可以说非常实用了，感兴趣的小伙伴可以扫描下方二维码，前往资料专区下载查看。

腾讯云 CODING 成功入选领导者位置

在战略和能力两大维度国内领先

📃IDC 报告指出：

腾讯云 CODING 在一站式 DevOps 平台领域具有最佳用户体验，对不同规模、不同类型的研发团队均可良好适用，并且在测试、交付、咨询、市场合作等方面，腾讯云 CODING 沉淀了众多合作伙伴，建立了全面而成熟的生态伙伴体系。

腾讯云 CODING DevOps

腾讯云推出的面向软件研发团队的一站式研发协作管理平台，从需求提交到产品迭代，从产品设计到代码管理、测试管理、持续集成、制品管理直至部署交付，整套流程均可在一站式平台内完成，降低企业研发管理难度，提升研发效率。

目前，CODING DevOps 能够提供企业级公有云服务和私有部署方式，以便满足客户不同场景的开发需求，并提供同城双活、两地三中心高可用容灾能力。客户范围涵盖互联网、金融、政企、工业、运营商、媒体、医疗、教育等各个行业。

例如，中化信息联合腾讯云 CODING DevOps 打造了新一代数字化研效平台，打通从需求、设计、开发、构建、测试、发布到部署的全流程，实现了项目管理可视化、构建集成自动化、持续测试自动化、持续部署自动化，以此来快速交付高质量的业务价值。如今，中化信息内部每天会触发 500 余次 CODING 流水线，将代码构建、部署效率提升了 10 倍以上。

全球数字化进程的提速推动越来越多的企业级客户拥抱 DevOps 理念，也带来更广泛的 DevOps 市场需求。腾讯云将持续加大在云原生领域的探索与创新，并对 CODING 进行全面的产品战略与组织升级，为更多企业提供体验更好、效率更高的研发管理、敏捷开发及 DevOps 服务，帮助企业降低研发成本，提高交付效率，实现研发效能升级。

——腾讯云副总裁黄俊洪

我使用过的方案有：

• https://pub.dev/packages/melos
• https://pub.dev/packages/derry

melos 在 mono repo 下工作得很好，还提供了 vscode 插件； derry 也不错，不过暂时在 arm mac 下有 bug ，不是很完美

各位是如何做的？纯 shell 命令或者 vscode 插件都可以。

金融数字化步履不停，研发效能升级不止

秉“双区”建设之势，怀服务大湾区之志，深圳某大型银行（以下简称“A 银行”）在 2022 年全面开启以数字化转型为方向的第二个五年发展战略规划新征程。“零售+科技+生态”动力齐驱，A 银行坚持以科技敏捷带动业务敏捷，不断纵深推进数字化转型与场景经营。

然而，随着 A 银行数字化转型逐渐深入，快速扩张的 IT 建设团队给多团队管理及跨团队协作带来了全新的挑战，而不断变化的业务需求，也对研发资产的安全管控及研发交付的效率、质量提出了更高的要求。

为了让 IT 建设团队以更敏捷的协作、更高效高质的交付应对数字时代的业务需求，A 银行最终从多家厂商中选择引入 CODING 一站式研效平台，从研发效能升级入手加快其数字化步伐。

CODING 灾备异构方案，保障银行业务连续性

对于金融行业来说，保障用户数据安全以及业务连续性是重中之重。为此，A 银行内部有严格的数据容灾要求：硬件层面满足一份数据三个副本存储，任意一物理节点宕机均不影响平台正常运行使用，同时还要满足不同平台的异构备份。

为了帮助 A 银行完成基础设施升级，实现其灾备要求，CODING 的专家团队深入客户现场，最终制定了以 CODING 为基座的容灾及异构备份建设方案。在应用层面上，采用罗湖（主）-武汉（备）两地每日定时同步增量数据，两地 K8S 集群主节点挂载独立备份存储实现连续 7 日平台全量数据备份。同时，行内原有 GitLab 通过 CODING 持续集成流水线，自动实现定时触发备份，达到异构诉求；备份结果每日推送上报 IM 通信平台，管理人员及时感知。

CODING 为 A 银行制定的容灾及异构备份建设方案

在为 A 银行制定灾备方案的过程中，如果选择实时同步，会存在以下两个尖锐问题：

1. 实时同步会导致频繁读写，网络稳定性、平台稳定性难保障，且数据库易锁。

2. 从容灾环境切换回生产环境之后，数据一致性难保障。

因此，CODING 专家团队最终决定选择为 A 银行定时同步备份，备份机每日全量与增量备份，增量同步容灾环境；切换至容灾环境时，全量数据及增量数据备份，再次切换生产环境刷回增量，同时容灾环境备份停止。

经过严密的切换演练及数据一致性验证，CODING 平台满足 A 银行的高可用建设要求，能够大大降低源码资产数据丢失的风险，保障极端情况下代码资产安全。这也为 A 银行开发中心推动各团队使用 CODING 平台托管源码打下坚实的基础。

CODING DevSecOps ，实现持续安全交付流程闭环

除了满足银行严格的灾备要求，一站式 CODING 研发效能平台给 A 银行带来的价值远不止于此。A 银行比较注重整体研发流程的体验，一直期望能更好地管控其研发过程，充分利用自动化带来的便利。通过 CODING ，A 银行成功落地端到端的 DevSecOps 流程，实现代码的统一安全管控，打造了敏捷化、规范化、自动化的持续安全交付闭环，极大提升了软件交付质量与速度，降低研发成本，完成研发效能升级。

A 银行基于 CODING 落地的 DevSecOps 研发工作流

研发核心资产统一纳管

对于代码仓库的管理，A 银行原先使用了 Git 、SVN 等代码版本控制管理工具，源代码分散在各个项目组，没有统一的管理入口。而 CODING 提供的代码仓库功能，不仅支持 Git 、SVN 仓库类型，还支持导入 GitLab 、GitHub 等主流类型代码仓库，并提供仓库分组、团队-项目-仓库级别的精细化权限管控、代码评审、版本管理等功能，有力支撑 A 银行顺利将散落在各个工具的代码全部迁至 CODING ，实现组织代码资产的统一分布式管理。

除代码资产以外，A 银行还将不同业务线的文档、制品及构建资源统一接入 CODING 平台进行管理。CODING 打通了开发、测试、运维等各个研发环节的资产管理链路，利用一站式的优势成功帮助 A 银行实现资源整合，解决其面临的软件资产管理分散问题。

研发管理规范统一落地

在未使用 CODING 之前，A 银行内部缺乏分支管理规范，部分人员直接在主干分支开发，部分又会拉取分支开发，分支和版本管理混乱。在 CODING 团队的帮助下，A 银行先后制定适配行内传统单体应用和微服务应用的 Git 分支与标签管理策略，同时建立起统一的代码合并评审流程及追溯审计机制，最终形成 master 主干分支发布、feature 特性分支开发的过程分支管理模式。

A 银行通过主干-分支模型规范跨组织研发过程

主干环境：部署主干代码稳定版本，完整依赖，随时发版，持续保护和维护。

分支环境：包含某个迭代分支涉及的单个 /多个服务，用于联调和测试（这里未单独体现出测试环境，不推荐维护测试分支，采用 master 主干进行 daily build ，随时可部署环境，用于集成或联调测试环境，提前发现问题）

此外，A 银行发现研发规范很多时候依赖研发人员自觉遵守，缺乏一定的约束性。而 CODING 平台提供的研发规范机制实时反馈规范执行情况，自动拦截不符合要求的研发活动，“无感”地约束和督促研发人员遵循研发规范。结合行内实际研发诉求，A 银行在代码、分支、版本等方面均配置了对应的约束规则，并通过增加审核环节，实现质量管控并减少协作沟通成本。

安全活动融入自动化 CI/CD 流水线

A 银行的 IT 团队长期面临外部竞争与金融监管的双层压力，对业务诉求敏捷，对系统追求稳定。通过将代码扫描与制品扫描安全能力融入至自动化的 CI/CD 流水线，CODING 帮助 A 银行提升业务效率的同时还构建了代码安全质量护城河。

如下图所示，A 银行在 CODING CI 流水线中融合了一系列自动化安全活动。在代码检出时，系统会自动进行代码扫描，随后进行单元测试，在镜像被推送到 CODING 制品库之后，随之进行制品扫描。安全活动层层加持，消除了业务发布之前的绝大部分缺陷与风险。

CODING 代码扫描支持 16 种主流开发语言的扫描方案。在设置了扫描语言方案、质量门禁之后，代码检出时会自动对源代码进行扫描，自动生成问题列表，并附带修改建议。

通过问题概览大盘，研发人员可以清晰了解代码问题数量、代码圈复杂度、重复率等情况，极大地帮助 A 银行及时发现潜藏代码缺陷、安全漏洞以及不规范代码，提升代码的可维护性和稳定性。

在镜像构建并推送到制品库的环节，CODING 制品扫描能力会被自动触发。系统会对制品进行依赖分析，解析出制品引用的开源组件，再通过「腾讯安全开源组件漏洞特征库」识别出制品引用的开源组件存在的漏洞，输出漏洞报告与修复建议。A 银行的研发人员可以通过预设的质量红线判断制品质量，也可在详情页查看具体扫描结果。

DevSecOps 流水线一键复用

DevSecOps 的快速推广，单靠重复的人工复制自然是行不通的。得益于 CODING 流水线的可配置、可复用优势，A 银行针对行内常用的研发语言，结合原有脚本，输出了团队内公用的流水线模板，大大降低存量系统接入 DevSecOps 的门槛。不同业务小组成员一键即可复用自动化流水线，提高日常研发过程中的构建与发布效率。

研发效能全面提升，助力推进银行数字化转型

一站式 CODING DevOps 平台的最大优势，是给 A 银行提供了统一的研发入口，为其打通从项目管理、代码托管、代码构建、测试、应用交付到系统运维的研发管理全链路，还同时满足了银行严格的灾备异构需求，为 A 银行高效、高质交付业务价值提供了强有力的基础保障。在未来，A 银行会在行内全面推广并应用全新的基于 DevSecOps 的一站式 CODING 平台，充分利用先进的 DevSecOps 理念让研发链路运转得更顺畅、更高效、更安全。CODING DevSecOps 解决方案，作为 A 银行在数字化转型过程中的强力引擎，将会持续赋能 A 银行优化研发过程体验、专注研发效能提升，领跑数字化业务新赛道。

快来体验吧！

#腾讯会议应用市场全新上线# #会·得新应手#

中化信息技术有限公司，简称“中化信息”，是世界 500 强企业中国中化控股有限责任公司（简称“中国中化”）的全资直属公司，依托于中国中化的信息化建设实践，建立起从咨询、设计到研发、交付及运维的服务价值链，形成涵盖生命科学、材料科学、基础化工、环境科学、轮胎橡胶、机械装备、城市运营、产业金融等行业业务应用及创新应用的 17 条产品线及解决方案，致力于通过发挥信息科技的驱动与赋能作用，助力中国中化成为世界一流的综合性化工企业。

“线上中化”战略推进，更强韧的 IT 能力成为刚需

进入工业 4.0 时代，信息技术渗透至各行各业，产业数字化应运而生。通过互联网改造，传统企业能够打通产业链上下游，使设备、工厂、供应商、产品和消费者紧密地连接和融合，以智能化、数字化的方式为消费者提供更高品质的服务体验，打造更高价值的产业生态，构建强大的数字生态系统。

产业数字化转型的红利固然可观。为此，中国中化提出了“线上中化”的战略目标，大力推动公司内部的数字化转型工作，以数字化赋能公司高质量发展，推动中国中化走向世界一流行业。与此同时，“线上中化”的数字化战略对中化信息的 IT 能力提出了空前挑战。中化信息作为中国中化主要的信息科技平台提供商，肩负 “发挥信息科技的驱动与赋能作用，助力中国中化成为世界一流的综合性化工企业” 的使命，必须要不断提高其 IT 能力，持续打造创新的基础平台和解决方案，以支撑“线上中化”战略的夯实落地。

一站式研效平台建设，支撑研发全流程闭环管理

为了从根本上提高自身的 IT 能力，中化信息决定采用全新的研发管理模式。通过 CODING ，中化信息以 DevOps 方法体系为核心打造了新一代数字化研效平台，打通从需求、设计、开发、构建、测试、发布到部署的全流程，形成研发质量监控闭环，实现项目管理可视化、构建集成自动化、持续测试自动化、持续部署自动化，以此来快速响应业务需求，快速交付高质量的业务价值。

从敏捷方法论开始，围绕「项目」的精细化多角色协作

凭借 CODING DevOps 平台的多租户管理优势，中化信息根据产品或业务需求组建多个项目，再将需要协作的各方添加至对应项目，以此开展精细化的团队协作。以「项目」为单位，中化信息对人员权限和资源进行了统一的管理，让公司内部实现了产品 /项目经理、应用架构师、开发人员、测试人员和运维人员等不同角色在一个平台内高效协作。

CODING DevOps 平台承载业界先进的敏捷 Scrum 理论，提供强大灵活的项目管理功能，包括迭代规划、需求分解、状态流转、看板视图跟踪等等，帮助中化信息在公司内部快速落地敏捷项目管理模式。

根据研发团队既定的工作流程和模式，中化信息自主定义了项目中的需求、任务、缺陷等事项类型的属性及工作流，同时还通过全局项目协同配置对全团队实现了规范性管理，极大提升了跨角色、跨部门的协作效率。

代码统一管理，企业核心资产更安全

• 项目内多仓库集中管控

中化信息内部共有多达上百个仓库，且同时使用了 Git 和 SVN 两种版本控制系统，难以进行有效的统一管理。CODING 提供快速稳定的 Git/SVN 代码托管服务，并提供简单易用的外部仓库（如 GitLab 、GitHub 等常见外部仓库）导入功能，帮助中化信息将原有的 SVN/Git 代码仓库逐步迁移至 CODING ，实现在单个项目内集中管理对应业务团队的所有代码，完成代码资产的统一纳管。此外，每个代码仓库均支持单独的权限配置，让中化信息在集中管理代码之余，也保留了不同仓库差异化管理的灵活性。

• 面向安全的代码扫描

使用 CODING 前，中化信息内部主要通过人工审查发现代码安全漏洞，但人工的方式百密终有一疏，且耗费较多的人力。CODING DevOps 平台自带的代码扫描功能集成了 CheckStyle 、FindBugs 、SonarQube 等几十种工具、数千条规则，支持包括 Java 、C/C++、Javascript 、Python 、Go 、PHP 、Ruby 等十余种主流语言，高效替代了中化信息研发人员的人工操作。在开发人员提交代码之后，CODING 平台会自动分析代码仓库中的源代码，挖掘潜藏的代码缺陷、安全漏洞以及不规范代码，并且生成问题列表，给开发人员提供修改建议。另外，平台也会对代码质量进行度量，统计出结构异常复杂的方法及重复代码，帮助开发人员持续优化改进。

自使用 CODING 以来，中化信息大量且高频地使用 CODING 提供的 Java 代码扫描方案，提升了代码的稳定性和可维护性，极大地改善了团队的研发效能。

测试计划实时协同，保障上线前的质量卡点

中化信息内部的测试、产品、研发等成员角色均会参与测试计划。在这种情况下，测试、产品、研发的同平台协作变得尤为重要。通过 CODING 的测试管理功能，测试计划进度、用例评审结果、测试结果等信息实时同步。另外，在测试过程中，测试人员可以针对特定的测试用例一键提交缺陷，帮助开发人员快速完成缺陷复现。

除了上述的协同便利之外，CODING 也让中化信息的测试管理更简单、更灵活、更可视化。得益于树状结构的测试用例库，中化信息的测试人员能够复用已有的测试用例，灵活组织测试计划，大大提升了测试工作效率。与此同时，当测试里程碑结束时，CODING 平台生成的测试结论、图表、工作分布、测试耗时等多维度测试报告会自动发送给关注者。另一方面，测试管理人员也可以通过可视化甘特图纵览项目测试概况，准确把握团队工作量峰值、谷值，轻松改善团队工作规划。

自动化流水线，构建部署更快捷

对于新一代研效平台的建设，中化信息期望打造一条高度自动化、可视化的软件开发流水线，实现端对端链路闭环，减少研发过程中的人工操作，提高研发版本交付效率。CODING DevOps 平台提供的持续集成能力，正是帮助中化信息打造自动化流水线的高效利器。凭借 CODING 内置的几十种构建计划模板以及图形化编排界面，中化信息通过简单配置即可实现自动化的代码编译、打包、扫描，直至将产品的二进制包自动部署至公司内部的机器资源。即便出现部署失败的情况，研发人员也可通过详尽的日志快速定位问题。

CODING 流水线的低门槛使用及分秒级别的运行时间，让中化信息无比惊喜。如今，中化信息内部每天会触发500 余次 CODING 流水线，将代码构建、部署效率提升了 10 倍以上。

多维度管理视角，数据报表不可少

研发过程的可视化跟踪，也是中化信息研效平台升级的目标之一。CODING 提供多样化的报表类型，包括需求统计、缺陷统计、代码统计等，满足了中化信息在不同研发场景下的可视化分析需求。丰富的场景化卡片模板，无需进行复杂配置，即可直接使用；强大的数据分析能力，帮助中化信息对 IT 研发流程的各个环节进行精细化的跟踪和统计分析，建立从交付效率、交付质量、资源效率、完成情况等多维度分析的效能度量实践体系，覆盖效能管理全场景，为团队效能改进、领导层决策提供坚实的数据支撑。

持续交付“快又稳”，赋能“线上中化”新未来

“线上中化”数字化战略加速落地，中化信息作为中国中化的信息技术主力，始终走在转型前列。通过与 CODING 合作，中化信息打造了覆盖软件全生命周期的新一代研效平台，实现了需求、开发、测试、部署的一站式管理，大幅提升业务交付的效率与质量，强力支撑中国中化的数字化实现。在未来，CODING 会持续为中化信息的研发管理赋能，进一步强化其数字化研运体系，赋能“线上中化”新未来。

本期主题“轻量级云开发与云应用”，在「架构与原理」专场，您将看到 CODING DevOps 、Lighthouse 、CVM 等 CSIG 明星开发工具背后技术原理解析；您也将看到来自腾讯云 TVP 、腾讯云先锋、腾讯云合作伙伴英特尔的专业大神，分享其成长故事及心得体会。

实践出真知，Techo Day 还开设了「动手实验室」环节。您将体验到 Cloud Studio 、自动化助手 TAT 、PAG 等在开发环境的实际应用。实验室采用了企业微信小班互动的形式，让老师与开发者们在同一真实开发环境中进行实操，实时交流开发项目及技术细节，更深入地理解、更便捷地使用腾讯云的明星工具！

一直以来腾讯云都致力于为开发者提供更“化繁为简、轻而易用”的工具产品，从而降低开发门槛，提高研发效率。在晚上的「发布与升级」环节，您将看到覆盖云原生、机器学习、数字孪生、物联网等重点赛道的产品专家为大家讲述工具升级优化的理念以及未来愿景！

此次 Techo Day ，希望通过腾讯、腾讯云有关技术干货的课程分享与应用工具的动手实践，帮助开发者提升研发效能，解决日常工作中的应用所需，也为技术人群的同业交流、技术热点与技术趋势发布提供一个优质的交流平台。

本文作者：杨苏博

偏后端的全栈开发，目前负责腾云扣钉的 Cloud Studio 产品。对 WebIDE 领域中的 VS Code 和 Theia IDE 有深入研究与丰富实践；多年 Serverless 领域从业经验，是 Serverless First Malagu 开源框架的作者；热爱开源，敢于创新。

前言

Next.js 是由 Vercel 团队研发的一款全栈应用开发框架，我们使用 Next.js 开发前端页面以及一些轻量级的后端 API ，前端和后端都用 Javascript 技术栈，并且是前后端一体化的（在同一个项目中开发前后端）。另一个被大家所熟知的特性是它的服务端渲染能力，对 SEO 友好。Vercel 自身是一个用户体验极佳的 Serverless 平台，支持包括 Next.js 在内的几十种开发框架一键部署到 Vercel 平台。Vercel 平台自身拥有极强的适配扩展能力，第三方框架可以按照 Vercel 平台的适配规则自主进行适配。作为 Vercel 亲儿子的 Next.js 可以完美适配 Vercel 平台，通过 Next.js + Vercel ，让开发和部署都能拥有极致的体验。Vercel 团队信奉着“吃自己的狗粮”原则，很多应用都是基于自己的工具和平台开发的。

美中不足

Next.js + Vercel 看起来是如此的完美：通过 Vercel CLI 一键部署 Next.js 到 Vercel 。另外，Next.js 也能很方便地运行在云主机上。但是 Vercel 作为国外的 Serverless 平台，对于国内用户，总是存在种种难以逾越的限制。如何将 Next.js 完美运行在国内的 Serverless 平台变得尤为重要。

国内 Serverless 平台官方在如何让 Next.js 运行起来的问题上各显神通。让 Next.js 在 Serverless 平台上运行不难，而要做到像 Vercel 一样的极致部署运行体验却很有挑战。

在尝试将 Next.js 部署到国内 Serverless 平台的时候，比如腾讯云函数、阿里云函数计算，可能会遇到如下一些坑：

1. 运行适配困难：Next.js 的运行需要一个 HTTP Server ，而事件函数提供的是一个简单签名函数，无法直接运行，需要将事件函数模拟成一个近似 HTTP Server 的代理服务；

2. 代码体积过大：一个最简单的 Next.js 应用的代码体积为 245MB 左右，打包压缩后是 54MB 左右，而函数代码体积限制一般是在 50MB 以内（阿里云函数计算通过 OSS 方式上传代码可以超过 50MB 的限制，但不能超过 100MB ）。代码体积过大往往带来一系列副作用：

   a. 代码上传时间长，且容易失败，部署成本变大（可以通过 NFS 和 Layer 解决）；

   b. 依赖更多云服务，如使用对象存储服务部署代码包，又或者把体积大的 node_modules 目录上传到 NFS 服务上，然后挂载到函数上。总之，让应用架构变复杂；

   c. 冷启动时间变长，函数在第一次运行的时候，需要先加载远端的代码，如果代码包越大，则冷启动时间越长。

不过，通过腾讯云的 Web 函数和阿里云函数计算的 Custom Runtime ，可以解决第一个问题，因为它允许我们运行一个真正的 HTTP Server 。而第二个问题要困难很多，虽然其中部分问题可以通过一定手段缓解，比如冷启动可以通过预置并发解决，但是又会让运行成本变得难以接受。所以解决问题的根本还是在代码体积上。

为什么 Next.js 项目代码体积大

为了分析这个问题，我们需要先了解 Next.js 的架构。Next.js 是一种 React 的服务端渲染框架，集成度极高，框架自身集成了 Webpack 、SWC 、Babel 、Express 等，使得开发者仅依赖 Next 、React 和 React-dom 就可以方便地构建自己的 SSR React 应用，我们甚至可以不用关心路由。Next.js 的高度集成性，易于实现代码分割、路由跳转、热更新、服务端渲染和前端渲染。

在 Next.js 项目中，不仅仅包含了运行时所需要的依赖，还包含了本地开发、构建所需要的开发时依赖，而且开发时依赖体积又大。我们常见的解决方案是简单粗暴打包所有的依赖，从而导致 Next.js 项目代码偏大。

Vercel 官方如何打包部署 Next.js

Vercel 官方打包部署 Next.js 的方案比较复杂。Vercel 平台底层基础设施集成了 AWS Lambda ，Next.js 本质是部署在 AWS Lambda 平台上。为了能让 Next.js 在 Lambda 上运行，Vercel 官方提供了一个专门用于构建 Next.js 项目的构建器：@vercel/next。该构建器的逻辑大致是把 Next.js 中的每一个 API 和服务端渲染的页面都分别构建输出为一个函数，这一系列函数都归属与 Vercel 平台上的一个应用。这样就保证了每个函数的代码体积足够小。

Next.js 打包部署到国内 Serverless 平台最佳实践

解决函数适配困难：我们可以通过 Web 函数或者 Custom Runtime 来解决（不推荐使用自定义镜像的方式，因为自定义镜像冷启动很严重），并在其中运行一个 HTTP Server ，且简单适配 Next.js ，这里在 Next.js 官方有示例。

解决代码包体积过大问题：可以剔除掉运行时不需要的可选依赖和开发依赖，剔除方式如下：

npm install --omit optional --omit dev # 或者 yarn install --ignore-optional --prod 

说明：因为 swc 构建工具是通过可选依赖安装的，在运行时不需要，所以我们需要把可选依赖也剔除。

通过以上方式构建的代码体积由原来的 54MB 减小到了 18MB 。另外，值得一提的是阿里云函数计算 Custom Runtime 内置的 Node.js 版本为 v10.16.2 ，而 Next.js 最新版本要求必须是 Node.js 12.22.0+。所有直接部署在函数计算的 Custom Runtime 上的 Next.js 应用无法运行，此时我们需要自行将 Node.js 的二进制下载到我们自己的代码中（也可以通过 Layer 实现），然后指定新的 PATH 环境变量。

如果每次都需要做上面的操作会很繁琐，而且还需要自己写适配入口代码，以及 Web 函数和 Custom Runtime 所必须的 bootstrap 文件，且该文件必须拥有可执行权限，在运行时额外安装新版 Node.js 。其实这些能力在 Cloud Studio ( https://cloudstudio.net/) 云开发平台中已经内置提供了。针对一个原生的 Next.js 应用，使用 Cloud Studio 云开发平台可以一键部署到腾讯云函数或者阿里函数计算，对业务代码零侵入，零门槛，只需如下几步：

1. 登录进入 Cloud Studio 的 Dashboard 页面。

（ https://cloudstudio.net/）

1. 选择 Next.js 模板，并创建一个工作空间。

1. 切换到 Cloud Studio 云部署套件视图。

1. 选择腾讯云部署选项，并微信扫码登录。

1. 点击 [开始部署] 按钮，一键部署 Next.js 应用。

1. 点击 [访问] 按钮，即刻预览部署后的效果。

说明：同样的 Next.js 应用，无需做任何修改，采用上述一样的步骤一键部署。

Cloud Studio 是基于浏览器的集成式开发环境（ IDE ），为开发者提供了一个永不间断的云端工作站。其包含代码高亮、自动补全、Git 集成、终端等 IDE 的基础功能，同时支持实时调试、插件扩展等，可以帮助开发者快速完成各种应用的开发、编译与部署工作。用户在使用 Cloud Studio 时无需安装，随时随地打开浏览器就能使用。

目前 Cloud Studio 支持部署到腾讯云函数和阿里云函数计算，并且支持 15+ 前后端框架的一键部署。

写在最后

从开始的胡乱打包，到后面的精致打包，让代码体积变小，可以帮助大家避免一系列的坑。至于我们为什么不采用像 Vercel 那样的极致方案，原因有三点：实现成本太高、对 Next.js API 深度依赖，维护成本高和构建成多个函数管理成本极大（我们不可能像 Vercel 一样提供一个高阶平台）。通过 Cloud Studio（ https://cloudstudio.net/）云开发平台，我们可以一键部署 Next.js 等流行框架，对框架零改造。

团队域名：*.coding.net 还可以访问，但是一些功能也挂了（仪表盘-近期代码提交，1 个小时之前的 push 现在还不显示）

刚收到这个邮件有点吃惊，去 官网 看了下条件如下，除了第一条都无可辩解，第一条是不是不合适，保活？

2.8 您需知悉：为确保账号资源的合法合规及有效使用，CODING 有权在以下情况对账号进行回收或封禁处理，回收或封禁后 CODING 不再对该账号内数据作保留，由此带来的任何损失由您自行承担：

• 账号超过 24 个月时间无登录操作；
• 当您未使用合法的邮箱、手机号码、实名信息注册或绑定；
• 您的账号违反本协议中相关规定或法律法规，或应主管部门要求时；
• 其他 CODING 认为应当对您的账号进行回收或封禁的情形。

老百姓大药房是中国具有影响力的药品零售连锁企业，中国药品零售企业综合竞争力百强冠军、中国服务业 500 强企业、湖南省百强企业。

自 2001 年创立以来，现已成功开发了湖南、 陕西、浙江、江苏等 22 个省级市场，拥有门店 8000 多家，全国仓储面积超过 19 万 平方米。

数字智联时代，如何更好地服务“老百姓”？

随着业务规模不断扩大，老百姓大药房累计会员逼近 6 千万大关，每年服务 1.25 亿忠实顾客。在数字化时代，尤其是全球疫情流行的大背景下，消费者对服务体验和质量提出了更高的要求。给消费者提供“更齐全、更温暖、更专业”的服务，既是老百姓大药房“一切为了老百姓”的企业愿景，更是疫情时代关乎民生的企业责任。

在日新月异的数字智联时代，如何将线上渠道与线下门店结合，在风云变幻的市场环境中保持一定的敏捷性与灵活性？如何以业务需求和价值为核心，对内提升团队的业务响应能力和工程交付效率，对外提升服务质量与用户口碑？对于传统零售行业的老百姓大药房来说，敏捷转型无疑是最佳答案。

老百姓大药房希望运用新的工具和规范化的工作流程打造自组织的敏捷团队，树立敏捷交付理念，培养敏捷种子人才，提升团队的敏捷成熟度，从而使研发团队具备快速试错、验证假设的能力，以助力企业良性、高速发展。敏捷转型，是历史的选择，也是时代的呼唤。

Thoughtworks 先行，从 0 到 1 敏捷导入

Thoughtworks 在 17 个国家拥有专业卓越的跨职能团队，汇集了大量战略专家、开发人员、数据工程师和设计师。Thoughtworks 首创“分布式敏捷”概念，深知如何集全球团队之力大规模交付卓越的软件，致力于帮助客户开启流畅数字化之路，提升公司应变能力，引航未来征程。

在对老百姓大药房的研发部⻔现状、职责范围、组织结构、业务痛点、工作流程、使用工具及技术等背景信息进行深入调研之后，Thoughtworks 中国区的咨询师制定了基于 CODING 实现的敏捷转型计划，分批次、有秩序地在多个试点团队实施敏捷导入。

• 敏捷组织架构设计 在敏捷转型之前，老百姓大药房的业务团队和研发团队在战略上缺乏协同，业务需求的目标和价值经常无法很好地传递给研发团队，且跨组协作成本高，存在阻碍。为了更好地提升业务交付价值，Thoughtworks 指导老百姓大药房建立了以业务价值为核心的跨职能组织结构。

纵向为自组织的跨职能小组，包含产品经理、Scrum Master （通常由开发兼任）、架构师、开发人员和测试人员等，不超过 10 人。一个跨职能小组对应老百姓大药房的一个具体产品或者业务线，可以完整交付业务价值，并且能自行决定产品目标和自主决策。灵活机动的小团队模式，便于跨职能成员当面交流和讨论，更好地为共同的业务目标进行协作。

横向为同个职能内的的协同组织，由职能负责人牵头职能内的协同活动，协调跨业务线合作的资源，推动跨团队、跨业务线的协作与改进。

• 敏捷基础培训&实践辅导 成功的实践需以扎实的理论知识为依据。在老百姓大药房内部，多数成员尚未意识到敏捷开发和持续交付的价值和必要性，缺乏不断学习和提升的积极文化与氛围。针对这个问题，Thoughtworks 咨询师通过一系列培训导入敏捷价值观和管理实践，覆盖敏捷基础概念、产品经理及 Scrum Master 基础知识、DevOps 实践等方方面面，确保老百姓大药房的成员清楚地认识到敏捷是什么、为什么需要敏捷、并通过项目实战理解各个角色该如何在团队中发挥最大价值。

• 人员赋能：敏捷教练培养 除了对产品经理和 Scrum Master 进行日常实践辅导培训以外，Thoughtworks 还通过敏捷教练训练营的模式帮助老百姓大药房培养内部教练，以保障敏捷转型效果可持续、可推广。在 Thoughtworks 咨询师的带领下，组织内选定的种子选手经历了一系列强化培训、实践辅导及学习分享。最终选定的合格内部教练会带着“践行敏捷、推广敏捷”的使命，在老百姓大药房组织内作为推动敏捷变革的核心力量⻓期存在。

用 CODING ，打造规范化、可视化、自动化的敏捷研发管理体系

企业敏捷转型，不仅需要思维的转变，还需要通过工具承载敏捷的理念和流程。CODING 依托业界敏捷项目管理方法论与 DevOps 体系打造的一站式平台，打通了敏捷开发全生命周期的工具链孤岛及协作壁垒，助力老百姓大药房在组织内部打造规范化、可视化、自动化的敏捷研发管理体系。

项目与项目集联动，规范化业务协作

在使用 CODING 之前，老百姓大药房组织内部研发团队对业务的透明度有限。业务侧的需求目的、场景和价值传达不清楚，往往造成不必要的沟通和理解成本。不透明、无契约的协作造成了业务侧与研发侧无法形成充分互信，从而无法将业务价值最大化。

在使用 CODING 之后，老百姓大药房将原始业务需求统一在项目集中进行管理。一个项目集对应一个具体产品或业务线，然后通过不同的工作项对该产品 /业务线下不同模块的需求进行分类。业务侧根据业务战略规划里程碑，然后在对应的需求分类下创建子工作项，填写具体的需求背景、描述、目标 /价值，指定开始 /截至时间，即可完成需求登记。

通过「分解到项目」，该业务需求可被产品经理拆分到多个项目的用户故事和任务中实现。这对于跨团队、跨业务线合作的场景尤为重要。

业务需求在研发侧的映射是项目中的一个个用户故事，是敏捷协作流程中的最小工作单元。老百姓大药房组织内部对用户故事的书写进行了严格规范：必须描述清楚用户故事和验收条件，并提供必要的细节描述以及产品原型图等信息。用户故事是研发团队协作的基础，将验收条件澄清，才能让产品、开发和测试对“需求是否做好、做对”形成共识，确保团队“心往一处想，劲往一处使”，交付满足预期的业务价值。

通过项目集与项目的数据联动，需求开发的进度、风险以及资源情况对业务侧而言不再是黑盒状态；研发团队在项目中也可以清晰地看到用户故事或任务所承载的原始业务需求，理解要实现的需求目标和价值，做到既“知其然”，也“知其所以然”。视角分离的数据互通，让双方只需将精力放在各自最关注的部分，同时也极大增强了业务需求流转的透明度，确保双方对业务需求达成共识，加强双方的契约合作。

CODING 项目看板，可视化敏捷研发活动

看板作为可视化工作流的载体，是敏捷研发中必不可少的因素。老百姓大药房的研发团队可谓将 CODING 项目看板使用得淋漓尽致，使团队内的敏捷活动最大程度地可视化、透明化。

• 迭代计划 CODING 的 Scrum 敏捷管理项目模式提供了卡片式的待办事项列表，让老百姓大药房的研发团队在规划迭代时能以可视化的方式进行。在迭代开始第一天，团队成员会集中起来，围绕着 CODING 的迭代看板，讨论本次迭代的范围，估算所用故事点，然后根据团队速率确定迭代计划，并开启迭代。通过看板展示的多维度数据，团队成员可以清晰地知悉整个迭代要完成的用户故事、各个用户故事的优先级及需要耗费的预估工时等信息。这也使得老百姓大药房的团队成员能以共同的业务目标为核心展开高效的团队协作。

• 每日站会 在每日站会上，老百姓大药房的研发团队会使用迭代事项的看板视图同步每天的工作信息与问题。通过看板视图，用户故事的工作流转视觉化。哪些用户故事尚未完成、处于什么阶段、当前处理人是谁均一目了然。若用户故事已满足流转至下一状态的条件，直接拖拽至状态卡片，即可自动更新故事状态。对于存在风险（即将逾期尚未完成）的用户故事或者优先级较高的用户故事，团队成员通过明显标签即可识别，在站会中也会重点关注此类事项并展开必要讨论。

• 迭代回顾 针对每一个迭代，CODING 均提供了单独的概览与统计视图，为迭代回顾提供了重要的数据来源。在每个迭代的最后一天，老百姓大药房的研发团队会以 CODING 提供的事项状态趋势图、故事点燃尽图和事项分布图为依据，对本迭代的工作过程进行回顾，总结做得好的地方，分析需要改进的地方，在鼓舞士气的同时保持团队内持续改进与反馈的文化。

CODING 的项目看板以可视化的方式将老百姓大药房研发团队内的各个敏捷活动串联起来，有效降低了协作成本。这也恰好印证了 CODING 的一站式平台是基于敏捷方法论打磨的、用于实践敏捷研发的绝佳利器。

CI/CD 流水线，自动化持续交付

在实施敏捷转型之前，老百姓大药房面临的一大难题是研发团队内 DevOps 工程实践不足，严重影响了团队的交付能力。由于缺乏有效的自动化手段，每次版本发布都需要投入极大的人力，团队全员熬夜加班的情况时有发生。

CODING 提供的自动化 CI/CD 能力，给老百姓大药房的研发团队带来了极大的惊喜。将部署、发布等能力打包在 CI 流水线，并将代码度量、人工评审等环节固化在流程中，不仅能持续提升研发人员的代码质量，更是让运维能力左移至研发侧，加强了研发人员的自运维能力。以往需要通宵完成的版本发布，现在仅需几分钟即可完成，给研发团队两周一次的高频发版提供了强有力的保障。

自动化的 CI/CD 流水线在后续会逐渐从试点团队全面覆盖组织内部所有的研发团队，以满足持续业务发布的需求。除此之外，老百姓大药房对 CODING 自研的云原生开发工具 Nocalhost 和云原生应用生命周期管理工具 Orbit 也表现出了极大的积极性。开发环境上云，充分利用云计算构建弹性可扩展、可观察、易于管理的松耦合系统，无疑是支撑老百姓大药房持续业务创新的基石。

“人、流程、工具”三大要素相辅相成，助力敏捷转型成功

敏捷转型，对于老百姓大药房来说，无疑是一场大胆的革命。令人可喜的是，从试点团队的敏捷实施效果来看，这场革命取得了阶段性的胜利。 在针对老百姓大药房试点团队的调查中，100%的人都认为敏捷实施对团队起到了帮助作用。其中，83%的人认为目前的模式比以前更有秩序和节奏，77% 的人认为比以前更透明，而 59% 的人则认为团队的交付能力增加了。

这样的结果对 Thoughtworks 以及老百姓大药房来说都不意外。无论是 Thoughtworks 的咨询师还是老百姓大药房内部培养的敏捷教练，都反复提到：敏捷转型之所以取得成功，第一要素肯定是因为“人”。老百姓大药房高层的大力支持和推广、团队成员的积极参与和配合、以及咨询师的高度融入，是敏捷转型能够顺利落地的必要条件。除此之外，依托敏捷方法论而生的 CODING 一站式平台助力老百姓大药房将规范化的敏捷流程付诸实践，也是不可或缺的促成因素。人、流程、工具，在敏捷转型中缺一不可。

老百姓大药房的 CIO 对于本次敏捷转型的实施也给与了高度肯定。他提到，团队的积极性提高了，研发团队与业务之间对于交付价值有更深刻的意识。通过 CODING 软件系统，管理者可以随时掌握研发中心的项目状态，在发现风险时提前介入、从而更好把握项目成本与开发进度。这使得整个敏捷研发中心的开发管理过程得到落地性的优化。

在接下来的一年里，老百姓大药房会在组织内将敏捷模式从试点团队推广至全部研发部门，彻底实现自上而下的敏捷革命。CODING 会一如既往地提供支持，与老百姓大药房共同打造数字智联时代零售行业敏捷转型的标杆。

本文作者：程胜聪 - CODING 测试域产品总监

在业内如火如荼的 DevOps 转型过程中，自动化测试始终是热点之一，毕竟提供快速质量反馈是达成 DevOps 目标的关键。于是，作为测试领域的“皇冠”，自动化测试的落地实施始终为人们所关注。但是落地当中产生了种种问题甚至是争论，经久不衰，无形中给自动化测试体系建设蒙上了层层迷雾，让人疑惑。下面我们就一些踩过的“坑”进行探讨，期望这些经验分享能够有助于揭开迷雾、看清方向。

要不要做自动化测试？

在软件工程理论当中，测试相对开发来说是个“辅助”的角色，而软件交付的产物也不必包括测试的产出。随着软件研发过程的复杂度提升，虽然还是辅助角色，而且其价值仍然难以单独衡量，但是测试对质量保障的作用已经深入人心，以至于从 10 多年前开始，已经没有人会挑战测试作为研发体系中基本角色的存在了。

然而类似的，作为“辅助的辅助”，测试领域中的自动化测试又开始面临着同样的质疑：自动化测试到底有没有价值？这个问题在 10 多年前开始被频繁提出，而且难以回答。作为处于辅助地位的投入，人们肯定会密切关注其成本大小以及跟收益的对比。自动化测试最开始出现，是为了替代重复性的手工操作，从而节约回归测试的人力成本，于是要获取正向收益的前提是执行的次数够多： 自动化收益 = 迭代次数 x （手工执行成本 – 用例维护成本）- 用例编写成本

所以，在 DevOps 时代的频繁发布测试场景下，自动化测试的价值得到了充分展现。要不要做自动化测试的问题如今已经不会造成困扰，因为当下业内已经形成了一致的认识：自动化测试是持续测试的基础，是 DevOps 时代中不可或缺的实践。此外，由于自动化测试的执行效率很高，体现出来的时间成本优势更是明显，甚至比成本优势更能戳中这个快速发布时代的痛点：因为不这样做的话，我们会越来越难以应对短周期发布所需要的快速有效验证。

有策略地开展自动化测试

测试体系建设需要分层策略指引、接口测试往往最优先

罗马不是一天建成的，为了达成自动化的目标，进行自动化测试体系的建设是需要投入资源和人力的。因而在具体落地过程中，我们需要充分考虑 ROI ，来设计符合实际情况的目标达成路径。自动化测试确实有很大价值，但不代表我们应该无节制地投入到各种类型的自动化测试当中：自动化测试是为了验证既定逻辑是否符合预期，在需求变更频繁的场景下，自动化代码的维护成本不可小觑。所以我们需要合适的策略，来指引自动化测试的实施——金字塔模型。

不少人对金字塔模型的第一印象，是其给出在 3 种测试上的投入占比建议：单元测试最多、接口测试居中、UI 测试最少，比如 70%、20%、10%。但更为重要的是，Mike Cohn 提出了对测试进行分层的理念，以及给出了每个层级的测试优缺点：越接近用户使用界面的高层次测试，粒度越粗，效率越低，写的测试应该越少；反之越接近底层代码的测试，粒度越细，效率越高，应该写的更多，也应该执行得更频繁。

而在实践当中，每个企业面临的场景不同，投入情况也不一样。比如现实情况可能并不是金字塔而是纺锤形状的，中间的接口测试占比最高。种种实践表明：在自动化测试建设的初期，接口测试往往是团队开展自动化测试的首选。这是因为接口测试兼备执行效率和体现业务价值两方面的优点，在这个领域进行资源投入较为容易被技术团队和业务团队共同接受。而且由于接口定义的稳定性也较高，其维护成本也是可控的。所以相对单元测试和 UI 测试来说，接口测试的投入产出比可以说是最高的。

接口测试以接口定义管理为基础，契约变更的同步提醒和 Mock 是关键

接口测试通过调用接口来达成测试验证的目标，既包括系统与系统之间的接口，又包括同一系统内部各个子模块之间的接口。接口测试的重点是检查系统 /模块之间的逻辑依赖关系，以及进行交互的数据传递的准确性。接口测试是黑盒测试的一种，却是最接近白盒测试的黑盒测试，故而在较早发现缺陷和执行效率上也接近于单元测试，往往被称为“灰盒测试”。

接口测试的用例一般包括单接口用例和基于业务场景把不同接口集成到一起的多接口用例。单接口用例是基础，而且也是开发调试过程所需。业内比较流行的是用 Swagger 进行接口文档管理，Swagger 预定义了主流编程语言相关的代码注解，可以在接口实现代码变动之后获取接口文档的更新，自动反映接口变更的功能对自动化用例的维护来说非常重要。

多接口用例则是测试人员根据对需求功能的理解所设计出来的，这部分用例就充分展示了自动化测试的业务价值。由于这部分用例相对复杂，团队会需要为之准备基础框架，甚至打造脚手架来提高编写效率。在实现上一般会包括接口规范定义、接口间调用的代码管理、测试数据的存储管理、执行调度平台、结构化统计报告这几个部分的能力。于是在业内也出现了不少在这个领域的效率工具，比如 Postman 、ReadyAPI ！、Robot Framework ，以及“低代码”的平台 apifox 、Eolinker 等。

有了接口的契约定义，就可以对未上线的接口实现 Mock （测试替身或者挡板），这样就可以不用依赖于具体的开发实现而构建场景测试用例，有利于测试开发之间或者不同开发者之间的并行协作。现在搭建 Mock 解决已经有很成熟的框架，比如 Mockito 、EasyMock 等，或者平台型工具 postman 、apifox 都能够很方便的搭建 Mock Server 。

总的来说，有了可以遵循的接口定义规范、加上接口变更的信息同步、以及提供对接口的 Mock 服务，在团队中就可以基于 API-first 的方式实现并行开发、调试和测试了。

高效编写自动化用例有没有“捷径”可走？

现今系统的功能越来越强大，也越来越复杂，写好自动化测试用例不是简单的事情，这一块也是不可忽视的投入。于是在自动化建设的实践中，我们自然而然会追求更高效的方法。追求高效之路没有问题，只是如何才能避免走歪呢？下面我们对一些常见的“提效工具”进行探讨，期望可以对现实的实践起到借鉴作用。

编码方式向左，低代码平台向右？

现今系统的接口往往错综复杂，要做好接口测试，既需要对业务层面的系统 /模块之间的逻辑关系有深刻理解，又需要掌握好技术层面的各种测试框架和相关编码技术。可以说，接口测试自动化的建设仍然面临着较大挑战，人们自然会寻求高效的方式进行实施，相应的就出现了对自动化用例低代码平台的需求。于是出于“对测试同学技术能力的现实考虑”，研发 Leader 往往会“以负责任的态度”，寻求“入坑”去追求低代码平台。低代码的概念在近两年如此之火，更是导致这个话题反复被提起。那么我们在写自动化测试用例的时候，到底应该是遵循老老实实写代码的方式，还是应该大胆采用低代码平台去快速提升覆盖率呢？

低代码平台的优势是什么——那就是通过降低自动化编写的技术门槛，让编码能力较弱的人员也能参与进来，从而较快地从 0 开始提升自动化覆盖率。一般低代码平台都是基于接口测试自动化的数据和代码分离的原则而进行设计的：先把常用的接口操作方法抽象出来，并且封装好（在 Robot Framework 中称为关键字），然后通过在界面上拖拽组件组合成一个逻辑流程，再加上数据传递驱动形成一个完整的业务场景。所以使用低代码平台给人的体验，就是通过表格表单的操作实现自动化用例，感觉上“不需要编程能力”。

然而，在实践中使用低代码平台进行复杂业务测试时，对数据字典、操作的抽象（关键字）、设计能力的要求还是很高的，不然碰到相对底层逻辑的变更，那就需要改动茫茫多的用例。从不少团队的实践来看，低代码平台在中长期维护上面对多变业务场景会显得难以为继：缺乏技术抽象思维的、非工程背景的业务（或者业务测试）成员很难持续“重构”现有的用例。而为了保证用例的准确性和整体运行效率，对自动化用例的重构是不可避免的。面对着一系列的“表格式”文档，工程师普遍认为这种方式是脆弱和低效的，从而不愿意接手。

所以，是否使用低代码平台取决于我们对业务发展的预期：对于非核心业务，如果预期模块是相对固化而不需要演进的，那么不妨大胆利用低代码平台开展快速覆盖的自动化测试，低代码平台确实缓解了团队管理者的“自动化建设焦虑”，帮助团队迈出自动化测试的第一步；而对于核心业务、注定要跟随着业务发展而进行技术演进的模块，那么就需要充分考虑中长期达到提升自动化编写效率的目的。原则上我们应当承认，自动化测试用例的编写，事实上存在着“工程门槛”，也确实是需要“工程门槛”的。哪怕使用低代码平台，也需要拥有“工程师思维”，考虑“关键字”和数据结构的封装和维护。总的来说，应该通过增加可视化、减少重复性工作的方式，让工程师更加高效地编写自动化用例；而不是“无限制的降低门槛”，以期望未经训练就可以写出健壮的、高质量的自动化测试用例。

流量录制回放方式可以取代手工写自动化用例吗？

关于接口测试，现实中还存在一种情况：那就是对现有系统缺失的接口测试进行“补锅”，需要对已存在的众多接口场景进行测试用例的补充覆盖。如果采用传统的测试方式，是从接口定义开始，手动梳理系统接口文档、对照着录入测试用例、写好逻辑断言，然后还要在深入理解接口后，构造相应的测试数据，这是常规的方式，也是正确的方式，但是毫无疑问是个慢工细活。当我们需要在较短时间内完成一轮补充的话，这个方式显然做不到。于是一种新的解决方案出现：自动采集真实的流量并形成接口测试用例。

流量“录制”指的是对线上的流量请求和返回进行拦截录制，然后记录下来形成测试用例；而“回放”指的是把线上录制下来的请求和返回，复制到一个准生产环境服务中，测试新功能和服务是否满足要求。真实（数据）和高效，是流量录制回放方式的两大优点，而其主要的应用场景包括：

1. 出现线上故障时，录制的真实流量可以回放到开发 /测试环境来进行调试分析，这是用到“真实”的场景，也是流量录制回放功能的基础价值；
2. 对录制好的真实流量进行复制放大、应用到预发布环境中作为压测用例，这也是用到“真实”的场景，真实流量对压测来说确实是个很好的补充；
3. 如上文提及，批量形成第一次的回归自动化用例集合，这是用到“高效”的场景。

实现流量引流录制的主流方式包括：Nginx 的镜像复制、GoReplay 直接监听网络接口捕获 Http 流量、基于日志解析，以及针对应用业务自研复制引流功能。业内最为流行的工具当属 GoReplay 和 TCPCopy ，其中 GoReplay 尤其简单易用，而且无代码入侵，对线上应用的影响可以忽略不计。

那么是不是有了流量录制回放的功能，就不再需要手工写自动化用例了呢？肯定不是的，我们还需要踏踏实实写自动化用例。首先，流量录制回放是后置的“补锅行为”，没有人希望等到接口上线之后才去测试，所以往往是一次性的工作；其次，流量录制也是需要较长时间才能达到较高的用例覆盖，对于非常用的边界，但是重要的场景我们仍然需要人工去设计；再次，对于构建复杂的多接口组合的场景用例来说，流量录制的方式还难以做到：对录制下来的流量进行二次加工，可能还不如动一下脑筋去人工实现。

UI 测试用例的录制方式靠不靠谱？

UI 测试的方式非常直观，也很容易看到业务价值，但是 UI 界面的快速迭代特征导致测试用例的有效生命周期很短，维护成本极高。所以，相比起单元测试和接口测试而言，脆弱、复杂、以及投入产出比低下的 UI 自动化测试，不应该成为我们的主要投入领域，一般用于覆盖关键并且 UI 处于稳定状况的业务。

UI 自动化用例还可以通过录制方式来快速生成，现今比较流行的提供录制方式的自动化测试工具包括：面向桌面程序的 QTP 、Ranorex 、面向 Web 页面的 Selenium IDE 、Chrome DevTools-Recorder 、阿里的 UI Recorder 、面向移动端程序的星海“鲸鸿”、WeTest UITrace 等。

现在业内存在一个有趣的现象，那就是尽管录制得到的 UI 自动化用例基本上不具备可维护性，但是不少人还是会希望采用录制方式实现自动化。究其根本，是大家对 UI 测试的期望值跟一般自动化测试不一样：承认 UI 界面的易变性导致自动化用例维护成本很高的事实，从而干脆当作“短暂”的、“用完即弃“的回归测试用例——只要录制足够简单快速，大不了过一段时间（下一版本）就废弃重新录制。

出于“物尽其用”的观点，做这样的选择看上去无可厚非，但是也要关注团队成员对这种方式的接受度。毕竟反反复复去做一些注定了要放弃、从头再来的事情，对人的士气打击也是显而易见的。从长远来看，我们还是更希望从相对稳定的层级，比如组件级别去覆盖 UI 的测试，也就是说前移到单元测试环节。毕竟现在前端框架已经很成熟，完全可以基于框架对 UI 进行细粒度的单元测试。而对于端到端的 UI 测试，还是应该谨慎投入。

“聪明”的执行自动化用例

以下自动化测试代指的是集成级别测试，不包括单元测试

写好用例代码是自动化测试重要的第一步，但是只有执行了才能让其价值得到展示。如同自动化收益公式所表述的那样，自动化测试用例执行次数越多越好。而在实践当中，当我们不能每次执行全量回归用例集时，就需要考虑测试范围和效率之间的平衡，有策略地执行自动化用例。下面两点是关于自动化价值的核心原则，需要在自动化测试体系建设中牢记：

原则 1：自动化测试价值的根源在于业务，应该基于业务驱动自动化测试，始终关注优先级最高的需求所对应的测试。

原则 2：自动化测试价值的放大器是测试执行频率，只有跑的次数多了，才能够赚回成本；而只有单轮次执行的够快，才能保障较高的执行频率。

CI/CD 中跑自动化测试会遇到什么“坑”？

从瀑布模式时代开始，传统的自动化测试执行方式是 nightly-run：设置任务在每天下班后跑全量回归用例，然后第二天拿到结果后再去处理执行失败的 case 。而之所以做不到实时跑自动化测试，就是因为自动化用例累积到一定数量之后，需要好几个小时才能执行完一轮。然而在 DevOps 时代并不会有如此“宽裕”的时间留给回归测试，会期望把自动化测试嵌入到 CI/CD 流水线之中，提供及时的质量反馈，例如下面几种情况：

1. 自动化测试嵌入 CI 中，也就是每次把新特性的代码合并（ Merge Request ）到主干分支之后，除了需要跑一次全量单元测试外，往往会跑一次冒烟测试用例集；
2. 自动化测试嵌入 CD 中，在每次执行生产环境部署动作之前，确认在预发布环境上跑一次全量回归测试用例集；部署完成后还会在生产环节跑一次冒烟测试用例集；
3. 在团队能够实现迭代内及时编写好自动化用例的情况下，CI 过程中还需要执行已完成特性所对应的用例，确保代码变更之间的相互兼容；
4. 甚至在迭代内，团队中的成员可以自由创建 CI 来执行任意一个选定的自动化用例集。

一般来说，CI/CD 对运行时间是非常敏感的，所以在流水线中的集成测试部分不能耗时过长。如果不加控制地扩大测试用例集范围集成进来，那么运行时长必然不受控制。

设想一下，随着代码写的越来越多，每次跑自动化用例所花费的时间越来越长，最后只能降低执行自动化测试的频率……这就比较无语了，明明已经写好了这么多代码，却发挥不了价值，那我们还需要努力写更多自动化用例吗？这样的“坑”相信很多人都碰到过。自动化测试原本功能很强大，但现在被束缚在笼子里面，这样的困境该如何破解呢？既然每次按部就班执行大量测试用例的方式不可取，那就需要找到更优的方法，来实现“更聪明”地执行自动化用例。

要执行得更快，第一个想到的解决方案自然是并行执行，把用例分发到分布式的机器环境中。而要做到这点，则需要设定规则保障用例之间的独立，并且做好测试数据的管理，让每次用例执行改动后的数据都能复原。只是这样做会让复杂度大大增加，而且问题出现后也难以排查。除此之外还有一个很重要的问题：每次跑的都是全量，中间夹杂着大量无效执行的用例，那么因此得到的笼统的通过率又能够说明什么问题呢？除非设定简单的标准，就是要全部通过，但是现实中因为网络抖动导致的延时、复杂的数据更新等等原因，都会导致零零星星的失败。所以，并行执行还不能完全解决问题，我们还需要另辟蹊径：如果跑自动化测试用例时，可以根据变更来确定用例范围，而不是每次执行都覆盖全量用例，是不是就可以控制测试执行的时间呢？答案就是精准测试——通过建立变更和测试的对应关系，从而更有效的验证变更，减少不必要的全局回归。精准测试从实现上大致上包括两种：基于代码变更确定用例集，和基于需求变更确定用例集。

基于代码变更来自动确定用例集，是将测试用例与程序代码之间的逻辑映射关系建立起来，反映的是代码的测试覆盖率。这个目标非常宏伟，只是目前业内的方案还不成熟，还需要搭配大量的人工检查核对。而基于需求变更来确定用例集，则是建立测试用例与业务需求之间的映射关系，反映的是需求的测试覆盖率。这个方法在技术上听起来不是那么高大上，只是通过管理上的约束来实现，但是已经能很好达到我们的目的。CODING 就是基于这样的逻辑打造了自动化用例库，目标是让 1 ）和 2 ）的实践得到顺畅落地，乃至实现 3 ）和 4 ）的自由执行某个自动化用例集。

CODING 助力实现“业务驱动自动化测试”

CODING 测试产品推崇的是“业务驱动测试”：一切从业务需求出发，通过建立自动化跟业务需求的关联，可以让自动化有的放矢的扩大覆盖率，而不是凭空随意去写测试代码，产生重复的无效测试。

同时，CODING 自动化用例库通过对自动化测试代码进行解析，把得到的函数列表匹配到相应的功能用例，基于已有功能用例与需求的关系，形成自动化用例与需求功能的映射关系：

基于这样的关联关系，我们就可以顺藤摸瓜，根据某个自动化函数运行失败，找到对应哪个需求有问题，然后根据需求的优先级或者影响范围决定是否继续下一步，是打回修复问题还是决定继续发布上线。

首先，建立自动化代码和功能用例的匹配关系，自动化覆盖率“一目了然”。

CODING 提供示例代码导入，帮助用户通过在代码中按照规则在注解 /注释中填写功能用例 ID ，或者人工判断，让解析出来的自动化代码函数跟已有的功能用例进行匹配，逐步提升功能用例的自动化覆盖率（也为精准测试打下基础）：

然后，在迭代进行当中，能够选择性执行特定的自动化用例集。

在普通测试计划中，可以圈选部分功能用例来执行对应的自动化用例；而在迭代测试计划中，圈选特定需求后，对应的功能用例列表也就产生了，从而实现业务驱动自动化用例的执行。CODING 会持续加强灵活执行自动化测试方面的能力，提供更加顺畅的“聪明”执行的场景方案。

总结

自动化测试体系的建设是个系统工程，涉及到人、技术、流程等方方面面，我们尤其需要全局思维、权衡利弊，“没有最好的、只有最合适的方式”。

首先，应该在团队层面对齐自动化测试的目标。因为质量保障是有成本的，不能无限制的投入，没有清晰的质量预期就无从着手去制定实施路径。不论是团队成员的能力建设，还是自动化测试技术框架选型，整体工作流程的设计都必须以此为基准。

其次，技术框架 /工具的选型应该要适配现有或者目标工作流程。对于希望打造研发一体化工作模式的中大型团队，在工具选用和流程制定上就需要体现跨职能的协作性，而且要向业务对齐，并且要充分考虑团队的持续效率。比如让自动化测试成为 DevOps 持续集成 /持续部署的一环，自动化测试要体现业务价值（保障对业务需求的覆盖），然后关注测试脚手架的可维护性，形成对自动化用例 /测试数据的重构，测试执行效率及时调优的制度规范。

最后是对人的发展，业务的变化带来技术和流程变革的要求，最终的落脚点还是要依靠人的成长。我们在制定目标、设计流程、选用工具的时候，会考虑到团队的适配度。团队成员也会随之产生职责变化甚至技能升级要求，需要关注个人体验，并对其进行引导和培养，实现“有温度”的转型。曾经风风火火的“去测试化”风潮的回落，正说明了测试的角色不会消失，测试开发最终还是测试，只是让测试角色“回归”到工程师的本源。

点击开启高效云端研发工作流

本文为 CSDN 博主「祈晴小义」（黄鑫鑫：腾讯云 CODING DevOps 研发工程师、Nocalhost 项目的核心开发者）的原创文章，并根据作者在 CSDN 云原生 Meetup 深圳站的演讲内容进行了整理，主要分享 Nocalhost 在解决云原生开发问题上的思路和探索，并展示 Nocalhost 为云原生开发带来的全新体验。

云原生场景下的开发痛点

当我们的应用架构从传统应用过渡到云原生应用的时候，会发现应用架构的复杂性大大提升了，原来的传统应用组件少，部署简单，我们往往可以在本地开发完一个传统应用后，把它丢到服务器上就能跑起来。而对于云原生应用来说，应用被拆分成一个一个粒度更小的微服务，各个服务之间有着错综复杂的关系，从而让开发环境的搭建和服务的调试变得异常困难。

本地部署 VS 集群部署

当我们要开发云原生微服务应用时，如何将我们的开发环境搭建起来呢？常见的有两种方式：本地部署和集群部署。

本地部署是将一整套微服务应用部署到本地的开发机器上，如下图所示：

这种方式会带来以下几个问题：

1. 影响开发机器的性能。微服务应用往往规模比较大，动辄几十上百个服务，都泡在自己的开发机上可能会让电脑变得很卡，影响工作效率。

2. 环境无法共享，资源浪费严重。当我们需要在本地部署起整套规模比较大的微服务应用的时候，就需要使用配置较高的开发机器，并且每台开发机器的开发环境只有一个开发人员能使用，即便该开发人员只需要开发其中一个或某几个服务，也无法将其它使用不到的服务共享给其它开发人员使用。

3. 对于一些规模很大的微服务应用，本地机器可能还没有办法跑起来。

另外一种方式将微服务应用部署到云上的 K8s 集群里，如下图所示：

这种部署方式可以较好地提高资源利用率，但是它会让开发和调试应用时的反馈链路被大大拉长。

我们开发传统应用时的工作流是：在本地编写好代码 -> 把代码进行编译 -> 运行程序查看结果，如下图所示：

这个过程往往很快，所以我们可以在做完一次代码的小改动以后，就把它运行起来查看结果。

但是在开发 K8s 集群上的应用时，工作流变成了：修改代码 -> 编译程序 -> 将程序打包到 Docker 镜像 -> 将 Docker 镜像推送到镜像仓库 -> 修改集群中容器的镜像版本，等待 K8s 将新版本的镜像部署上去 -> 查看结果，如下图所示：

这个流程可能需要耗时几分钟，当这个循环反馈被大大拉长了以后，无疑会让开发的效率大大降低。

目前主流的云原生开发方式

手动打包推送镜像

这种方式是最原始的方式，工作流大体如下：

编写完代码以后，在本地编译生成二进制文件或者 jar 包之类，然后通过 Dockerfile 构建出 Docker 镜像，再将镜像推送到 Docker 仓库，再通过修改工作负载的 yaml 定义中镜像版本，部署新版本容器的任务则交给 K8s 去做，只不过部署调度的过程可能有点漫长，需要等待 K8s 将新版本的 Pod 调度运行起来之后，我们才能看到代码修改的效果。如果代码改动得频繁，这个流程显然是非常繁琐的。

CI/CD 流水线

这种方式和第一种方式的流程大体上是一样的，只不过是通过 CI/CD 的能力，把手动的操作改成了自动化的流程：

这种方式的工作流是：在本地修改完代码，把代码推送到代码仓库，从而触发代码仓库配置好的 CI 流程，把代码编译构建成应用程序（如二进制或 Jar 包），并打包成镜像，之后会触发所谓的持续交付（ Continuous Delivery ）机制，将镜像推送到制品仓库里，最后再触发持续部署（ Continuous Delivery ）流程，将新版本的容器调度部署到集群中。虽然使用 CI/CD 以后，可以减少大部分手工操作环节，但整个流程花费的时间仍然很多，事实上，CI/CD 更适合在发布应用环节使用，而不是在开发应用环节。开发环节更注重的是能够快速得到反馈从而验证自己的想法，当我们的修改需要提交到代码仓，在 CI/CD 流水线跑完了以后才能看到效果，会限制我们使用简单的尝试，来从几种方案中找出最优的一种，或者定位 bug 的原因。

流量转发

流量转发的思路是：将集群里访问开发中服务的流量转发到本地。如下图所示：

当需要开发 D 服务时，将集群中访问 D 服务的流量转发到本地开发机器上的某个端口上，在本地写完代码以后，直接将应用程序在本地跑起来即可。实现这种方式的相关产品有：kt-connect 和 telepresence。

在本地直接运行应用程序固然可以缩短循环反馈，提高开发效率，但这种方式也有一个很大的问题：许多运行在 K8s 集群上的服务会依赖其它 K8s 资源，例如依赖 ServiceAccount 、ConfigMap 、Secret 、PVC 等等，这样的服务要在本地跑起来并不太容易。

在容器里进行开发

这种方式的思路是：当我们要对某个服务进入开发时，先让要开发的服务进入开发模式，然后将代码同步到容器中，直接在容器中把开发中的代码运行起来：

这种方式同时解决了开发循环反馈过慢和服务依赖集群问题，是目前云原生开发中较好的实践，也是 Nocalhost 支持的主要开发方式之一。

Nocalhost 初体验

第三部分主要是以 Demo 演示的方式来带大家体验 Nocalhost 的特性，感兴趣的同学可以前往深圳站 Meetup 视频回放，从 01:26:15 处开始观看。 https://live.csdn.net/room/csdnnews/yCHrYqnM

Nocalhost 核心机制

Nocalhost 是如何实现在容器中进行应用程序的开发的呢？在一个服务进入开发模式时，Nocalhost 所做的核心工作有以下 4 个步骤。

缩减副本数

开发应用程序时，我们只需要在一个容器里运行正在开发中的应用程序，如果存在多个副本，我们通过 Service 访问该服务时，就无法控制流量只访问到我们正在开发中的应用程序所运行的那个副本，所以 Nocalhost 需要先将工作负载的副本数缩减为 1 。

替换开发容器镜像

生产环境运行的容器往往会使用很轻量级的镜像，镜像里仅包含运行业务程序所必须的组件，而缺少编译构建业务程序所需的相关工具（如 JDK ）。在对某个工作负载进行开发的时候，Nocalhost 会将容器镜像替换成包含完整开发工具的开发镜像。

增加 SideCar 容器

为了将本地的源代码改动同步到容器中，我们需要在容器里运行一个文件同步服务器。为了使文件同步服务器进程和业务进程解耦，Nocalhost 将文件同步服务器运行在一个独立的 sidecar 容器中，该容器与业务容器挂载相同的同步目录，因此，同步到 sidecar 容器中的源代码在业务容器中也可以访问。

启动文件同步客户端

由于文件同步服务器监听在容器里的某个端口上，我们在本地无法直接访问，所以 Nocalhost 会把一个本地随机端口转发到容器里文件同步服务器监听的端口，打通文件同步服务器和客户端的网络，然后再启动本地的文件同步客户端。文件同步客户端启动后会通过刚刚转发的本地随机端口和文件同步服务器建立通信，之后便会开始进行文件的同步。

在以上步骤完成后，Nocalhost 会自动打开一个进入到远程容器的终端，通过该终端，我们就可以把实时同步到容器里到源代码直接运行起来。

Nocalhost 高级特性

Duplicate 开发模式

Nocalhost 默认的开发模式是将集群中原本正常运行着的服务给替换成开发容器，如下图：

这种方式存在以下问题：

1. 开发时会影响环境的使用。当对某个服务进行开发时，该服务在开发过程中可能会由于代码修改有问题导致异常甚至奔溃，集群里又有其他服务依赖该服务，从而影响到整个环境的使用。

2. 无法支持多人开发同一个服务。

为此，我们可以使用 Duplicate 开发模式，这种模式下，Nocalhost 不会对原有的服务做任何修改，而是复制出和一个原有服务一样的副本来进行开发，如下图所示：

这种模式下，多人可以对同一个服务进行开发，每个人都拥有自己的开发副本，集群原有的环境也不会受到任何影响。

Nocalhost Server

Nocalhost 除了通过 IDE 提供方便开发 K8s 应用的插件外，还提供了一个适合企业级开发环境管理的 Nocalhost Server，以下是 Nocalhost Server 的管理界面：

Nocalhost Server 可以提供集群、应用、人员权限上的管理，关于 Nocalhost Server 的详细介绍，可以参考官方文档上的介绍。

Mesh 模式

前面我们提到，如果要实现多人开发同一个服务，可以使用 Duplicate 开发模式，但这种方式也有一个局限性，就是只能在本地通过 API 接口请求去访问开发中的副本，没办法通过应用的入口地址来访问。对于需要通过统一的应用入口来访问开发中服务的场景，我们可以使用 Nocalhost 的 Mesh 模式。

Mesh 模式会为每个人分配一个 MeshSpace ，不同的 MeshSpace 通过在流量中带入不同的 Header 来控制从应用入口进来的流量的访问链路。

使用 Mesh 模式要求开发环境通过 Nocalhost Server 管理，并且应用需要有 Header 透传和使用 Istio 进行流量转发的能力，关于 Mesh 模式的使用可以参考官网文档 （文档目前还不是很完善，更详细的信息可以直接通过 GitHub 联系 Nocalhost 的开发团队）。

点击阅读原文，一键开启云原生开发环境

本文作者：黄鑫鑫 - Nocalhost 项目核心开发者 腾讯云 CODING DevOps 研发工程师。硕士毕业于中山大学数据科学与计算机学院，曾负责过平安云主机及国家超算中心容器云平台等相关业务，熟悉虚拟机，容器，K8s 相关技术，专注于云原生领域

简介

本文通过使用 Nocalhost 将本地开发机无缝连接到一个远程 Kubernetes 集群， 并在本地使用 Goland 来开发和调试 Kubernetes 集群中的 Apache APISIX ingress controller。Nocalhost 让我们可以使用现有的技术栈来顺畅地开发和调试类似 APISIX ingress controller 的 K8s 应用。

本文包括：

1. 在 IDE 中部署 APISIX Ingress controller 到远程 Kubernetes 集群
2. 使用 Nocalhost 开发和调试 Kubernetes 集群上的 APISIX ingress controller

环境准备

• 准备一个可用的 Kubernetes 集群。 可以使用任意拥有命名空间管理权限的 Kubernetes 集群
• 确保本地已安装好 Helm v3.0+
• 集群中已安装好 APISIX (APISIX Ingress controller 的依赖)
• GoLand IDE 2020.03+
• 安装 Nocalhost JetBrains 插件
• 安装 Go 1.13 及以上版本

部署 APISIX Ingress Controller

按照以下步骤，在 GoLand 中通过 Nocalhost 部署 APISIX Ingress Controller：

1. 在 GoLand 中打开 Nocalhost 插件
2. 选择将要部署 APISIX Ingress Controller 的命名空间
3. 右键点击选定的命名空间, 选择 Deploy Application, 然后选择 Helm Repo 作为安装方法
4. 在对话框中 Name 中输入：apisix-ingress-controller，在 Chart URL 中输入：https://charts.apiseven.com

部署完成后，我们通过在 IDE 内启用端口转发来测试 apisix-ingress-controller:

1. 在 Nocalhost 插件的 Workloads 中找到 apisix-ingress-controller ，右键点击并选择 Port Forward
2. 添加端口转发 8080:8080
3. 在本地访问 http://127.0.0.1:8080/healthz 并检查结果

开发 APISIX Ingress Controller

Step 1. 进入 DevMode

1. 右键点击 apisix-ingress-controller 工作负载， 选择 Start DevMode
2. 如果已经将源码克隆到本地，请选择源代码目录。 否则通过输入 apisix-ingress-controller 的源码仓库地址 https://github.com/apache/apisix-ingress-controller.git 来让 Nocalhost 克隆源代码到本地
3. 等待操作完成，Nocalhost 将在进入 DevMode 后在 IDE 内打开远程终端

打开远程终端后，通过在远程终端中输入以下命令来启动 apisix-ingress-controller 进程：

go run main.go ingress --config-path conf/config-default.yaml 

apisix-ingress-controller 启动后，通过 http://127.0.0.1:8080/healthz 访问服务， 并检查结果:

Step 2. 修改代码并检查结果

现在我们来修改一下代码并看看效果：

1. 停止 apisix-ingress-controller 进程
2. 在 Goland 中搜索 healthz 并找到 router.go 文件。 将 healthzResponse 的状态代码从 ok 更改为 Hello Nocalhost
3. 重新启动进程并在本地检查更改结果

可以看到我们无需重新构建镜像，几秒后便可以看到改动的结果：

Step 3. 结束开发模式

开发完毕后，我们可以通过以下步骤结束 DevMode：

1. 右键点击 apisix-ingress-controller
2. 选择并点击 End DevMode

Nocalhost 将会让 apisix-ingress-controller 结束 DevMode, 并重置 apisix-ingress-controller 到其原始版本。 启用端口转发来看看结束 DevMode 后的结果:

需要注意的是，DevMode 模式下，所有代码更改都只在 开发容器 中生效。退出 DevMode 后，Nocalhost 将会将远程容器重置为原始状态(进入 DevMode 之前的版本)。 通过这种方式，在退出 DevMode 以后，在 DevMode 模式下做的修改都不会影响原有环境。

调试 APISIX Ingress Controller

调试应用程序是一件麻烦的事，在 Kubernetes 集群中调试应用程序则更加麻烦。Nocalhost 可以帮助我们在调试 Kubernetes 集群中的程序时获得和在 IDE 中直接调试本地程序同样的体验。

Step 1. 开启远程调试

我们可以通过以下方式开始远程调试:

1. 右键点击 apisix-ingress-controller 并选择 Remote Debug
2. Nocalhost 将会先让 apisix-ingress-controller 进入 DevMode ， 并运行在 dev config 中定义的调试命令

Step 2. 设置断点

我们在 healthz 函数上设置一个断点， 设置好断点后，在浏览器中访问 http://127.0.0.1:8080/healthz ，会触发断点，GoLand 会跳到前台。 点击调试相关按钮可对程序进行调试：

远程运行 APISIX Ingress Controller

Nocalhost 不仅仅可以用来远程调试应用，通过使用 Remote Run 功能，还可以让为我们快速地在 Kubernetes 集群中运行开发中的应用程序。 我们可以通过以下步骤使用 Remote Run 功能：

1. 右键点击 apisix-ingress-controller ，并选择 Remote Run
2. Nocalhost 将会先让 apisix-ingress-controller 进入 DevMode， 并运行在 dev config 定义的运行命令 每次更改代码完代码后，Nocalhost 都会自动触发运行命令，将程序运行起来:

总结

通过以上步骤，我们已经学会如何使用 Nocalhost 来开发和调试 Kubernetes 集群中的 APISX ingress controller 。 使用 Nocalhost ，我们不再需要等待缓慢的本地开发循环反馈，而是通过一种高效的云原生开发方式来得到快速的反馈。

引用

• Apache APISIX getting started guide
• Developing for Apache APISIX Ingress Controller

一键开启云原生开发环境

截至 2021 年 9 月，百果园在国内外布局 200 多个特约供货基地，线下门店超 5000 家，进驻全国 90 多个城市。百果园 APP 下载量突破 1500 万，小程序注册人数超 4000 万，一体化会员数超 8000 万。经过整整 20 年的品牌经营，这个“一心一意做水果”的连锁龙头企业已在生鲜连锁零售行业构建了规模最大的线上线下一体化店仓网络系统，连续 6 年进入中国连锁百强企业。

数字化新零售业态下，非一体化研发管理体系瓶颈凸显

随着线上 /线下一体化战略的推进，百果园打造了专属的销售、金融、交易、供应链、营销服务、标准化种植以及数据分析平台，通过智能化与数字化实现人、货、场的结构调整和升级。业务需求激增、用户数量暴涨的同时，项目数量呈倍数逐年增长。这也使得多平台、多项目的标准化管理难度升级，非一体化研发管理体系瓶颈凸显。

难题一：研发工具及数据分散割裂，管理及维护成本高

在邂逅 CODING 之前，百果园使用不同的系统来分别管理项目事项、托管代码以及沉淀团队知识。非一体化的研发管理工具存在弊端，难以支撑百果园在创新型数字化零售业态下多渠道零售业务的增长需求。

• 由于管理工具分散，账号及权限管理体系不统一，工具管理存在难度；成员需要在不同的平台之间来回切换，研发效率低下。
• 各工具之间的数据割裂，难以实现代码与项目需求的关联。若要实现各工具之间的数据联通，还需要额外的研发成本。
• 多个工具单独维护，维护难度及成本高。

难题二：自研系统与项目管理平台对接存在阻碍，缺少本地技术支持

百果园自研的度量审计系统主要用于度量项目内迭代和具体任务的进展，便于管理者评估各事业线的发展情况。要实现这一目的，度量审计系统需要与项目管理平台对接，以获取所需的项目数据。

然而，由于百果园所使用的项目管理平台的 Open API 与自研系统匹配度不高，两者对接上存在困难，需要定制化开发。除此之外，百果园之前使用的项目管理平台由国外厂商提供，该厂商在国内的技术支持能力欠缺。如何针对实际的业务场景将工具对接快速落地，百果园需要有效的本地咨询服务与技术支持，否则只能自行摸索，耗时耗力。

“三步走”战略，CODING 助力百果园打造一体化研发管理体系

百果园希望将分散在各工具的已有数据迁移至一站式的研发管理工具，在企业内部打造统一的办公与协作平台，以满足数字化新零售业态下多项目、多系统的研发管理需求。经过多轮技术评估与交流沟通，百果园最终选择 CODING DevOps 作为统一的研发管理平台。百果园选择 CODING DevOps 的原因在于：

1. 灵活的项目事项及工作流配置：与业界主流的项目协同产品（如 Jira ）对标，提供丰富的事项类型、属性及状态配置，并支持定制适用于团队的工作流。这也使得百果园能在 CODING DevOps 平台沿用已有的项目协作方式，无需额外调整。
2. 强大的一站式研发管理能力：提供从需求到设计、开发、构建、测试、发布到部署的全流程协同及研发工具支撑，实现一站式研发流程管理。
3. 专业的技术支持：提供 7x24 小时在线技术咨询和专业的培训服务，由专门的研发团队实现定制化开发。针对百果园工具切换所需的无缝数据迁移服务以及迁移之后的自研系统对接问题，CODING 技术团队提供全面支持。

为了顺利协作百果园迈向一体化 DevOps 体系建设，CODING 采取了“三步走”策略，分阶段逐步实施了解决方案。

第一步：梳理业务流程，定制团队协作工作流

因为需要沿用已有的项目协作流程与模式，CODING 的技术支持团队首先梳理了百果园的需求流转过程。CODING DevOps 整合了百果园从需求评审、产品设计、开发、测试到发布验证全流程，确保各功能团队能围绕着产品需求开展更透明、更敏捷的协作活动。

在 CODING 的帮助下，百果园在 CODING DevOps 平台确定了「需求」在项目内流转的工作流。以产品需求为例，需求规划部门登记需求之后，会进入评审环节。需求评审通过之后，产品团队即可进行产品设计。若产品设计及 UI 设计方案通过评审，产品经理会针对相关项目人员进行产品宣讲。开发人员对需求明确无误之后，即可开始编写代码；而测试人员可在研发早期阶段准备测试用例，待开发完成编码之后进行测试，确保产品可稳定发布上线。

除了「需求」之外，百果园也配置了适用于自身业务实际情况的「任务」、「缺陷」及其他自定义事项的工作流，以追踪团队内所有研发活动的流转状态，随时掌握项目动态。

第二步：存量数据迁移，实现工具切换

在确定使用 CODING DevOps 进行团队协作之后，百果园需要解决的首要难题是数据迁移。如何将分散在多个平台的已有数据无损迁移至统一平台进行管理？ CODING 给出了满意答案。

在实施数据迁移之前，CODING 面临百果园 100+ 项目，1600+ 代码仓库，以及 20,000+ Wiki 页面。为保证平滑、无损且业务无感知的数据迁移，CODING 采取了“先调研、后适配；先试点、后批量；先整体、后增量”的方式，分阶段逐步实现了数据从分散的项目管理平台、代码仓库、知识管理平台全量迁移至 CODING DevOps 一站式平台。

数据迁移的成功，离不开 CODING 技术团队的专业服务与百果园在数据迁移前期的积极配合：

• 充分调研：CODING 侧与百果园就技术现状及项目需求进行了多次沟通与评估，并最终确定适用于百果园的数据迁移方案，包括系统对接、产品培训、数据迁移及验收等多个阶段。
• 合理规划：针对数据迁移前、中、后全流程的多个阶段，CODING 及百果园合理拆分事项并制定了详尽的工作计划，由双方在约定的时间点协作完成。在首次迁移工作执行之前，CODING 的技术团队拆解了近百个事项，确保迁移方案能准确无误地实施。
• 专业支持：由 CODING 侧在数据迁移前对百果园进行 4 场技术培训（覆盖 400+ 人员），确保百果园的人员能快速上手 CODING DevOps 一站式平台，在数据迁移之后顺利开展团队协作。

第三步：助力自研系统对接，全面支撑客户成功

在完成数据迁移之后，针对百果园自研的度量审计系统需获取多维度项目数据的需求，CODING 技术团队提供了专业的支持，顺利协助百果园完成自研系统与 CODING DevOps 平台的对接。

百果园自研的度量审计工具以项目看板的形式展示项目内的迭代信息，包括迭代的预计完成时间、进度及迭代中所有任务的详情等。这些度量数据均可以通过 CODING 的 Open API 顺利获取。CODING 提供丰富的数据接口，支持查询不同类型的项目信息，比如事项详情、迭代详情、事项属性设置等等，给百果园自研的度量审计工具提供了多样化的源数据。

CODING Open API 的开放能力与成熟度，加上技术支持团队的专业水平，全面支撑客户成功。

工具多合一，百果园开启 DevOps 之旅

实现数据迁移之后，百果园摆脱了多工具管理的烦恼。通过一站式 CODING DevOps 平台，百果园轻松打造标准化的研发管理流程，提高研发效能，降低工具维护成本。

一站式研发工具链，团队协作提速增效

百果园的成员仅凭一个 CODING 账号即可登录一站式平台进行团队项目协作，无需频繁切换至不同平台。统一的工作入口和账号体系不仅帮助百果园提高研发效率，还降低了其研发工具的使用与维护与成本。

在需求阶段，项目经理在「项目协同」中查看具体产品需求，并根据需求分解具体的开发任务、测试任务和发布验证任务。

产品经理在完成需求分析和产品设计之后，可在「文档管理」中使用 Wiki 撰写产品文档。

在开发阶段，开发人员在「代码仓库」中编写代码，并在提交代码时与具体的项目需求绑定。

在测试阶段，测试人员可在「测试管理」中编写测试用例，创建对应的测试计划，最终进行测试结果记录，一键生成测试报告。

在产品发布上线之后，所有的项目成员均可通过 Wiki 归档过程文档，沉淀团队内的经验，促进知识共享与传递，打造持续改进与反馈的团队文化。

需求代码互联互通，团队协作透明化

在使用 CODING DevOps 之前，百果园面临着需求无法关联代码的问题。需求与代码的信息割裂，管理者难以实时掌握需求的开发情况，无法及时识别潜在的进度风险。而 CODING DevOps 平台强大的资源关联能力解决了这一难题。各功能模块间数据互通，项目成员可按需将项目事项与对应的代码版本、测试用例、Wiki 文档等关联起来；反之，任何代码改动亦可与项目事项紧密关联。一切项目需求均可追踪，对应的研发过程清晰可回溯，给项目成员带来了极大的便利。

零成本功能扩展，测试用例实现线上管理

区别于 Atlassian 的开发者生态，CODING 提供全量开放的一站式能力。无需通过付费的插件或额外的定制功能，百果园即可享受 CODING DevOps 一站式平台的全部能力。比如，百果园最初的需求是将项目、代码与文档集中在同一平台管理，但在了解了 CODING DevOps 的「测试管理」功能之后，百果园决定将测试用例也统一迁移至线上进行管理。

在使用 CODING DevOps 之前，百果园的测试人员需要用 Excel 来管理测试用例。随着测试用例数量日渐增多，重复的人工操作易出错、耗时间。除此之外，线下管理的方式难以实现测试用例的灵活分组，无法以可视化的方式统计用例数量，且不便于频繁更新用例或沉淀基线用例，容易造成用例丢失或分组混乱的情况。

在使用 CODING DevOps 之后，百果园摆脱了手动管理测试用例的困境。通过填写简单的 Excel 或 Xmind 模板，测试用例即可批量一键导入至网页。同一版本发布所需的测试用例纳入同一分组，然后根据产品功能再进行划分。如百果园的测试团队负责人所说，通过线上的方式管理测试用例，用例的分组逻辑、数量均清晰可见，便于评估测试工作量和范围。而不断迭代的基线测试用例，也可轻松在线上更新维护。除此之外，版本发布之后，测试团队还可以将该次版本中发现的测试问题或有价值的信息沉淀在 CODING DevOps 的 Wiki 文档，便于团队成员之间经验共享，持续提高工作质量。

除了「测试管理」之外，百果园也开始小规模使用 CODING DevOps 平台的「持续集成」与「制品库」能力，并将持续深入探索，实现全量的一站式能力落地，真正打造属于百果园的一体化研发体系。

便捷移动办公，「 Coding Anytime Anywhere 」

以往，由于部分服务部署在内网节点，百果园的开发人员依赖内网环境进行办公，移动办公时需要额外配置。而 CODING DevOps 支持企业微信小程序、微信小程序、H5 页面等多种终端，百果园成员无需额外配置 VPN ，打开浏览器即可登录自己的工作台，随时随地移动办公，或通过微信小程序查看事项进展与消息通知，随时掌握项目动态。

在未来的规划中，百果园的开发团队会逐步将开发环境全量迁移至 CODING 的公有云，真正实现云上的「 Coding Anytime Anywhere 」。

齐力探索 DevOps 最佳实践，持续共建行业新生态

在 CODING 与百果园对接的过程中，百果园的 PMO 与质量部从整个公司层面出发，以宏观的角度对项目价值（如能效或质量提升）进行分析与评估，与 CODING 一起对产品的功能与使用流程进行全方位的探讨，并最终选择了与 CODING 进行合作。

使用 CODING 一站式平台对于百果园而言，并不是简单的工具切换，而是携手 CODING 在 DevOps 实践中迈出重要的第一步。在未来，CODING 将与百果园进行长期合作，在 DevOps 实践中持续摸索与探讨，共建 DevOps 在零售行业的数字化新生态。

以下文章来源于悬镜安全 ，作者悬镜安全

近日，一站式 DevOps 软件研发管理协作平台 CODING 与 DevSecOps 敏捷安全领导者悬镜安全达成战略合作，签约仪式在深圳腾讯云 CODING 总部举行，腾讯云 CODING CEO 张海龙和悬镜安全 CEO 子芽代表双方企业签署了战略合作协议。依托于在敏捷安全方向丰富的落地经验，并基于 CODING 完备的 DevOps 体系，将悬镜安全敏捷安全工具链全面融入，打造整体的 DevSecOps 创新模式。CODING 与悬镜安全旗下灵脉 IAST 、源鉴 OSS 、云鲨 RASP 、灵脉 PTE 、夫子 ATM 全面集成，为 DevOps 转型的用户提供丰富的敏捷安全储备，为 DevOps 各个阶段的安全保驾护航。

深圳市腾云扣钉科技有限公司（ CODING ）成立于 2014 年 2 月，系腾讯旗下全资子公司。旗下一站式软件研发管理平台 —— CODING （ coding.net ）上线稳定运行 7 年，目前已累积超过 200 万开发者用户，5 万家企业团队，服务涵盖互联网、金融、政企等不同行业客户。CODING 一站式软件研发管理平台提供代码管理、项目协同、测试管理、持续集成、制品库、持续部署、团队知识库等系列工具产品。从需求提交到产品迭代，从代码开发到软件测试、部署，整套流程均在 CODING 完成。基于完整的工具链，CODING 为各行各业客户提供成熟的研发管理数字化转型、研发管理规范、敏捷开发及 DevOps 等解决方案，帮助企业降低研发工具建设成本，提高产品交付效率，实现研发效能升级。

悬镜安全作为国内 DevSecOps 敏捷安全领域的领导者，多年来专注于领域内技术研究探索和相关体系落地实践，其首创的“DevSecOps 智适应威胁管理体系”为用户提供贯穿开发运营全生命周期的安全解决方案，用前沿 AI 技术赋能行业用户高效践行 DevSecOps 。目前，该体系已在金融、能源、泛互联网、IoT 、云服务及汽车制造等多个行业落地，是具有行业应用价值的新一代敏捷安全体系。

此次，CODING 与悬镜安全战略签约，未来双方将在软件供应链安全、DevSecOps 敏捷安全、DevOps 、开源威胁治理等前沿自主创新技术领域展开全面合作，从联合技术研究、解决方案设计、产品服务体系建设以及全国性市场开拓等多维度进行深度绑定，并充分利用各自优势的技术实施能力和深耕领域共同赋能行业用户，携手助推供应链安全产业生态创新发展。

悬镜安全 CEO 子芽则表示：“希望双方建立密切、长久的战略合作伙伴关系，不光是停留在产品层面的打通，更期待 CODING 和悬镜安全能够充分发挥各自业务特点及优势，在业务合作、市场营销、产业推动等多个领域开展强强合作，实现资源共享、优势互补，共同促进双方产品与服务的延伸和发展。”

腾讯云 CODING CEO 张海龙对此次战略合作表示：“多年来，CODING 持续深耕研发者领域，为来自不同行业的 5 万家企业客户提供成熟的 DevOps 服务，深知安全在企业研发流程中的重要性。依托腾讯云强大的安全产品能力，CODING 已经推出 DevSecOps 解决方案，提供安全开发管控平台和全流程安全工具，将安全嵌入到 DevOps 的各个流程中去。而悬镜安全作为国内 DevSecOps 领域的先行者，与 CODING 的安全理念不谋而合。此次 CODING 和悬镜安全强强联手，将进一步构筑和打磨快速落地的成熟 DevSecOps 解决方案，为行业客户数字化转型之路保驾护航。”

立即开启高效云端研发工作流

导语

12 月 9 日晚间，Apache Log4j 2 发现了远程代码执行漏洞，恶意使用者可以通过该漏洞在目标服务器上执行任意代码，危害极大。

腾讯安全第一时间将该漏洞收录至腾讯安全漏洞特征库中，CODING 制品扫描基于该漏洞特征库，对引用了受影响版本的 Log4j 2 制品进行了精准定位，并给出修复建议，同时可禁止下载含有该安全漏洞的制品，最大限度的减少漏洞蔓延。

Apache Log4j 2 漏洞详情

Apache Log4j 2 是一个基于 Java 的日志记录工具。该工具重写了 Log4j 框架，并且引入了丰富的特性，作为日志记录基础第三方库，被大量 Java 框架及应用使用。

此次漏洞是由于 Log4j 2 提供的 lookup 功能造成的，该功能允许开发者通过一些协议去读取相应环境中的配置。但在实现的过程中，并未对输入进行严格的判断，从而造成漏洞的发生，当程序将用户输入的数据进行日志记录时，即可触发此漏洞。

漏洞详情：

Log4j 2 的使用极为广泛，可能受影响的应用及组件（包括但不限于）：Apache Solr 、Apache Flink 、Apache Druid 、Apache Struts2 、Srping-boot-strater-log4j2 、ElasticSearch 、Flume 、Dubbo 、Redis 、Logstash 、Kafka 。

使用 CODING 制品扫描，快速识别受影响制品

CODING 制品扫描已经识别到该漏洞，可以在制品管理 - 制品扫描模块创建「安全漏洞扫描方案」，对相关 Maven 包进行安全扫描。在 CODING DevOps 线上版本中可直接对该漏洞进行排查，私有化的 CODING DevOps 及 WePack 客户请联系客户经理咨询升级。

扫描结束后，可以看到最新的中文漏洞信息。该漏洞的危险等级被腾讯安全定义为「危急」，同时该漏洞使用广泛，利用门槛低，被标记为「优先关注漏洞」，在漏洞详情中，我们建议用户尽快修复至「 2.15.0-rc2 」版本，将此依赖升级后，即可规避漏洞影响。

同时，可通过“禁止下载未通过质量红线的制品”的管控方式，以避免日后产品更新引入该风险。

如何修复漏洞

升级 ApacheLog4j 所有相关应用到最新的 Log4j-2.15.0-rc2 版本。

（ 2.15.0-rc1 版，经腾讯安全专家验证可以被绕过）

补丁下载地址： https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc2

漏洞缓解措施：

1. jvm 参数 - Dlog4j2.formatMsgNoLookups=true

2. log4j2.formatMsgNoLookups=True

获取补丁后重新打包，可将依赖 jar 包上传至 CODING 制品仓库，并修改制品依赖配置，推送新版本。

重新扫描后，可以看到制品已通过扫描。

强强联手，共同保卫客户软件安全

CODING 与腾讯安全及其科恩实验室、云鼎实验室携手，共同保卫客户软件安全。

可信漏洞特征库

「腾讯安全开源组件漏洞特征库」是腾讯基于自身安全研究与国内外通用开源漏洞库信息搭建的漏洞特征库，由专业安全团队持续运营，为用户提供准确、及时、易懂的安全信息。

完善的流程管控

在软件生产过程中，进入 CODING 制品库的制品会受到 CODING 制品扫描能力的监管。CODING 会对制品进行依赖分析，解析出制品引用的开源组件，再通过「腾讯安全开源组件漏洞特征库」识别出制品引用的开源组件存在的漏洞，输出漏洞报告，通过预设的质量红线判断制品扫描通过情况，展示在制品详情中。

同时，腾讯安全专家根据漏洞静态威胁等级（ CVSS ）和动态风险等级（漏洞当前是否有公开利用 POC ）筛选出需优先关注的漏洞，在扫描结果中进行优先度提示，协助客户优先处理危急问题。

持续的风险制品管理

制品扫描方案可以设置禁止下载没有通过安全扫描的制品，以此避免存在安全隐患的制品被团队成员继续引用或发布，实现对漏洞风险的持续管控。

在漏洞、数据安全问题频发的当下，为了给客户提供更可靠的服务体验，CODING 在投入软件开发过程提效的同时，也持续关注软件开发过程安全和软件资产安全，致力于为企业用户提供更高效、更可靠、更安全的云上研发工作流。

在未来，CODING 也将持续关注软件的安全生产，保持与腾讯安全团队的紧密合作，在制品管理环节提供更精确的依赖分析能力、License 扫描能力，协助客户全面建设 DevSecOps 能力，将安全管控左移，降低软件生产风险。

联系 CODING 顾问，获得 DevSecOps 解决方案

本文为 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 与企业的研发管理诉求相结合，中转研发 - 构建 - 质检 - 发布信息流。同时我们也会提升上下游工具和部署平台兼容能力，满足企业的多样化工具链与多种部署需求。

点击即可观看 CIF 峰会回放

本文作者：成龙 腾讯前端开发工程师，负责腾讯文档前端开发与研发效能提升，AlloyTeam 成员。

导语

本篇文章将着重探讨 DevOps 在持续集成阶段需要提供的能力，将对工作流的设计及流水线的优化思路做一个简要讲解。

DevOps 一词源于 Development 和 Operations 的组合，即将软件交付过程中开发与测试运维的环节通过工具链打通，并通过自动化的测试与监控，减少团队的时间损耗，更加高效稳定地交付制品。

随着腾讯文档的项目规模越来越大，功能特性与维护人员越来越多，特性交付频率与软件质量之间的矛盾日渐尖锐，如何平衡两者成为了目前团队亟需关注的一个重点，于是，落地一个完善的 DevOps 工具链便被提上日程。

当我们在谈论 CI 时，我们在谈论什么

CI （ Continuous Integration ），即持续集成，指频繁地（一天多次）将代码集成到主干的行为。

注意，这里既包含持续将代码集成到主干的含义，也包含持续将源码生成可供实际使用的制品的过程。因此，我们需要通过 CI ，自动化地保证代码的质量，并对其构建产物转换生成可用制品供下一阶段调用。

因此，在 CI 阶段，我们至少有如下阶段需要实现：

1. 静态代码检查

这其中包括，ESLINT/TSLINT 静态语法检查，验证 git commit message 是否符合规范，提交文件是否有对应 owner 可以 review 等等。这些静态检查不需要编译过程，直接扫描源代码就可以完成。

2. 单元测试 /集成测试 /E2E 测试

自动化测试这一环节是保障制品质量的关键。测试用例的覆盖率及用例质量直接决定了构建产物的质量，因此，全面且完善的测试用例也是实现持续交付的必备要素。

3. 编译并整理产物

在中小型项目中，这一步通常会被直接省略，直接将构建产物交由部署环节实现。但对于大型项目来说，多次频繁的提交构建会产生数量庞大的构建产物，需要得到妥善的管理。产物到制品的建立我们接下来会有详细讲解。

利于集成的工作流设计

在正式接入 CI 前，我们需要规划好一种新的工作流，以适应项目切换为高频集成后可能带来的问题与难点。这里涉及到的改造层面非常多，除了敦促开发人员习惯的转变以及进行新流程的培训外，我们主要关心的是源码仓库的更新触发持续集成步骤的方式。

1. 流水线的组织形式

我们需要一个合适的组织形式来管理一条 CI 流水线该在什么阶段执行什么任务。

市面上有非常多的 CI 工具可以进行选择，仔细观察就会发现，无论是 Drone 这样的新兴轻量的工具，亦或是老牌的 Jenkins 等，都原生或通过插件方式支持了这样一个特性：Configuration as Code ，即使用配置文件管理流水线。

这样做的好处是相当大的。首先，它不再需要一个 web 页面专门用于流水线管理，这对于平台方来说无疑减少了维护成本。其次对于使用方来说，将流水线配置集成在源码仓库中，享受与源码同步升级的方式，使得 CI 流程也能使用 git 的版本管理进行规范与审计溯源。

确立了流水线的组织形式后，我们还需要考虑版本的发布模式以及源码仓库的分支策略，这直接决定了我们该以什么样的方式规划流水线进行代码集成。

2. 版本发布模式的取舍

在《持续交付 2.0 》一书中提到，版本发布模式有三要素：交付时间、特性数量以及交付质量。

这三者是相互制衡的。在开发人力与资源相对固定的情况下，我们只能对其中的两个要素进行保证。

传统的项目制发布模式是牺牲了交付时间，等待所有特性全部开发完成并经历完整人工测试后才发布一次新版本。但这样会使得交付周期变长，并且由于特性数量较多，在开发过程中的不可控风险变高，可能会导致版本无法按时交付。不符合一个成熟的大型项目对于持续交付的要求。

对于持续集成的思想来说，当我们的集成频率足够高，自动化测试足够成熟且稳定时，完全可以不用一股脑地将特性全堆在一次发布中。每开发完成一个特性就自动进行测试，完成后合入等待发布。接下来只需要在特定的时间周期节点自动将已经稳定的等待中的特性发布出去即可。这对于发布频率越来越高，发布周期越来越短的现代大型项目中无疑是一个最优解。

3. 分支策略

与大部分团队一样，我们原有的开发模式也是分支开发，主干发布的思想，分支策略采用业界最成熟也是最完善的 Git-Flow 模式。

可以看出，该模式在特性开发，bug 修复，版本发布，甚至是 hotfix 方面都已经考虑到位了，是一个能应用在生产环境中的工作流。但整体的结构也因此变得极为复杂，不便管理。例如进行一次 hotfix 的操作流程是：从最新发布前使用的主干分支拉出 hotfix 分支，修复后合入到 develop 分支中，等待下一次版本发布时拉出到 release 分支中，发布完成后才能合回主干。

此外，对于 Git-Flow 的每一个特性分支来说，并没有一个严格的合入时间，因此对于较大需求来说可能合入时间间隔会很长，这样在合入主干时可能会有大量的冲突需要解决，导致项目工期无端延长。对此，做大型改造与重构的同学应该深有体会。

针对这一点，我们决定大胆采用主干开发，主干发布的分支策略。

我们要求，开发团队的成员尽量每天都将自己分支的代码提交到主干。在到达发布条件时，从主干直接拉出发布分支用于发布。若发现缺陷，直接在主干上修复，并根据需要 cherry pick 到对应版本的发布分支。

这样一来，对于开发人员来说需要关注的分支就只有主干和自己 working 的分支两条，只需要 push 与 merge 两条 git 命令就能完成所有分支操作。同时，由于合入频率的提高，平均每人需要解决的冲突量大大减少，这无疑解决了很多开发人员的痛点。

需要说明的是，分支策略与版本发布模式没有银弹。我们采用的策略可能并不适合所有团队的项目。提高合入频率尽快能让产品快速迭代，但无疑会让新开发的特性很难得到充分的手工测试及验证。

为了解决这一矛盾点，这背后需要有强大的基础设施及长期的习惯培养做支持。这里将难点分为如下几个类型，大家可以针对这些难点做一些考量，来确定是否有必要采用主干开发的方式。

1 ）完善且快速的自动化测试。只有在单元测试、集成测试、E2E 测试覆盖率极高，且通过变异测试得出的测试用例质量较高的情况下，才能对项目质量有一个整体的保证。但这需要团队内所有开发人员习惯 TDD （测试驱动开发）的开发方式，这是一个相当漫长的工程文化培养过程。

2 ） Owner 责任制的 Code Review 机制。让开发人员具有 Owner 意识，对自己负责的模块进行逐行审查，可以在代码修改时规避许多设计架构上的破坏性修改与坑点。本质上难点其实还是开发人员的习惯培养。

3 ）大量的基础设施投入。高频的自动化测试其实是一个相当消耗资源的操作，尤其是 E2E 测试，每一个测试用例都需要启动一个无头浏览器来支撑。另外，为了提升测试的效率，需要多核的机器来并行执行。这里的每一项都是较大的资源投入。

4 ）快速稳定的回滚能力和精准的线上及灰度监控等等。只有在高度自动化的全链路监控下，才能保证该机制下发布的新版本能够稳定运行。这里的建设我会在之后的文章里详细介绍。

大型项目中产物->制品的建立

对于大多数项目来说，在代码编译完成生成产物后，部署项目的方式就是登录发布服务器，将每一次生成的产物粘贴进发布服务器中。生成的静态文件由于 hash 不同可以同时存放，html 采用直接覆盖的方式进行更新。

直接使用复制粘贴的方式来操作文件的更新与覆盖，这样既不方便对更新历史的审计与追溯，同时这样的更改也很难保证正确性。

除此之外，当我们需要回滚版本时，由于服务器上并没有存放历史版本的 html ，因此回滚的方式其实是重新编译打包生成历史版本的产物进行覆盖。这样的回滚速度显然不是令人满意的。

一个解决方法是，不要对文件进行任何的覆盖更新，所有的产物都应该被上传持久化存储。我们可以在请求上游增设一个流量分发服务，来判断每一条请求应该返回哪一个版本的 html 文件。

对于大型项目来说，返回的 html 文件也不一定不是一成不变的。它可能会被注入渠道、用户自定义等标识，以及 SSR 所需要的首屏数据，从而改变其代码形式。因此，我们认为 html 文件的制品提供方应该是一个单独的动态服务，通过一些逻辑完成对模板 html 的替换并最终输出。

总结一下，在每次编译完成后，产物将会进行如下的整理以生成最终的前端制品：

1. 针对静态文件，如 CSS 、JS 等资源将会发布到云对象存储中，并以此为源站同步给 CDN 做访问速度优化。

2. 针对 HTML 制品，需要一个直出服务做支撑，并打包成 docker 镜像，与后端的微服务镜像同等级别，供上游的流量分发服务（网关）根据用户请求选择调起哪些服务负载进行消费。

速度即效率，流水线优化思路

对于一个好的工具来说，内部设计可以很复杂，但对于使用者来说必须足够简单且好用。

在主干开发这样高频的持续集成下，集成速度即效率，流水线的执行时间毫无疑问是开发人员最关心的，也是流水线是否好用的决定性指标。我们可以从几个方面着手，提高流水线执行效率，减少开发人员的等待时间。

1. 流水线任务编排

对流水线各个阶段需要执行的任务我们需要遵循一定的编排原则：无前置的任务优先，执行时间短的任务优先，无关联的任务并行。

根据这一原则，我们可以通过分析流水线中执行的各个任务，对每一个任务做一次最短路径依赖分析，最终得出该任务的最早执行时机。

2. 巧用 Docker Cache

Docker 提供了这样一个特性：在 Docker 镜像的构建过程中，Dockerfile 的每一条可执行语句都会构建出一个新的镜像层，并缓存起来。在第二次构建时，Docker 会以镜像层为单位逐条检查自身的缓存，若命中相同镜像层，则直接复用该条缓存，使得多次重复构建的时间大大缩短。

我们可以利用 Docker 的这一特性，在流水线中减少通常会重复执行的步骤，从而提高 CI 的执行效率。

例如前端项目中通常最耗时的依赖安装 npm install ，变更依赖项对于高频集成来说其实是一个较小概率的事件，因此我们可以在第一次构建时，将 node_modules 这个文件夹打包成为镜像供下次编译时调用。Dockerfile 示例编写如下：

FROM node:12 AS dependenciesWORKDIR /ciCOPY . .RUN npm installENV NODE_PATH=/ci/node_modules 

我们给流水线增加一条检查缓存命中的策略：在下次编译之前，先查找是否有该镜像缓存存在。并且，为了保证本次构建的依赖没有更新，我们还必须比对本次构建与镜像缓存中的 package-lock.json 文件的 md5 码是否一致。若不一致，则重新安装依赖并打包新镜像进行缓存。若比对结果一致，则从该镜像中直接取到 node_modules 文件夹，从而省去大量依赖安装的时间。

流水线拉取镜像文件夹的方法示例如下，其中 --from 后跟的是之前缓存构建镜像的别名：

COPY --from=dependencies node_modules/ .# 其他步骤执行 

同理，我们也可以将这一特性扩展到 CI 过程中所有更新频率不高，生成时间较长的任务中。例如 Linux 中环境依赖的安装、单元测试每条用例运行前的缓存、甚至是静态文件数量极多的文件夹的复制等等，都能利用 Docker cache 的特性达到几乎跳过步骤，减少集成时间的效果。由于原理大致相同，在此就不赘述了。

3. 分级构建

众所周知，流水线的执行时间一定会随着任务数量的增多而变慢。大型项目中，随着各项指标计算的接入，各项测试用例的数量逐渐增多，运行时间迟早会达到我们难以忍受的地步。

但是，测试用例的数量一定程度上决定着我们项目的质量，质量检查决不能少。那么有没有一种方法既可以让项目质量得到持续保障的同时，减少开发者等待集成的时间呢？答案就是分级构建。

所谓分级构建，就是将 CI 流水线拆分为主构建和次级构建两类，其中主构建需要在每次提交代码时都要执行，并且若检查不通过无法进行下一步操作。而次级构建不会阻塞工作流，通过旁路的方式在代码合入后继续执行。但是，一旦次级构建验证失败，流水线将会立即发出通知告警，并阻塞其他所有代码的合入，直到该问题被修复为止。

对于某任务是否应放入次级构建过程，有如下几点原则：

1 ）次级构建将包含执行时间长（如超过 15 分钟）、耗费资源多的任务，如自动化测试中的 E2E 测试。

2 ）次级构建应当包含用例优先级低或者出错可能性低的任务，尽量不要包含重要链路。如果自动化测试中的一些测试用例经过实践发现失败次数较高，应当考虑增加相关功能单元测试，并移入主构建过程。

3 ）若次级构建仍然过长，可以考虑用合适的方法分割测试用例，并行测试。

总结

我们认为，从代码集成、功能测试，到部署发布、基础设施架构管理，每一个环节都应该有全面且完善的自动化监控手段，并尽量避免人工介入。只有这样，软件才能同时兼顾质量与效率，在提高发布频率的情况下保证可靠性。这是每一个成功的大型项目最终一定要实现的目标。

参考资料

1. 《持续交付 2.0 》—— 乔梁 著

2. https://www.redhat.com/zh/topics/devops/what-is-ci-cd

3. https://www.36kr.com/p/1218375440667012

立即开启高效云端研发工作流

本文作者：王振威 - CODING 研发总监 CODING 创始团队成员之一，多年系统软件开发经验，擅长 Linux ，Golang ，Java ，Ruby ，Docker 等技术领域。近两年来一直在 CODING 从事系统架构和运维工作。

不同类型的企业资产有不同的管理办法，但守护资产的安全性无一例外都是重中之重，但对如何保障代码资产安全并没有形成统一认知。本文将就“代码资产的安全性”这一话题展开全面的阐述，尝试从代码管理的生命周期进行全链路分析，读者可以据此来审视自己企业的代码资产安全。

代码资产安全是什么

代码资产安全不等于信息安全

代码资产安全不等于信息安全，这是很容易理解的。整个企业的信息系统组成不仅仅是代码资产，甚至可以说大多数情况下不涉及代码资产。企业的信息系统往往由基础计算设施、网络平台、软件、数据库等方面组成。信息安全重点是关注上述信息设施在投产之后运行过程中的安全问题。而大多数软件运行的程序包是经由源代码编译的结果，跟源代码本身是分割开来的。信息安全关注的方面更为全面，代码资产安全只是其中的一部分，而且往往不是最为关注的一部分。

代码资产安全不等于代码安全

代码资产安全不等于代码安全，这不太容易理解。代码安全往往指代代码本身的安全性，如代码中是否有远程过程执行漏洞，注入漏洞等等。而代码资产安全是一个管理概念，强调管理过程的安全，而非代码本身安全，例如某研究机构需要研究某种计算机病毒，他们需要在源码库中存放对应病毒的源码。这病毒的源码就是这个机构的重要资产。

代码管理系统不审视源码中的漏洞或者恶意行为，而是必须忠实地确保存储的代码的原始文件。

代码资产管理是围绕代码仓库的全生命周期管理

代码资产管理的核心是代码仓库。仓库里存放着企业的全部代码，配置文件以及全部历史版本。守护代码资产安全的核心就是围绕代码仓库的三个关键环节构建起全链路的安全能力，这三个环节分别是检入，存储和检出。

检入安全

检入可以理解为开发者在开发环境上编辑好代码，并且把代码传送到代码仓库的过程。这个环节关注两个方面，分别是机密性和完整性。

机密性

机密性是指开发者把开发环境中的代码检入代码仓库的过程不被第三方窃取，一般通过传输过程加密来实现。Git 代码仓库最常用的是 HTTPS 和 SSH 传输协议。

HTTPS 协议是通过 HTTP 协议加上传输层安全协议（ TLS ）实现的。HTTP 协议是明文传输协议，这意味着如果没有 TLS ，网络节点中的路由设备都可以轻松窃取代码。TLS 可以在 TCP 协议之上建立双向加密能力，配合 HTTP 协议上就是 HTTPS 。HTTPS 客户端和服务端先通过非对称加密协商加密算法和密钥，再使用协商的算法和密钥来进行对称加密传输。本文不涉及具体算法的安全性介绍，不过随着密码学的发展，算法在与时俱进，我们可以认为加密算法本身是安全的。

然而这一过程并不完备，攻击者可以制作中间服务器，使得客户端在发起连接的时候误连接了中间服务器，从而跟这个中间服务器进行加密通信。这将导致即便是加密传输，但最终还是会被恶意服务器窃取，这就形成了中间人攻击。

行业推出了 CA （证书授权机构）机制应对此问题，即服务器在提供加密传输服务前，要把自己的公钥和服务的域名绑定，并且在全球公信的 CA 处登记。这样一来，HTTPS 客户端在尝试建立加密链接的时候，会要求服务器出示 CA 签发的证书，客户端可以使用预安装在操作系统或者浏览器内的 CA 公钥进行验证，确认服务器对域名的所有权，这样一来就可以确保不会有中间人攻击。有行业公信力 CA ，也有企业内部 CA ，而后者需要在客户端安装企业内部 CA 的证书文件。

知名安全机构 Qualys 可以在线对 HTTPS 服务器进行 SSL/TLS 多方面的报告评估，如下图为两家国内云计算公司推出的代码托管服务器的评估：

HTTPS 虽然解决了传输安全，但在认证用户身份这里，Git 代码仓库还是依赖 Basic Auth 机制来实现。Git 代码仓库会要求 HTTPS 客户端提供账号密码，并附在请求体中一并传输给服务器，由服务器来确认操作者身份。在传输过程中，账号和密码是被 TLS 一并加密传输的，我们不必担心传输过程的密码泄露问题。但开发者通常为了不必每次操作都输入账号密码，会让电脑记住密码，如果不妥善处理，可能会导致泄露。这里重点是一定不能把账号密码拼接在远程仓库访问地址里面，正确的做法是使用 Git 在各种操作系统下的 凭据管理器，如 macOS 是使用钥匙串管理，Windows 是使用 Git Credential Manager for Windows 来进行管理。

SSH 是一种常用于远程管理 Linux/Unix 服务器的安全加密协议，其功能非常多样。以 Git 为基础的代码托管也常使用这个协议进行加密代码传输。使用者提前把自己的公钥文件配置在服务器上后，可以在后续的传输过程中确认身份。

SSH 使用非对称加密（用户的公钥）确认身份，用对称加密传输数据。跟 HTTPS 不同的是，SSH 协议无法指定域名，所以无法引入 CA 机制来防止中间人攻击。

但 SSH 客户端在与未知服务器进行连接时，会提示服务器的公钥指纹信息，使用者应当对比服务供应商官方提供的公钥公告和命令行提示信息来确认服务器身份，确保不被中间人攻击。

如图展示腾讯云 CODING SSH 服务器的公钥指纹公示：

如图所示，SSH 客户端尝试连接服务器时给出的服务器公钥指纹确认：

在用户确认身份（输入 yes 并按下回车）后，SSH 客户端会把服务器的公钥信息记录在 ~/.ssh/known_hosts 中，下次即可直接连接，不再询问。

要点小结

• 代码的传输要使用双向加密协议，HTTPS 和 SSH 都可以
• HTTPS 协议需要关注服务器的证书签发方（ CA ）的权威性
• HTTPS 协议需要关注客户端是否安装了不受信任的 CA 文件（防止 CA 欺诈）
• 使用 Git 凭据管理器保管 Git HTTPS 协议的账号密码
• SSH 协议在使用的时候需要仔细比对服务器提供的公钥指纹跟服务提供商公告的公钥指纹是否完全一致，防止中间人攻击
• 客户端需要注意防止攻击者恶意篡改 ~/.ssh/known_hosts 文件内容或者 SSH 的客户端配置（可以通过忽略服务器公钥信任机制）
• 妥善保管 SSH 私钥文件（往往存放于 ~/.ssh/id_rsa ），如 Linux 下确保此文件的权限是 400 等，防止他们读取

完整性

代码检入的完整性包含两个方面：

1. 开发者一次提交的代码变动是否完整（内容不被篡改）
2. 某次提交是否确为某开发者做出的变动（不被冒名顶替）

以 Git 为例子，这个代码版本控制软件已经从内生机制上确保了内容不被篡改。Git 采用一种类 Merkel 哈希树的机制来实现分层校验。

哈希是一种把任意数据映射成等长数据的算法，且不可逆。哈希算法有的特点是原始数据发生一点变化，映射的结果会产生较大变化，而且这一变化毫无规律。映射后的等长的数据被称为指纹。

哈希算法非常适合用来快速比较两段数据是否完全一致（指纹一致几乎可以推断原文一致）。在我们上文中提到的对比 SSH 服务器出示的公钥指纹，和服务提供商公告的指纹就是这种原理的应用。

Merkel 哈希树：

Git 对仓库中的每一个文件内容和其基本信息整合进行哈希。会将一个目录树下的所有文件路径和文件哈希值组合再哈希形成目录树的哈希。会把目录树和提交信息组合再哈希，此哈希结果就是 Git 的版本号。这意味着每次提交都产生一个完全不同的版本号，版本号即哈希。在给定一个版本号，我们可以认为这个版本背后对应的全部文件内容，历史记录，提交信息，目录结构都是完全一致的。对于确定的版本号就没有篡改的可能性。

哈希算法小概率会产生冲突（同一个指纹对应多个不同原始数据的情况），这时可能导致一致性校验失效。所以哈希算法也在与时俱进，如当下 MD5 算法已经几乎过时，Git 当前正在使用 SHA1 算法，未来可能会升级到更为安全的 SHA256 算法。

如图展示 Git 中的某个目录树的内容信息：

即便开发者自己提交的版本经过 Git 的层层哈希，可以确保内容不被恶意篡改，但仍然有被冒名顶替的危险。

因为 Git 在提交过程不需要验证用户身份，而且提交可以被不同的人在各种传输过程中传输和展示。设想攻击者冒充公司员工制造一个提交，却被公司其他员工认为是公司内部人士会有多可怕。目前基于 Git ，业界的普遍做法是引入 GPG 签名机制。

GPG 是基于非对称加密算法的一个应用，其原理是使用私钥处理一段信息，得到一段新的信息，这段新的信息只能由私钥生成，而且可以使用对应的公钥来识别这段新的信息的生成来源，这段新的信息就被称为数字签名。

简单来说，信息发布者使用自己的私钥（私人印章）对要发布的信息（待签名文件）进行签名，并且把原始文件和数字签名一并发送给使用方。使用方持有发布方的公钥，对收到的数字签名和原始文件进行校验就可以确认确实是发布方发出的，未被冒名顶替。这类似给要发布的信息盖了个章。

如图展示 Git 中某个提交被开发者添加 GPG 签名的效果：

要点小结

• Git 本身的哈希机制可确保内容不被篡改
• 使用 GPG 为提交签名可防止冒名顶替
• 服务器端要校验 Git 提交邮箱声明和 GPG 签名

存储安全

存储安全是指当代码被检入到代码仓库后，如何保证数据的机密性，完整性和可用性。抛开基础设施的安全性不谈，对于代码存储来说，数据往往由数据库数据和代码库文件组成，这里重点讨论代码文件存储安全问题。

机密性

代码仓库中的代码大多直接存放于操作系统的磁盘中，在服务器软件进行读写操作的时候，不涉及网络传输的机密性风险，但直接写入磁盘上的文件在未做控制的情况下，往往可以被操作系统上的很多不相关进程随意读写，这些非预期的代码读写会造成额外的风险。

一种做法是去控制每一个文件的读写权限，如统一设置为 600 ，另一种做法是干脆只允许服务器上运行一个业务进程，实现操作系统级别隔离。

容器技术提供了一种良好的隔离进程方案：如在 Kubernetes 体系下，代码仓库存储在 PV 上，并只被挂载进代码仓库的应用容器内读写，而且基于容器的调度和弹性特性可以较好的支持高可用并避免资源浪费。

完整性和可用性

我们知道 Git 本身会通过哈希校验机制来确保仓库的完整性，但前提是仓库文件是完备的。如果仓库的文件丢失或者损坏，Git 的哈希校验也将无法工作。数据的完整性有很多种解决方案，最常见的冷备，半实时备份，实时备份，磁盘快照等方案都是为了确保文件在丢失或者损坏的时候可以找回，来确保仓库的完整性的。不过总的来说，备份往往是事后的恢复手段，无法实现即时的自愈，最终依据备份机制来进行数据修复往往会影响可用性。

虽然业界没有针对代码仓库的通用高可用方案，但数据库主从策略和 RAID 机制是两个可以参考的做法，这里来做下简要介绍。

数据库主从策略，一种做法是数据写入主库，从库自动增量同步数据。当主库发生故障时，从库自动替代。代码存储类似，可以把存储节点分为主节点和从节点。

RAID 机制是一种磁盘分片存储的冗余机制，有多种做法，如 RAID5 ，分片存储，并存储一份校验信息，当任意一块磁盘坏掉，可以通过校验信息来复原数据。

腾讯云 CODING DevOps 在这方面进行了深入研究，并结合了主从和 RAID 的思路，实现了针对代码仓库的高可用策略，可妥善保障仓库的完整性。

如图所示，对于 D 仓库来说，他的主仓库 D(m) 存放于第二个节点，他的从仓库 D(s) 存放于第一个节点（实质上还可以设定更多从仓库，这里为了图示方便，只显示了一个）。这样的设计让各个节点都可以不闲置计算资源，而且任意一个节点出现损坏都可以快速恢复。

检出安全

代码检出后才能使用，而检出也涉及传输机密性问题，这点与检入部分没有区别。而对于 Git 仓库来说，检出环节的仓库完整性会由 Git 的哈希校验机制保证，也不会有太大问题。检出环节的安全问题往往是因为不合适的权限策略和密钥管理导致代码泄露。

企业内部代码通常有如下四个场景：

1. 检出开发
2. 阅读评审
3. 自动执行（ CI ，自动化测试等）
4. 管理审计

检出开发权限

需要区分开发者能读写的权限范围，保护好关键资源和密钥，按如下原则：

• 按照业务、组件等进行分门别类的存放，仓库隔离
• 根据所处的部门和组织关系配置仓库的权限
• 为分支设定读写权限，只允许有权限的成员写入
• 使用文件锁定方式保护敏感文件不被误修改
• 统一传输协议，如只允许 HTTPS 或者 SSH
• 为个人密码，令牌，公钥等设定有限期
• 审计密码，令牌，公钥等的使用记录
• 为目录设定读写权限，只允许指定开发者读取或者写入某些目录
• 禁止强制推送策略，防止代码被回退

如图所示，设置仓库内的目录权限：

阅读评审权限

诉求是看源码和辅助信息，并做出自己的评审结果，不涉及写入代码，按如下原则：

• 区分读写和只读成员群体，禁用后者的写入权限
• 区分深入评审和轻量级评审，禁用后者的代码检出权限，只允许其 Web 页面查看源码
• 使用 CODEOWNERS 机制自动指定评审成员

如图所示，设置仓库的 CODEOWNERS：

自动执行权限

自动检出，检出行为背后不对应一个人，不涉及代码写回，按如下原则：

• 禁止成员把自己的密码，令牌，密钥用于自动执行
• 使用项目 /仓库令牌，部署公钥机制确保令牌和密钥只对指定仓库有权限
• 为不同场景设置专用的令牌，不得混用，也不得用于其他用途
• 为令牌，公钥等设置有效期
• 为令牌，公钥等设置禁止写入权限
• 审计令牌，公钥等的使用记录

如图所示，设置令牌的权限和有效期：

管理审计权限

这种场景是非技术人员希望了解仓库统计信息，活跃情况，了解研发过程进度等，按如下原则：

• 给成员开放所管辖的仓库列表和仓库详情的 Web 页访问权限
• 禁止成员使用 HTTPS/SSH 协议把源码检出到本地
• 禁止成员在网页端下载源码包

如图所示，设置禁止仓库写入等权限

总结

代码资产管理是个体系化的工程，这个过程中的安全性不是某个单点可以完全保障的，需要从检入，存储，检出三个环节对全链条进行风险分析。很多企业在这些方面很重视，但聚焦错了方向，可能付出了很大努力，但实质上依然冒着代码资产的丢失和泄露的巨大风险。希望此文可以帮助企业正视代码资产安全，为代码资产管理者提供一个审视安全的基本框架。

让 CODING 为您的代码资产保驾护航

文章来源于优普丰敏捷教练 Scrum ，作者王洪亮大锤

前言

一页纸需求是指的业务方在提需求的时候篇幅很短的情况。有的时候极端情况下，原始需求只有一句话，甚至只有几个字。比如说：“开四限四“就是一个涵盖了非常多的要求的一种需求。

一页纸需求会让很多 BA 感到困惑。BA 也知道一页纸需求表达的不全面，但是需要科学的分析才能够将细节进行完善。否则就会变成散点式补充需求内容，也无法确认自己补充的内容是否完整。站在业务方的角度来看，一页纸需求也许是他们尽可能提出的最全面的内容了。业务方由于非 IT 背景，可能想提出更多的内容也无能为力。因此，需要 BA 承担对应的职责，将一页纸进行扩充完善。

一般情况下，BA 会通过头脑风暴的方式来梳理一些问题，向业务方提出问题，获得答案。但是头脑风暴的方式在这里能够发挥的作用有限，即使是问了很多问题，仍然不知道自己是否梳理了所有该梳理的场景，是否还有场景遗漏。因此需要一个有条理，有脉络的方式进行一页纸需求的分析。从而能够快速而有效地建立起整个需求文档，以推进开发工作。

应对一页纸需求，大锤梳理了一个五步法，得到广泛应用，并且妥善的解决了一页纸需求的问题。五步法是指通过业务价值、角色梳理、术语定义、主业务流程梳理、纲举目张详细分析的方式进行需求分析。

当 BA 接到一页纸需求时，可以按照五步法需求分析法进行：

五步法示意图

第一步应要确认该需求的业务价值，通过业务价值来判断该需求的核心功能以及确认需求的优先级。以后的需求都要围绕着这个业务价值进行展开分析，这样才能够聚焦，才知道设计的功能是否必须的，是否能够帮助实现对应的业务价值。同时也能够判断对应的业务价值实现的方式是否科学。

第二步应对该需求中所涉及的角色进行梳理。很多时候由于缺少对角色的梳理，并不能够正确的理解在业务中，各种角色如何完成自己的任务以达到实现业务价值的目标。如果遗漏了某些角色，那么会导致最后业务无法闭环运行的后果。另外也可能由于角色梳理的缺失导致需求分析结果的不正确。比如说，某个角色的功能都开发了，却缺少了对应的功能入口。

第三步对需求的术语进行定义。在一些项目中可能涉及专业词汇术语，因此在前期明确术语的定义，后期在与客户确认需求功能时，可以统一用词习惯。不会出现一词多义或者一意多词的情况。并且，术语定义可以为开发工程师和测试工程师提供统一的用语，为开发过程的沟通效率提高奠定基础。并且由于术语定义的环节能够将术语的含义讲清楚，也对后续的需求分析理解产生了不可磨灭的重要作用。

进行完前三步后，应对主流程进行梳理。一般来说，一页纸需求当中会包含必要的乐观路径的描述。通常描述主流程不会特别困难。但是缺失往往都在于悲观路径，边界条件等环节，因此第五步，通过纲举目张的方式对需求的细节进行梳理补充。纲举目张表示渔民晾渔网的时候，将渔网挂起来之后，渔网的孔就会自然的张开。引申到写文章的时候，文章的大纲要是先定义好了，文章的内容自然就清晰了。同样的，在分析需求的时候如果能够对于细节环节的梳理方式有个总体脉络，就可以清晰地梳理出各种隐含的需求。第五步可以包括：边界思维、对称思维、异常思维、发散思维、关联思维、并发思维等各种思维方式的应用，以梳理出各种需求的细节。

1. 业务价值

1.1 什么是业务价值

解决别人愿意花钱解决的问题，就是业务价值。它通常是市场、企业、用户三方可以获得的价值主张，结合组织战略规划以及产品 /项目生命周期进行定义。

1.2 业务价值解决的问题

1.2.1 发现潜在需求

干系人提供的原始需求可能包含的信息不充分，如果 BA 照搬就可能产生场景遗漏，但是如果 BA 能够考虑业务价值，从用户角度出发分析需求，就会发现潜在的需求。因此我们需要明确组织业务目标和价值，之后的分析都围绕这个目标展开。

1.2.2 划分需求优先级

需求的排序首先应该是依照业务价值来进行的，结合市场的趋势、产品所处的生命周期阶段、组织当前的产品 /项目组合战略、研发的投入成本等进行综合考虑。根据业务价值可以协助我们更好的对需求进行优先级划分。

1.3 如何实现业务价值

1.3.1 建立业务目标

BA 在进行需求分析的过程中，会有很多想法和见解，但如果无法将其进行串联和推动，那就会忙于交付而不知道为什么交付。一般来说业务目标会有：赚钱、省钱这两大方向。赚钱又分为直接盈利（比如说：促进销售）和间接盈利（比如说：提高访问量，用户粘性等）。

1.3.2 满足核心业务

首先要满足核心业务，才能够确保价值的交付。然而核心的业务识别是一个相对较为有难度的事情。其实现方式也有很多种。之后会撰写文章讲述如何识别核心业务。比如在贷款业务中，还款模块可以分为：正常还款，提前划款，逾期还款，坏账还款等多个场景，而正常还款是最核心的业务。

1.3.3 满足正确优先级划分

优先级的分级最为常见的是按紧急、重要关联词构建。下图是常见的优先级划分方式，但是如果不掌握更具体的方式，就会陷入到，不知道该如何排序的境地。我们会在另外的文章中讲述如何进行合理有效地需求排序。这里先了解基本概念。

在用四象限法时同时，我们要理解优先级划分的核心所在是最好的需求优先级还是跟着业务走。因此我们也需要思考以下几个问题来对优先级进行判断：

1. 不做 - 是否会造成严重的问题和恶劣的影响？

2. 做了 - 会产生的好处以及实现的目标？

3. 是否跟核心用户利益有关？

4. 是否跟大部分用户权益有关？

5. 是否跟效率或成本有关？

2. 角色梳理

2.1 什么是角色梳理

明确定义参与到业务和系统活动中的所有角色。

2.2 角色梳理解决的问题

角色梳理可以帮助我们差缺补漏，减少遗忘场景的问题。存在有可能不使用系统，但是对系统却有很大左右权的潜在角色。比如：老板给 HR 买了一套考勤打卡系统，他不打卡，但是他却要关注如何通过打卡系统管理员工。

2.3 如何进行角色梳理

2.3.1 进行角色分析

系统为哪些类型的用户提供服务，他们都各自承担哪些不同的职责，并据此定义系统边界，也就是系统是对现实世界哪个范围的内容进行的模拟，这影响到需求设计和实现的范围以及工作。

2.3.2 利用角色功能矩阵进行梳理

在需求分析中，我们可以利用角色功能矩阵进行角色梳理，角色-功能矩阵将角色和功能进行正交排布，从而梳理那个角色可以执行哪个功能。

2.3.3 利用角色权限矩阵进行梳理

每个角色都有一个自己的权限矩阵，排布方式可能是树形目录。表明了该角色对应到详细的按钮级别的功能操作权限。

3.术语定义

3.1 什么是术语定义

对术语进行定义，以便后续沟通能快速无二义。

3.2 术语定义解决的问题

进行需求梳理时，明确系统术语定义方便于后期的沟通与功能确认。

3.3 如何对术语进行定义

3.3.1 统一语言

统一语言为今后的交流提供了统一的术语定义。要定义统一语言，最好是提供原名（本地语言）和英文名。英文名称是为了让开发者在源代码中统一名称。而它的描述是为了明确它是什么。如果可能的话，附上一张图片会增强可理解性。

有的时候，一个术语可能在多种情况下有不同解释。因此可能需要建立一个 Wiki 才能够说明清楚。比如说：风险对冲。

3.3.2 制作术语字典

定义项目中使用到的所有术语，包括同义词。这里的内容就是一个字典，为每个名字写下简明扼要的定义，其中包括在需求规格说明书中使用的所有名称的含义。

这个字典应该使用你的组织或行业使用的标准名称。这些名称也应该反映出在工作领域中当前使用的术语。该字典包括项目中用到的所有名称。请仔细地选择名称，以避免传达不同的、不期望的含义。

4. 主业务流程梳理

4.1 什么是主业务流程梳理

利用闭环思维，需要从用户的视角来思考问题。具体是指以用户身份按照各种场景从头到尾走一遍，以确认场景的完整性。这里包括两种工具可以利用，一个是用户旅程，一个是对象旅程。

4.2 主业务流程梳理解决的问题

4.2.1 避免核心场景遗漏

根据用户的视角来对主业务流程进行梳理，可以避免核心业务场景的遗漏，同时也避免遗漏页面和交互。比如说，在一个电商促销活动模块的开发中，一页纸需求中只描述了如何促销，却忘记了引流功能的描述，如果不加以分析，就会遗漏引流这个模块导致整个电商活动的失败。

4.2.2 保证流程的逻辑性

根据用户的视角来对主业务流程进行梳理，确保主业务场景和业务的完整性。

4.3 如何对主业务流程梳理

4.3.1 绘制主业务流程图

流程图能够提供一种快速了解业务如何运作的视图。因此通过绘制主业务流程图能够快速明白业务的最终目标是什么，有哪些角色在参与以及他们的职责，以及彼此之间的联接。一般来说，流程图是个有效的工具，也有的场景只用流程图无法清晰的描述需求，可能要选取其他的合适工具。

4.3.2 用户访谈

采取用户访谈的形式来梳理主业务流程，通过访谈来判断是否遗漏业务场景。在进行用户访谈的时候注意带入到用户的身份中去。

5. 纲举目张详细分析

5.1 什么是纲举目张

利用边界思维、闭环思维、对称思维、异常思维、发散思维、关联思维、并发思维等方式，梳理所有流程环节、判断条件及边界场景等各种细节。

5.2 纲举目张解决的问题

通过纲举目张的方式可以顺利的梳理出各种细节场景。对于已经有明确答案的，可以直接提供答案；对于有多个选项的，可以提供选项让业务代表选择；对于没有明确答案的情况，可以留白，让业务代表填写。这样通过较为有条理脉络的方式进行各种场景细节的梳理的方式，可以帮助更快的一次性建立较为完整的需求体系，并且迅速推动开发工作。并且在此过程中，容易对需求质量建立信心。不至于像散点式提问的方式，BA 自己也不清楚需求到底还有多少没有确认的细节。

5.3 如何对纲举目张详细分析

6. 案例

6.1 案例介绍

为了能够在下个销售季获得更好的销售业绩，特准备开通线上优惠活动。活动内容如下：

新注册用户，赠送 200 元优惠券，有效期到 2019 年 12 月 31 日。

老用户在活动期间下单，现金（含支付宝，微信，信用卡；不是预充值即可）支付，满 500 减 100 。每单单独结算。

另外，充值满 1000 赠 100 。充值上限 10 万元。

** [前提假设] **

已经存在一个电商系统，包括购物，下单，支付，物流等功能都已经存在；

本次只考虑需求变更的部分；

移动端使用。

6.2 五步法分析需求

1 ）业务价值

业务价值是指：解决别人愿意花钱解决的问题，就是业务价值。它通常是市场、企业、用户三方可以获得的价值主张，结合组织战略规划以及产品 /项目生命周期进行定义。

本案例中，需要明确了商业价值才能够围绕着商业价值进行需求分析的展开，一切后续活动都是围绕着商业价值展开的。因此要明确商业价值：

• 新用户注册，成为来年的消费群体
• 老用户消费，年底回笼资金

2 ）角色分析

角色分析是指：系统为哪些类型的用户提供服务，他们都各自承担哪些不同的职责，并据此定义系统边界，也就是系统是对现实世界哪个范围的内容进行的模拟，这影响到需求设计和实现的范围以及工作量。

在对需求进行分析时，要明确该需求中涉及到的角色，避免产生遗漏问题。本案例中涉及的角色主要为 3 个：

• 新用户

• 老用户

• 管理员

3 ）术语定义

术语定义是指：统一语言为今后的交流提供了统一的术语定义。要定义统一语言，最好是提供原名（本地语言）和英文名。英文名称是为了让开发者在源代码中统一名称。而它的描述是为了明确它是什么。如果可能的话，附上一张图片会增强可理解性。

因此需要对术语进行明确定义，本案例中需要确认的术语：

• 满减活动（ DiscountWithGivenAmount ）：消费达到一定金额之后，就可以减扣一定的支付金额的方式为满减活动。

4 ）主流程梳理

主流程梳理是指：利用闭环等思维，以用户身份按照各种场景从头到尾走一遍，以确认场景的完整性。

梳理流程过程中，需要注意的是流程是否产生遗漏、业务整体逻辑是否正确。因为我们可以借助一些思维方式来保证需求分析的质量。

• 闭环思维：干系人提供的原始需求可能包含的信息不充分。如果 BA 照搬就可能产生场景遗漏，但是如果 BA 能够考虑业务价值，从用户角度出发分析需求，就会发现潜在的需求。不采用闭环思维仍然可以做出完整的功能，但是这些功能可能因为缺少入口而无法访问。

在本案例中，可以利用闭环思维来确认整个活动流程的节点和出口：

• 边界思维：很多事物都有自己的边界，如上限和下限，开始日期和结束日期。而且数据类型本身也有范围限制，比如整数（ Integer ），长整数（ Long ）或者双精度浮点数（ Double ）。未定义边界的需求在实现过程中会存在非常大不确定性，每个人理解的最佳实现方式是不同的，与业务需求的偏差往往就是 Bug 。有报道称，惠普的 SSD 硬盘会在使用一定的时间长度之后发生故障，就是因为时间超过了 Integer 的上限。

本案例中，可以使用边界思维来确认活动的条件，避免出现恶意事件：

• 关联思维：比如说在做登录的时候，会有密码，那就要考虑，密码是从哪来的，是管理员分配的还是用户设置的，还是默认的，还是通过手机短信通知临时获取的。这样可以考虑到更全面的场景。

本案例中，利用并联思维来分析容易遗漏的场景，做到需求全面覆盖。

优惠券和代金券可以并用吗？

代金券和充值金如何进行消费的，可以单独使用代金券吗？

充值金额是可以任意的吗？

赠送的金额和消费顺序？

• 发散思维：发散思维帮助 BA 发现更多的潜在场景。如果有个条件 A ，也许还有个条件 B 和 C 。比如说，性别不只是男女，有的公司定义了 70 多种性别，要把多样性考虑进来。一个自然数的输入框如果输入了下列内容到底会不会被认作是有效数字呢？“.0”, “0.”, “00”, “01” or “2e5”。通过发散思维可以发现更多的可能性来识别潜在需求。

本案例中，利用发散思维来挖掘更多的潜在需求，例如凑单。

• 对称思维：如果有注册，那就有注销；如果有支付，那就有退款；如果有订货，那就有退货；如果有审批通过，那就有驳回。

本案例中，利用对称思维进一步来检查需求分析是否存在遗漏，整体流程逻辑是否无误。

• 时间轴：用时间轴来定义事件的时间边界；也可以用于其他的范围描述的内容。

用时间轴代替大量文字，并且可以更好的展现出对时间的边界有。本案例中，利用时间轴来明确优惠券等有效期限。

确认优惠券的有效期限：

确认订单的积分时效：

7 月 1 日之 7 月 31 日间的订单可以得到 2 倍积分。

确认双时间的范围：

7 月 1 日之 7 月 31 日间的订单的积分可以在 10 月 1 日到 12 月 31 日间使用

确认不同角色协作：

政策指定时间段（例如 7 月 1 日 - 7 月 31 日）符合政策的从本公司的采购可以累积积分。

同时还可以利用时间轴描述对称流程：

其他 - 对象建模 - 资金池：

根据对象建模，把储值金额进行区分开，以原有储值、新储值、新储值赠礼进行拆解形成资金池，更好的判断资金的来源并统一汇集。

7.总结

通过以上一页纸需求分析的详细说明和案例解析，我们对五步法有了深刻的了解，同时对五步法的实践也有了深刻的认识。

在一页纸需求分析中，我们不仅要考虑到业务价值、角色梳理、术语定义、主流程梳理以及纲举目张的表面含义，同时要正确的理解其中每一步涉及使用的工具，还要通过实践来进行学习。

作者介绍：

作者：王洪亮 /大锤

可视化业务需求分析工具箱创始人，优普丰敏捷咨询首席教练、培训师。

社区知名技术大牛，资深软件开发及敏捷咨询师，精益创业导师。他整理了一套独到的需求分析工具箱。该套工具箱的工具以可视化为主要特点，帮助企业在需求分析的过程中以图和表为主的形式来展现需求，提高需求分析全面性的同时，缩短需求分析所需要花费的时间。并且为开发人员和测试人员在需求理解的过程中节省时间，减少反复确认，从而对整体开发效率起到了提升的作用。

作者简介
张海立（驭势科技云平台研发总监）：开源爱好者，云原生社区上海站 PMC 成员，KubeSphere Ambassador ；日常云原生领域工作涉及 Kubernetes 、DevOps 、可观察性、服务网格等。
玉易才：Nocalhost Maintainer ，CKA 、CKAD ，Work From Home

KubeSphere 简介

KubeSphere 是在 Kubernetes 之上构建的以应用为中心的多租户容器平台，提供全栈的 IT 自动化运维的能力，简化企业的 DevOps 工作流。 ​

KubeSphere 提供了运维友好的向导式操作界面，即便是 Kubernetes 经验并不丰富的用户，也能相对轻松地上手开始管理和使用。它提供了基于 Helm 的应用市场，可以在图形化界面下非常轻松地安装各种 Kubernetes 应用。 ​

Nocalhost 简介

Nocalhost 是一个允许开发者直接在 Kubernetes 集群内开发应用的工具。

Nocalhost 的核心功能是：提供 Nocalhost IDE 插件（包括 VSCode 和 Jetbrains 插件），将远端的工作负载更改为开发模式。在开发模式下，容器的镜像将被替换为包含开发工具（例如 JDK 、Go 、Python 环境等）的开发镜像。当开发者在本地编写代码时，任何修改都会实时被同步到远端开发容器中，应用程序会立即更新（取决于应用的热加载机制或重新运行应用），开发容器将继承原始工作负载所有的声明式配置（ configmap 、secret 、volume 、env 等）。

Nocalhost 还提供：

• VSCode 和 Jetbrains IDE 一键 Debug 和 HotReload
• 在 IDE 内直接提供开发容器的终端，获得和本地开发一致的体验
• 提供基于 Namespace 隔离的开发空间和 Mesh 开发空间

在使用 Nocalhost 开发 Kubernetes 的应用过程中，免去了镜像构建，更新镜像版本，等待集群调度 Pod 的过程，把编码 /测试 /调试反馈循环(code/test/debug cycle)从分钟级别降低到了秒级别，大幅提升开发效率。

此外，Nocalhost 还提供了 Server 端帮助企业管理 Kubernetes 应用、开发者和开发空间，方便企业统一管理各类开发和测试环境。

本文将介绍如何在 KubeSphere 中快速部署 Nocalhost Server及基本使用，提供一个帮助研发团队统一管理 Nocalhost 应用部署的管理平台；以及 Nocalhost Server 基本使用。 ​

前提条件

安装 KubeSphere

安装 KubeSphere 有两种方法。一是在 Linux 上直接安装，可以参考文档：在 Linux 安装 KubeSphere； 二是在已有 Kubernetes 中安装，可以参考文档：在 Kubernetes 安装 KubeSphere。 ​

在 KubeSphere 中启用应用商店

在 KubeSphere 中启用应用商店可以参考文档：KubeSphere 应用商店。

安装 Nocalhost Server

在 KubeSphere 3.2 中从应用商店安装

Nocalhost Server 已经集成在了 KubeSphere 3.2 的应用商店中了，因此可以直接访问应用商店并按 常规方式 进行应用部署。

在 KubeSphere 3.x 中通过应用仓库安装

在 KubeSphere 3.x 中，您可以 通过应用仓库来部署应用，下面分步介绍具体的操作过程。

步骤 1：添加应用商店

首先，使用具备企业空间管理权限的账号登陆 KubeSphere 并进入您选定的一个企业空间，在您的企业空间中，进入「应用管理」下的「应用仓库」页面，并点击「添加仓库」。

在弹出的对话框中，可将应用仓库名称设置为 nocalhost，将应用仓库的 URL 设置为 https://nocalhost-helm.pkg.coding.net/nocalhost/nocalhost，点击「验证」对 URL 进行验证，验证通过后再点击「确定」。

⚠️ 注意：URL 必须贴全链接，不能缺失 https:// 这部分，否则会验证失败

应用仓库导入成功后会显示在如下图所示的列表中。

有关添加私有仓库时的更多参数信息，请参见 导入 Helm 仓库。

步骤 2：从应用模版部署应用

进入您选定的用于部署 Nocalhost Server 的项目，如果还没有可用项目，可以直接打开企业空间页面中的「项目」栏目，「创建」一个新的项目。

假设我们已经创建了一个名为 nocalhost-server 的项目，进入项目界面，进入「应用负载」下的「应用」页面，再点击「创建」新应用。

在弹出的对话框中选择「从应用模板」创建。

• 从应用商店：选择内置的应用和以 Helm Chart 形式单独上传的应用。
• 从应用模板：从私有应用仓库和企业空间应用池选择应用。

从下拉列表中选择之前添加的私有应用仓库 nocalhost，可以看到仓库中的 Nocalhost Server Helm Chart 如下显示。 ​

您可以查看「应用信息」和「 Chart 文件」，在版本下拉列表中选择版本，然后点击「部署」。 ​

设置应用「名称」，确认应用「版本」和部署「位置」，点击「下一步」。 ​

在「应用设置」标签页，您可以手动编辑清单文件或直接点击「安装」。建议把 service.type 设置为 ClusterIP，以确保安装不受 Kubernetes 网络环境影响。当然，您完全可以结合自身研发环境来选择使用 NodePort 或 LoadBalancer 服务类型来暴露 Nocalhost Server （ Server 本身对此并无限制）。 ​

最后等待 Nocalhost Server 创建完成并开始运行，可以在「应用」中看到如下应用状态（可能需要刷新一下页面）。 ​

步骤 3：暴露 Nocalhost Server 服务

进入「应用负载」下的「服务」页面，选择 nocalhost-web 服务，在最右侧的拉下菜单中选择「编辑外部访问」。

在弹出的对话框中选择合适当前云端网络环境的外网「访问方式」，然后点击「确定」即可应用服务配置。

本文假设我们仍然保持 ClusterIP 的访问方式，通过 kubectl port-forward 来进行后续的 Nocalhost Server 使用。

❯ kubectl -n nocalhost-server port-forward service/nocalhost-web 8080:80 Forwarding from 127.0.0.1:8080 -> 80 Forwarding from [::1]:8080 -> 80 

⚠️ 注意：这里的 nocalhost-server 请替换为您实际使用的部署了 Nocalhost 应用的 Namespace

至此，已完成在 Kubesphere 中快速部署 Nocalhost Server ，如您是第一次使用 Nocalhost Server ，可继续以下关于 Nocalhost Server Dashboard 配置、在 Nocalhost IDE 插件中进行开发体验的内容。

使用 Nocalhost Server

完成 Port Forward 后可使用 http://localhost:8080 来打开 Nocalhost Server Dashboard 页面；使用默认账号 admin@admin.com 及密码 123456 进行登陆。登录后请更改默认密码。

​

创建集群

Nocalhost Server 多用于管理整个团队的 Nocalhost 研发环境，因此我们首先需要添加可进行管理的集群。

在 Nocalhost Server Dashboard 中选择左侧菜单列表中的「集群」，进入页面后选择「添加集群」。 ​

在弹出的对话框中输入「集群名称」，并录入 kubectl 可用的、具备 cluster-admin 权限的 kubeconfig 文件后「确认」。 ​

目前可导入的 kubeconfig 文件内容还不支持 exec 类型的用户凭证，如果您使用的是这里凭证，建议您另外生成一个具有足够权限的 ServiceAccount 并使用其对应的 kubeconfig 。

这里有多种方式获取目标集群的 kubeconfig ，例如您可以返回 KubeSphere 并进入集群页面，获取当前集群的 kubeconfig 文件。注意，如果使用 kubeconfig 文件的应用部署在当前集群外，您需要将 clusters:cluster:server 参数的值修改为对外暴露的 Kubernetes API 服务器地址。 ​

添加成功后，可以得到如下的集群信息页面。

创建开发空间（ DevSpace ）

接下来，我们进入「开发空间」页面，选择「创建开发空间」，并在弹出的对话框中选择「创建隔离开发空间」。

「共享开发空间」，即 MeshSpace ，不在本文章讨论范围，更多可参考 Manage MeshSpace 这篇文章介绍。​

在弹出的对话框中，可以填写「开发空间名称」（这里设置为 demo），选择「集群」和其「所有者」，并按需进行「其它设置」。

创建完成后，可以在「开发空间」页面看到已创建的隔离开发空间，如下图所示。 ​

创建 bookinfo 样例应用

下一步我们开始为团队创建一些可部署的应用，先进入「应用」页面，选择「添加应用」。

在弹出的对话框中填写「应用名称」，同时我们继续填写其它信息：

• 选择 Git 作为「安装来源」
• 输入 https://github.com/nocalhost/bookinfo.git 作为「 Git 仓库地址」
• 选择 Manifest 作为「 Manifest 类型」
• 「应用配置文件」留空，即使用默认值 config.yaml
• 「 Git 仓库的相对路径」填入 manifest/templates

可访问 GitHub 查看完整的 bookinfo 样例应用仓库，了解详细的配置文件细节。

创建用户并共享开发空间

最后，我们创建一个样例用户来演示如果共享开发空间。进入到「用户」页面后，点击「添加用户」，在弹出的对话框中填入必须的用户信息后「完成」添加。 ​

然后我们回到开发空间，选择我们之前创建的 demo 空间，点击画笔图标进入「编辑开发空间」的「共享用户」标签页，开始「添加共享」。 ​

选择需要添加的用户，并注意选择默认的 Cooperator 协作者权限，另一个 Viewer 观察者权限的用户只能浏览开发空间。

至此，我们在 Nocalhost Server Dashboard 中的配置就告一段落，下面将进入 IDE 利用 Nocalhost 插件执行应用的部署及开发体验。 ​

部署 bookinfo 应用部署

这里我们将使用 VS Code 执行应用的部署，首先需要 在 VS Code 中安装 Nocalhost 插件。 您也可以使用 JetBrains 及其 Nocalhost 插件。

在 VS Code 中打开 Nocalhost 插件面板，点击 + 号创建集群连接，填入 Nocalhost Server 地址，并使用前面创建的普通用户 test 的用户名及密码进行登录。

创建成功可以看到之前在 Nocalhost Server Dashboard 中创建的开发空间 demo(nh1btih)。

点击 demo 空间右侧的火箭图标，会在 VS Code 编辑器顶部加载应用列表，如下图所示可以看到之前添加的 bookinfo 应用。

选择该应用即会启动在 demo 空间中的 Nocalhost 应用部署过程（选择应用源的默认分支进行安装即可），安装完成后，会出现如下日志和弹窗提示：

同时在 Nocalhost 插件面板中也可以展开 Workload 看到具体的部署内容。

开发体验

• 点击绿色图标即可进入开发模式，选择从 git 仓库克隆源码。（第一次进入开发模式，Nocalhost 会提示你选择源码目录，可以直接选择本地的源码目录，也可以选择从 git 仓库克隆到本地，后续 Nocalhost 会记住源码目录，再次进入开发模式时，会直接打开这个源码目录）
• 进入开发模式后 Nocalhost 会自动将工作负载的镜像替换为开发镜像，并且将源码同步到远程容器中。
• 进入开发模式后会自动打开一个远程容器的终端，开发者可以在这个终端里面执行命令，运行开发程序。
• 右键工作负载 authors ，点击 Remote run ，即可在远端容器里面运行在开发配置里面预设好的应用运行命令。
  
• 更改代码并保存后，Nocalhost 自动将更改后的代码文件同步到远程容器中。（若在开发配置里面配置了该 hotReload: true 参数, nocalhost 将会自动在远程容器中再次运行预设好的应用运行命令，更改代码后无需要再次点击 Remote run 或者手动运行应用运行命令）

远程调试

• 右键工作负载 authors ，点击 Remote debug ，即可进入远程 debug 模式。
• 打上断点，在浏览器访问 http://127.0.0.1:39080/productpage ，即可进行远程 debug

引用链接

[1] KubeSphere: https://kubesphere.com.cn/ [2] Nocalhost: https://nocalhost.dev/ [3] Nocalhost Server: https://nocalhost.dev/docs/server/server-overview [4] 在 Linux 安装 KubeSphere: https://kubesphere.com.cn/docs/quick-start/all-in-one-on-linux/ [5] 在 Kubernetes 安装 KubeSphere: https://kubesphere.com.cn/docs/quick-start/minimal-kubesphere-on-k8s/ [6] KubeSphere 应用商店: https://kubesphere.com.cn/docs/pluggable-components/app-store/ [7] 常规方式: https://kubesphere.com.cn/docs/project-user-guide/application/deploy-app-from-appstore/ [8] 通过应用仓库来部署应用: https://kubesphere.com.cn/docs/project-user-guide/application/deploy-app-from-appstore/ [9] 导入 Helm 仓库: https://kubesphere.com.cn/docs/workspace-administration/app-repository/import-helm-repository/ [10] Manage MeshSpace: https://nocalhost.dev/docs/server/manage-devspace-mesh [11] bookinfo: https://github.com/nocalhost/bookinfo/ [12] 在 VS Code 中安装 Nocalhost 插件: https://nocalhost.dev/docs/installation#install-vs-code-plugin [13] JetBrains 及其 Nocalhost 插件: https://nocalhost.dev/docs/installation#install-jetbrains-plugin

点击此处链接一键开启云原生开发环境

云原生时代下，Kubernetes 的普及虽然在部署和运维阶段进一步屏蔽了“微服务”应用的复杂度，但对于开发而言，云原生环境仍旧为开发带来了重重挑战。比如在每次编码后，开发都需要完成重新构建镜像、推送到镜像仓库、修改工作负载镜像版本等一系列流程才能查看编码效果，这直接导致了开发体验差、效率低下。

另外，云原生技术栈跨度大、架构设计紧贴业务需求，从而对开发人员的要求更高，随之而来的企业招聘及用人成本也水涨船高。由此看来，目前云原生开发工具仍不能满足现阶段需求，缺失的能力还需进一步补齐。

而 Nocalhost 的出现让开发者收获了近乎本地化的开发体验，使用 Nocalhost 开发 Kubernetes 应用程序，无需重新构建镜像、更新镜像版本和等待集群调度 Pod 过程，本地编码实时生效，极大地提高了效率。Nocalhost 还提供了便捷的一键 RUN 和一键调试功能，进一步优化了在云原生环境下的开发体验。

另外，Nocalhost 面向开发者提供了 JetBrains 和 VSCode 插件，只需 2 分钟即可迅速上手。

此外，Nocalhost 面向企业则提供了 Server Dashboard ，帮助企业系统性地管理 Kubernetes 的应用和开发者以及各种开发、测试环境。

Nocalhost 团队合影

新技术是行业蓬勃发展的动力，而开源，则是孕育新技术的肥沃土壤。目前，腾讯在 GitHub 上已经自主开源了 130 多个项目，累计 Star 数超过 37 万，是全球开源贡献最大的科技公司之一。Nocalhost 作为腾讯的开源项目之一，自 2020 年 12 月 19 日对外开源以来，代码完全托管在 GitHub 上，积累的 GitHub Star 已达 900+，并于 2021 年 1 月 21 日，入选 CNCF Landscape 。未来，Nocalhost 将继续秉承腾讯的开源精神以及“让开发回归原始又简单”的产品理念持续打磨产品，坚定拥抱开源生态，为简化云原生开发难度，加速云原生普及持续贡献力量。

Nocalhost 是云原生生态里为数不多的立足于开发者视角的开源项目，在云原生的浪潮里，开发者的体验、效率和生产力工具值得引起整个行业的关注。我们期待，云原生给应用架构、服务运维和弹性成本方面带来巨大提升的同时，也能让开发者更加便利的去开发、调试云上应用。 ——王振威 腾讯云 CODING 研发总监

现代化的效率工具的落地已经逐渐从“自上而下”的管理模型转向由“自下而上”的价值驱动，开发者体验是一个被长期忽略的领域。我相信，Nocalhost 在为开发者带来更加便捷开发体验的同时，也将会掀起一股“自下而上”由产品价值驱动的热潮。 ——王炜 腾讯云 CODING Nocalhost 研发负责人、CNCF 大使

点击此处链接一键开启云原生开发环境

本文为 CODING Nocalhost 研发负责人王炜在腾讯云 CIF 工程效能峰会上所做的分享。文末可前往峰会官网，观看回放并下载 PPT 。

大家好，欢迎参加 CIF 大会，今天我跟大家分享的内容是：破解 Kubernetes 应用开发困局。首先做个简单的自我介绍，我是来自腾讯云 CODING DevOps 的王炜，目前是 Nocalhost 项目研发负责人，同时也是 CNCF 大使。话不多说，让我们进入正题。

这次分享主要分为五个方面：

1. 首先是 K8s 环境下的开发困局；
2. 以及主流的云原生开发方式；
3. 接下来是实现容器应用和热加载的原理；
4. 开发和调试演示，这里会用一个 Demo 来进行演示；
5. 最后是开源共建和展望。

首先是第一部分：K8s 环境下的开发困局。提到云原生开发，我们就不得不先从 Docker 开始说起。当我们的微服务越来越多，运行环境越来越复杂的时候，Docker 镜像为我们提供了很好的解决方案。但是当镜像和容器越来越多，服务的编排就成为了一个难题。这时候也出现了很多方案，例如 K8s 、Docker Swarm 等等。当然 K8s 已经几乎成为了事实标准，也成为了容器编排的首选方案，然而这个事实标准提供的能力却是面向运维的。例如，我们可以通过 Liveness 和 Readiness 定义服务的自动恢复机制，通过 Resource 定义资源用量等。这些定义其实对开发人员来说是增加了极大的额外负担，也造成了开发和调试两难的问题。

此外云原生的技术栈跨度非常大，这就对开发人员提出了更高的要求，这也要求团队对云原生架构设计也需要更加符合业务的需要。所以总体而言，对企业来说，招聘和用人的成本也更高了。

下图是一张 CNCF 云原生应用开发的全景图，我们会发现云原生开发工具这一环节目前仍然是缺失的。云原生开发这么难，那么主流的开发方式又是什么呢？或者说我们现在是怎么解决问题的？

经过总结，目前云原生开发方式主要有以下四种。

1. 全手工的流程。例如手工构建以及推送镜像，修改镜像版本，并且等待调度生效。我们把每次查看编码效果称为编码的反馈循环，这种开发方式编码的反馈循环大概需要十分钟一次，这是非常漫长的过程。

2. 全自动的流程，也就是把手动的环节变成了自动。这种方式显然会更快一些，但是它的反馈循环也只是缩短为了五分钟左右一次。

3. 第三种是对云原生比较了解的团队经常会使用的方案，也就是使用 Telepresence 这款工具来开发。Telepresence 主要是打通本地和集群的网络，使开发者能够在本地进行开发。这种开发方式把编码的反馈循环降低到了 10 秒 1 次，但是因为开发服务以源码的方式运行在本地，这种方式有一定的限制，我将在后文深入讲解。

4. 第四种是使用 Nocalhost ，直接在容器里开发。这种方式可以摆脱 Telepresence 在某些场景下的使用限制。

接下来我们详细聊一聊以 Telepresence 为代表的网络打通方案的使用限制。首先它最大的限制是本地环境和工作负载的运行环境有很大的差异，这就导致业务源码很难在本地运行。比如说业务在 K8s Manifest 里声明了 configmap 、secret 、volume 的挂载等等，这些很难在本地重建。其次还有环境方面的差异，以及跨平台，比如说像 Linux 和 Windows 之间的这些平台差异，以及在部分场景下的网络限制。

说了这么多，相信大家也能够理解，在 K8s 环境下开发的最大问题是：每次编码查看效果都需要重新构建镜像，这就导致了长时间的无效的等待。有没有不需要重新构建镜像的方案呢？答案是肯定的。如果我们能在容器里实现进程或者是应用的热加载，每次编码之后可以实时生效，我们是不是就不需要重新构建镜像了呢？

接下来我们继续探讨这种方式的实现原理和方案。首先从 Dockerfile 说起。Dockerfile 里定义了容器的启动命令，一般来说，这是业务进程的启动方式。例如运行一个可执行文件，如果我们进入容器内执行 PS 命令，会发现这个进程对应在容器里面，也就是 PID ＝ 1 的进程。我们以 Go 应用为例，如果让这个 PID ＝ 1 的进程替换为以源码的方式运行，go run main.go 这种方式，我们是不是就可以实现应用热加载，并且修改代码后只需要重新运行这条命令，就可以看到代码效果呢？

我们思路没有错，但是如果要实现这个方案，还需要三个条件。第一是容器的源码从哪里来？除了脚本型语言以外，一般的业务容器都没有源码；第二是以 Go 应用为例，编译的环境从哪里来？我们知道一般情况下构建的业务容器，因为存储大小的考虑，会保持最小的可运行环境；第三，如果将 PID ＝ 1 的进程替换掉之后，怎么阻止容器 Crash ？

我们分别来看如何解决这些问题。首先第一点源码问题，我们可以从本地同步到容器里来解决；第二是编译环境，我们可以把运行中的业务镜像，替换成具有编译环境的开发镜像，就能够提供编译环境；第三，我们可以将 PID ＝ 1 的进程替换为一个阻塞的进程，这三个问题就解决了。当我们实现这些方案后，容器其实已经具备了热加载的基础，Nocalhost 的原理正是基于上述的方案来实现的。接下来我会用一个 Demo 来演示应用的热加载和一键 Debug 的效果。

Nocalhost 提供了 VSCode 插件和 JetBrains 的全系列插件，只要安装就可以立即使用。接下来我将以 Golang 的为例，演示开发 Demo 项目 Booking for 。

[请点击文末阅读原文，前往 CIF 峰会「开源生态与效能提升」专场 - 《破解 Kubernetes 应用开发困局》，于 08:00 处观看 Demo 演示]

容器应用的实时热加载以及一键调试的演示到这里就结束了，感兴趣的同学可以按照 Nocalhost （ nocalhost.dev ）官网的 Quick Start 指导动手来试一试。

通过演示相信大家已经理解 Nocalhost 带来的全新云原生的开发体验。最后一部分我将与大家分享开源共建和展望。Nocalhost 目前是一个完全开源的项目，代码托管在 GitHub 上，已经有 900+ star ，同时也是 CNCF Landscape 项目，并且被收录在云原生全景图当中，也欢迎大家关注和贡献。

关于展望，在这次的分享中，我介绍了 Telepresence 和 Nocalhost 两种开发方式，它们在解决问题的思路上其实是各有不同的，你可以根据自己的业务情况选择一种方法来使用。此外 Nocalhost 提供了完整的开发环境和开发过程的管理能力，对于希望统一管理开发环境的团队，则可以安装 Nocalhost Server 来集中管理开发集群、应用、以及开发环境，当然 Server 也是开源并且免费的，我在这里提供几张 Server 的截图，感兴趣的同学可以遵循官方文档进行安装以及使用。

我的分享到这里就结束了。欢迎大家访问 Nocalhost （ nocalhost.dev ）官网，并根据官方文档进行安装和试用，谢谢大家。

点击此处链接，观看 CIF 峰会回放

本文为 CODING 高级产品经理王海明 在腾讯云 CIF 工程效能峰会上所做的分享。文末可前往峰会官网，观看回放并下载 PPT 。

大家好，我是 CODING 高级产品经理王海明，今天与大家分享的是项目协同 2.0 的设计理念及应用场景。

研发团队现状

在一切上云的数字化时代，将诞生越来越多的软件公司和数字科技企业，传统研发管理方式和理念不能满足这些企业的发展需要。 他们常常面临以下三个问题：

1. 产研矛盾
导致这一矛盾的原因，一是因为工具分治导致信息割裂，开发与需求脱节，产品不符合预期；二是由于产品研发周期过长，无法控制风险；同时由于需求变化快，研发交付速度慢，因此无法满足产品迅速迭代的要求。

2. 管理困境
由于不同产品线研发流程不同，团队难以统一管控；而且管理者缺少度量工具和管理视图，往往无法有效利用研发资源；同时产品交付速度和质量无法满足企业的发展规划，导致交付产品与企业战略不匹配。

3. 理念悖论
由于新工具门槛高、与现有工具差异大、上下游工具无法联动等原因，导致团队没有配套的实践工具，无法实践瀑布或敏捷等研发理论；同时由于无法有效实践研发理论，往往出现打着敏捷的旗号实际在实践瀑布模式的现象，研发管理方法论与实践严重脱节；而且一般研发管理工具所支撑理念较单一，仅有敏捷或仅有传统瀑布模式都不能满足多研发模式并存的团队。

针对以上问题，CODING 推出了项目协同 2.0，是更适合研发团队的项目管理工具。CODING 作为研发团队的基础设施，提供了从敏捷管理到 DevOps 上线的一站式研发管理解决方案。项目协同作为一切需求的源头，覆盖了产品构想、计划到开发的完整流程，迭代规划、需求分解、状态流转、看板视图、进度跟踪等能力一应俱全，让团队高效协同，提高交付效率。

项目协同设计理念

下面我来为大家介绍一下 CODING 项目协同 2.0 的一些设计理念。项目协同的核心元素是事项和迭代，围绕二者形成了多种应用场景和配置方案。例如在敏捷模式下是使用 Backlog 维护需求池、规划迭代、使用看板流转用户故事、查看燃尽图；在瀑布模式下，是通过计划页分解任务、分配任务、排期、登记工时等。从个人在工作台中完成个人任务，到项目成员在项目集中完成跨项目目标，项目协同对于产品研发的每个环节都做了场景化支持。

围绕价值流转和研发效能提升，项目协同提供了以下几大功能与特色：

多种协作方式

• 敏捷工作模式
  该模式是基于 Scrum 的敏捷项目管理模式，从需求池开始到迭代规划再到看板流转，让开发过程井然有序，适用于定期迭代并交付价值的团队。

• 瀑布开发模式
  瀑布开发模式主要用于管理开发计划、分解需求和任务，可以让项目严格按计划流程推进，有效控制项目风险，适用于基于时间或基于交付的软件项目。

• 多项目协同模式——项目集
  以上两种典型开发模式可在单项目中充分发挥优势，但是一旦出现一个产品线涉及多个项目协作，就需要引入新的协作机制，这就是：项目集。 在项目协同中，我们将项目集定义为：一组相关联且被协调管理的项目活动，以便获得分别管理所无法获得的效益。

项目集包含以下基本能力：
1. 项目集计划：录入项目集待办事项，分解事项并将各事项纳入计划中，并设立里程碑用以追踪关键事件进展；
2. 分解计划到项目：项目集涉及多项目协作，可将项目集内事项分解到项目中去完成；
3. 风险管理：在协作中识别风险及时上报，并在项目集中对风险进行集中管理、追踪和解决。

• 自定义协作模式
  在自定义协作模式下，不同事项类型的组合形成不同的协作模式，从而可以解锁更多的项目协作模式，使得团队在 CODING 中不用局限于以上两种基础协作模式。

强大的自定义引擎

事项类型的自定义能力得益于 CODING 强大的自定义引擎。可为团队打造独有的事项类型，并定制与之匹配的开发流程：

• 自定义事项属性
  事项的属性是内容的主要承载体，CODING 的事项属性支持自定义，提供了丰富的数据类型以供选择，涵盖文本、数字、单选菜单、多选菜单等基础数据类型，和成员选择、迭代选择等项目内数据源。

• 自定义事项工作流
  流程是信息有序流转的核心，CODING 的事项工作流可自定义，不仅提供了状态定义、流程自定义，还支持多种步骤流转规则，例如：步骤权限、附加属性、自动更改处理人、自动更改属性等。

丰富的多视角协作

不同的团队有不同的工作流程，不同的角色有不同的工作视角。每个角色在不同协作情况下的聚焦点不同，为此 CODING 提供了丰富多样的协作视角和视图形式：

• 工作台：让成员聚焦于个人未完成的工作；
• 筛选器：将复杂的事项的筛选条件保存下来，以供随时检索，并可设为项目共享筛选器；
• 丰富的事项列表视图：事项支持平铺、树状、看板、甘特图，并且自定义表头；
• Backlog 页面：产品负责人（ Product Owner ）处理用户故事的主要界面，随时对用户故事进行排序并规划进迭代；
• 迭代看板：敏捷团队在迭代过程中的主要协作界面，用户故事的流转一目了然。看板支持自定义，为敏捷团队提供了更丰富的协作形式。

数据互通与集成

CODING 作为一站式开发协作工具， 提供了丰富的工具模块，从协作、管理到编码开发再到知识沉淀，实现了云上研发工作流的全面覆盖。项目协同作为协作的中枢神经，承载的内容不止是简单的需求或任务，还可以将其他模块互通，例如：目标管理可以关联到项目内任务，与公司战略目标联动；测试管理中的测试计划、测试用例可以与迭代、需求、缺陷等进行关联；代码仓库、合并请求等代码资源可以关联需求和任务；知识和文档也能够关联到需求和任务中，充分利用团队的知识沉淀。

同时外部工具也为项目协同提供了更多拓展的可能性，我们现已集成：兔小巢、墨刀、CoDesign 等优秀的第三方工具，还开放了 API 、WebService 等功能，为开发者提供了更多的拓展能力。Service Hook 的消息通知不仅仅支持原生 Webhook ，还支持企业微信、钉钉、飞书、Jenkins 等工具。

多端支持

项目协同支持 PC 网页、移动端网页版、企业微信和微信小程序，全面覆盖移动办公场景，无论是否在电脑前，都可以访问工作台、迭代和事项，及时查看和完成工作。

项目协同应用场景

得益于强大的自定义引擎，项目协同适用于多种角色和应用场景。

适用角色

• 团队管理者
  项目协同的多项目管理能力，提供了全局搜索、工作负载和项目集功能。对于团队管理者来说，丰富的度量视图，可以跟踪团队绩效和负载；统一的配置功能，能为团队协作制定规范和工作流。

• 产品经理
  对于产品经理来说，Backlog 收集需求和迭代规划，提高了产品交付能力；迭代看板和燃尽图，能帮助跟踪迭代进度； Wiki 和文件网盘则可以用来收集用户反馈并沉淀团队知识。

• 开发工程师
  对于开发工程师来说，项目协同的需求和任务分解能力不会遗漏任何关键的开发步骤；同时关联代码仓库等开发工具，打通研发流程的工具链；通过丰富的度量视图，可以帮助开发团队提升研发效率。

• 测试工程师
  测试工程师可以利用项目协同的缺陷管理与跟踪，详实记录所有 Bug ；同时需求与测试用例关联，保证测试覆盖率；最后从测试结果提交缺陷，完整记录缺陷的复现场景。

适用场景

• 敏捷开发
  项目协同预置了 Scrum 敏捷项目管理模式（包括 Backlog 、史诗、用户故事、迭代和故事点等基本工具），以及多样的迭代视图模式（迭代规划视图、迭代看板、故事点燃尽图等），配置灵活多变，适应多种敏捷研发场景（敏捷团队小步快跑、快速交付产品价值）。

• 瀑布开发
  在项目协同内，需求和任务层层分解，提供了精细化的管理能力。团队可以管理开发计划，统一跟进开发进度，同时利用多维度报表，为团队资源配置提供数据依据。

• 一站式 DevOps 开发
  事项关联代码、合并请求，团队可以随时关注编码进度； 事项还可以关联测试用例，提升测试覆盖率和缺陷沟通效率；项目协同内还内置了丰富的度量指标，助力团队提升 DevOps 成熟度。

• 多项目协作开发
  项目集提供了多项目协作空间，让团队能够实现大规模协作；同时将计划分解到多个项目中，让不同项目分而治之；并通过统一的计划视图和里程碑，为 PMO 提供管理视角。

未来规划

最后，我将为大家展示项目协同今后的几个发展方向——

• 协作配置方案：统一配置项目协同事项与工作流，规范团队开发流程，为重用项目配置提供工具；
• 精细的权限控制：事项的每个属性都可控制读写权限，为强管理团队提供精细化事项管理的可能；
• 自动化功能：提供更多自动化处理事项的功能，例如事项自动流转、甘特图自动排期等，规范研发流程，减少重复操作；
• 更多视图工具：不断增加视图工具，例如增加丰富的事项查询语言、组合排序、工时统计与查看工具等；
• 拓展开放性：开放更多 API 、WebService 以及集成更多优秀的第三方工具，完善研发工具链。

我们相信，高度灵活的属性和流程配置，清晰直观的信息展示，规则透明的流转设定，可以让协同有条不紊。项目协同 2.0 的全部功能特性已经可以在 CODING 公有云（ coding.net ）上体验，欢迎大家使用并提出宝贵的意见和建议，一同打磨出更加优秀的产品。

点击观看 CIF 峰会回放，深入体验 CODING 新品！

腾讯云 CODING 旗下产品 CODING DevOps 涵盖了代码托管、项目管理、测试管理、持续集成、制品库、研发流程管理等多款产品和服务，满足了软件开发从构想到交付的关键所需，实现研发团队在云端的高效协同，实践敏捷开发与 DevOps ，全面提升软件交付的质量与速度。

基于完整的工具链，CODING 与深圳农商银行、腾讯微保、长安汽车金融、山西证券深入合作，为金融行业客户提供成熟的研发管理数字化转型、研发管理规范、敏捷开发及 DevOps 等解决方案，帮助企业降低研发工具建设成本，提高产品交付效率，实现研发效能升级。

赋能深农商数字化智慧型银行新征程

深圳农商银行是深圳市的本土地方性法人银行，成立至今，已发展为治理完善、风控稳健、特色鲜明、规模中等且具有良好声誉和较强市场竞争力的现代化商业银行，并以专业化、智能化、综合化的优质金融服务为大湾区 1600 万个人客户和 28 万中小企业客户持续创造价值。

深圳农商银行持续发力科技金融，将大数据、云计算等前沿科技与业务深度融合，实现线上线下立体化服务触达，全力跑出金融服务“加速度”。接下来，深圳农商银行将继续深入推进数字化转型，而数据与 IT 能力是银行数字化转型的基础。深圳农商银行在 IT 能力方面展开了深入建设，并且 DevOps 的建设也成为了深圳农商银行最近三年的重大建设目标之一。

CODING 提供的 DevOps 解决方案贴合了深圳农商银行的实际场景。代码管理和流水线作为 CODING 产品的强势点，获得了深圳农商银行的认可。从 DevOps 的建设，到落地实践方法，深圳农商银行对于 CODING 的方案逐渐产生信赖感。 最终，CODING 凭借专业的能力和积极的态度脱颖而出，与深圳农商银行达成合作。

CODING DevOps 平台的落地，将为深圳农商银行打造一条高度自动化、可视化的软件开发流水线，实现端对端链路闭环，减少研发过程中的人工操作，提高研发版本交付效率。针对代码提交、代码检查、代码分支管理、编译打包、测试等各个环节形成统一的规范，提高发布版本的质量。在平台落地过程中，也结合了深圳农商行的业务特点，针对银行传统单体应用和微服务的定制了分支模型以及配套流水线，通过 DevOps 流水线标准与双态 IT 架构的适配，支持数字化转型的平稳进行。

CODING DevOps 将整体提升深圳农商银行 DevOps 的成熟度，释放其技术潜能，为深圳农商银行朝数字化智慧型银行迈进的新征程赋能。

助力腾讯微保研运一体化项目建设

腾讯微保（ Tencent WeSure ）是腾讯旗下保险代理平台，携手国内知名保险公司为用户提供优质的保险服务，让用户可以在微信进行保险购买、查询以及理赔，让保险触手可及。

为了提供不一样的保险用户体验，微保输出腾讯的“连接、安全、场景”核心能力，与保险公司深度合作。通过结合微保的用户触达、风险识别、网上支付，跟保险公司的精算、承保、核赔和线下服务能力，希望实现全行业的生态共享共赢，最终让用户受惠。

微保的这一目标对其自身的研发和运营能力也提出了更高的要求。

目前，微保内部已经具有了相对成熟的开发交付流程，但部分能力仍有提升空间。而 CODING 的优势功能模块：代码仓库、代码扫描、持续集成、制品管理、制品扫描，能够满足软件开发从构想到交付的关键所需，补齐微保研运的短板。这些优势模块的引入，将成为腾讯微保研运一体化项目建设的重要一环，助力微保通过技术平台的能力拉通项目管理、研发、测试、集成、发布、运营等一系列环节，从整体上提升人员能效及项目能效，并做持续的数据跟踪与项目运营。

微保模式可以说是一次保险模式的创新。通过与腾讯微保的深入合作，CODING 将为微保提供更强大的开发能力、更高效的交付效率，助力微保进一步开放“连接、安全、场景”等能力，成为一个与保险业紧密合作的平台，把保险做到更公平、更高效、体验更好，给用户带来前所未有的创新体验。

推动长安汽车金融研发管理体系建设

长安汽车金融有限公司拥有西部首家由银保监会批准的汽车金融牌照，是专注于汽车产业链销售消费环节的创新型汽车金融公司，为国有控股金融企业。公司业务覆盖除港澳台以外的全国各省市自治区，为近 4000 家汽车经销商、近 200 万个人消费者提供优质金融服务支持。

“十三五”期间，长安汽车金融有限公司立足产业金融定位，实现了跨越式发展。尤其是自金融科技战略实施以来，长安汽车金融通过“短平快”的研发理念取得了众多科技成果。

然而“十三五“建设期间，长安汽车金融成绩斐然的同时也暴露出一些不足，如“业务不够精”、“科技不够强”、“体系不够优”，这些问题已明显制约了部分业务的发展。为了解决这些问题，长安汽车金融战略创新部与信息技术部联合推动基础研发平台的建设工作。

CODING 优秀的产品能力，可以解决长安汽车金融目前的痛点，这是 CODING 成功达成此次合作的关键原因。基于完整的工具链，CODING 将提供成熟的研发管理数字化转型方案，助力长安汽车金融建立内外统一的研发管理体系，提升整体的 IT 价值交付能力，实现研发效能升级。

加速山西证券数字化战略目标实现

山西证券股份有限公司最早成立于 1988 年 7 月，是全国首批证券公司之一，属国有控股性质。经过三十多年的发展，已成为作风稳健、经营稳定、管理规范、业绩良好的创新类证券公司。

公司股东资金实力雄厚，经营风格稳健，资产质量优良，盈利能力良好，公司控股股东为山西金融投资控股集团有限公司。

近年来，山西证券正在大力实施数字化转型战略，积极构建以客户为中心的数字化运营体系。

2021 年 6 月份，山西证券正式与腾讯云签署了战略合作协议，共同探索金融科技在证券金融场景中的创新应用，加速数字化转型战略进程。

DevOps 体系建设作为山西证券数字化转型的重要组成部分，受到山西证券领导的高度重视。CODING 作为腾讯云旗下一站式 DevOps 开发协作平台，无论是产品功能的成熟度还是产品易用性，都匹配客户当前需求。经过长达半年的产品 POC 及方案验证，CODING 解决方案获得山西证券的高度认可，最终双方达成合作。

通过合作的深入，CODING 将为山西证券提供成熟的 DevOps 平台，支撑其业务的快速发展和团队规模的扩张，解决山西证券整体工具链路集成不足、CI/CD 能力较低的问题，也没有持续的人力投入到自建的 CI/CD 方案中的问题，加速山西证券数字化战略目标的实现，进一步提供专业化、智能化、数据化、个性化的金融服务，提升山西证券在行业中的未来核心竞争力。

无限可能 , 不止于金融......

腾讯云 CODING 致力于成为云原生时代研发工具的领跑者，上线以来已稳定运行 7 年，目前已累积超过 200 多万开发者用户，5 万家企业团队，除金融行业以外，服务涵盖互联网、政企等不同行业客户。未来 CODING 将持续打磨升级自身产品，为更多开发者用户、企业团队提供更强大的自主开发能力，在市场不断开拓更多可能，将业务蓝图延伸至更多行业。

本文为 CODING 协同产品总监张路宇 在腾讯云 CIF 工程效能峰会上所做的分享。文末可前往峰会官网，观看回放并下载 PPT 。

欢迎各位朋友，来到腾讯云 CIF 工程效能峰会的分论坛，我是 CODING 的产品经理路宇，很高兴能以这种方式与大家见面。在接下来的主题环节中，会由我先为大家带来 CODING DevOps 研发平台的产品理念和全景解读，我们还邀请了几位今年下半年的新产品负责人给大家带来关于项目协同、WePack 、以及全新产品持续部署 Oribt 和研发流程管理 Compass 的分享（讲稿已在陆续发出）。

我加入 CODING 已经三年了，此前有近十年的研发管理经历，我同时是一个不折不扣的效率工具爱好者。过去几年里我看到了本土研发团队、业界，以及 CODING 产品对研发工具理念理解的三个阶段性变化：从工具、到工具箱、再到软件工厂。

工具、工具箱到软件工厂

西方经典管理理论认为，组织效率可以归为劳动效率、组织效率和人的效率。美国管理学家泰勒所著的《科学管理原理》被德鲁克誉为“20 世纪最伟大的发明”，劳动效率说认为分工提升生产效率，福特的流水线就是分工和工业化的典型代表。经济学家亚当斯密在《国富论》描述了螺丝制造的十八道工序，分别由十八个专门的工人负责完成。以马克思·韦伯为代表的组织理论家认为，有效的划分岗位，形成官僚组织结构能够释放效率，合理、合法的权利是促进组织达到自身目标的必要条件。组织效率最大化的手段是专业化水平与等级制度的结合。用我们今天的话说，就是让不同专业能力的人匹配适合的岗位。玛丽·芙丽特则提出了「以人为本」的人力资源管理理论，更加关注人的心理，管理中需要平衡员工需求与组织发展的目标。

现代数字化、平台化企业强调创新和协同，在经典管理理论的基础上又提出了新的挑战，仅仅分工已经不能满足市场的需要，我们发现：

1.强个体的价值崛起，最有价值的创新是由企业内少部分人完成的；

2.影响组织绩效的因素由内部转向外部，所有员工都需要关注交付内容的价值和客户需要。效能 = 价值 X 效率。如果价值为 0 ，再高的效率也于事无补；

3.由于需求多样化和快速变化，驾驭不确定性成为组织的核心挑战。不确定性是一把双刃剑，能够把握不确定性便是专注了企业发展的机会。

以上，是我们认为的数字化协同的理论根基，管理逻辑正在从分工走向协同，好的工具需要遵循经典的分工理论，但更加需要注重数字经济时代的协同需求。

我们提出这样一个问题 —— 软件研发还是数字化协同的领军行业吗？我找了这样一张 DevOps 2021 年的生态地图，如下图所示，像这样的图片想必大家近年来看到了许多。围绕代码的构建、测试、部署、运行环境、监控、项目管理以及信息流等等的工具层出不穷，这反映了我们所处的技术环境正在快速变化，软件从业人员的确越来越善于使用工具。

你的团队可能在用 Jira 进行项目管理，用 Gitlab 管理代码，用 Jenkins 实现持续集成，用 JFrog 管理制品……但是，一个研发团队需要使用如此多的工具，作为技术决策者在选择时面临不少的压力。从学习、部署再到应用，成本经不起计算。一位新同事入职，需要开上七八个账号，数字资产的管理面临潜在风险。

更重要的是，我们认为在这种工具集形态下，没有给开发者和管理者提供一个真正有效、柔性边界协同的环境。

显然，相比一些高集成度的数字化行业，甚至传统行业，我们不能自信的说我们正保持领先。技术决策者们刚刚走出工具时代，正停留在工具箱时代，迫切的需要一个新形态的协同环境迎接挑战。因此，CODING 提出了数字化软件工厂的概念。这也恰好符合 CODING 产品的演进路线。

2014 年，CODING 率先推出基于 Git 的代码托管服务工具，成为国内领先的代码托管服务平台，也是在此时提出了「云端开发，让开发更简单」的理念。2018 年，我们推出项目协同、持续集成、Cloud Studio 等产品，形成了一系列的必备研发工具，这些工具经过时间的打磨已经达到了国内较领先水平。去年，CODING 首批获得了信通院 DevOps “卓越级”认证，这也是国内最高级别的 DevOps 工具体系认证。今年，我们提出战略升级，结合现代软件工程实践和先进理念，推出研发度量、研发流程管理 Compass 等产品，打造有开放生态能力的数字化软件研发工作流。

“要充分发挥勤勉认真的技术人员的技能，建立一个自由豁达、轻松愉快的理想工厂。”——这是索尼公司已故创始人，井深大先生在公司成立之初写在《成立宣言》中的一句话。我个人非常喜欢这句话，并以它为团队管理和产品设计的信念愿景。

作为软件企业，需要站在现代软件工程理论之上和技术前沿之上，没有工程师可以脱离技术谈效率。同时，管理效率不仅仅来自于分工，更来自于协同。我们对先进研发管理工具有三点基本理念：

1.注重协同效应，1+1 > 2 ，每个人都能获得交付价值所需的信息上下文环境，让团队中强个体能够更强；

2.超越流程，基于卓越工程实践。既要打造优秀的单点工具，也要紧紧围绕云原生、DevOps 等技术理念，让每一个研发团队以更短的路径运用卓越团队的工程理念；

3.一致性、沉浸式的融合体验。紧密的集成用户界面和数据，为每个开发者创造能保持专注的线上工作环境。

一站式 DevOps 平台解读

接下来我将为大家介绍 CODING DevOps 一站式全景。下图体现了 CODING 的主要能力分布，从能力维度上，我们可以将其划分为项目协同、流水线、测试管理、制品管理、持续部署、知识管理、研发流程管理、PMO Office 及团队管理几大模块。

为了便于理解，我们可以将其中几大模块对应一些朋友熟悉的 Jira 、Jenkins 等，基本覆盖了成熟软件工程实践中的全部所需。我们可以从项目管理、工程管理和团队管理三个视角对它进行解读。在 CODING 中，「项目」是基本的协作容器单位。它可以泛指一个有生命周期的工程，也可以代表一个固定工作方式的项目团队。当需求进入需求池后，研发团队可以使用以 Scrum 为代表的敏捷模型，也可以使用偏向计划驱动的经典瀑布模型。史诗代表可以横跨迭代的大粒度需求，需求、任务、缺陷等是基本事项分解单位。CODING 包括了一个成熟的代码仓库服务，需求和代码提交、分支之间能够进行关联。

运用全新的研发流程管理产品 Compass ，研发负责人可以对项目的工作流进行约束和自动化配置。例如需求变更状态时，检查对应的代码分支是否通过了自动化测试，开发者提交代码时需要遵循代码分支的命名规则等。

从工程管理视角看。CODING 涵盖了一套健壮的可视化流水线能力，包含持续集成、制品管理、持续部署等。持续集成的目的是实现更快的发布频次，运用「测试左移」的理念，结合代码扫描和自动化测试的能力，研发团队可以实现每天几十次的可靠集成与发布。集成所产生的编译结果将被纳入到制品管理之中，便于版本索引和加速测试和发布过程。制品扫描功能可以在不访问源代码的情况下，通过扫描二进制组件及其元数据，找寻组件中存在的漏洞。

持续部署能以自动化方式，频繁而且持续性的将软件部署到生产环境，使软件产品能够快速的交付使用。持续部署模块中，涵盖了测试、生产环境的发布目标环境信息。根据发布计划，可以应用蓝绿发布、金丝雀发布等多种发布策略推送制品至线上环境。到这里，工程实现了从需求到发布的 DevOps 完整闭环，全环节的价值流、代码流、制品流上下文在 CODING 平台中清晰、透明。

缺乏对人力资源的管理是过去散装研发管理工具的弊端。为了适应不同规模研发团队的管理需要，结合本土研发团队的管理特点。CODING 在跨团队、跨项目的横向侧提供了一系列团队管理工具，深度发挥了一站式产品高数据集成度的优势。

同时 CODING 包含了一个全新的「知识管理」模块，知识空间可以挂载在项目之下或单独使用。可以使用 Markdown 或富文本的形式编写和组织产品文档，基于块集元素的文档结构可以让团队成员在文档中自由嵌入例如需求卡片、思维导图、表格等多种内容结构。

通过「团队目标」功能，可以在组织层运用 OKR 管理方法，CODING 中可设置公司级、部门级与个人级的目标视图，关键结果可与需求进行关联实现执行分解和跟踪。如果团队成员都能够通过目标管理机制，从「要我做」转变为「我要做」，毫无疑问这将会是一个充满机动性与高效能的团队。

团队视角的管理是今天更多成熟组织关心的产品能力，CODING 在平台层已经涵盖了组织架构管理、集中权限管理等等，我们期待能够吸纳和传递更多卓越团队的管理实践。在稍后的环节里，我也将为大家介绍今天发布的两款新的团队级管理工具：研发度量和工作负载。

平台为人服务

话说回来，我们相信工具和平台是以人为本，为人服务的。工程师的极客精神和惯性信念是「自己动手，丰衣足食」，技术决策者也面临自建工具，和公有云平台之间的选择。那么为什么 SaaS 平台好于自建工具呢？我在这里打一个比方。自建工具与云上平台的关系，好比宠物与牲畜的关系。宠物，例如猫、狗，是娇贵的，需要持续付出成本与精力细心养护，人为宠物提供关爱与服务，以换取情绪价值；牲畜，例如牛、马，则是人类经过演化筛选的生产工具，天生是为人类提供生产价值的。

仍然有相当多研发团队为自建工具无意识的、不计成本的投入，少则投入几人，多则投入几十人成立工程团队，进行学习、搭建、维保和开发工作。这种宠物思维忽略了工具的生产为主的天性，也忽略了云技术的演进和社会分工能带来的巨大效率优势。值得一提的是，CODING 拥有了可能是国内 DevOps 领域最大规模的高水平研发团队，团队成员有着丰富的技术、工程和用户体验积累。我们建议，技术决策者可以从运维成本、配置成本、易用性、权限管理、度量与规范等各个角度去做一次理性选择：是自建工具更好，还是一站式平台更好。

此外 CODING 还拥有以下优势：

• 可适应从瀑布式到敏捷的渐进式工作流过渡，支持从已有多种系统中进行数据迁移；
• ChatOps 生态与微信小程序、企业微信、钉钉等 IM 能够互通，平台开放了丰富的 API 供二次开发使用；
• 标准版免费，高级版本按人数规模订阅；
• 充分利用了腾讯云资源以及 CDN 加速能力，提供速度和可用性上的优势；
• 免费与付费用户均提供可用性保障和服务支持。 ……

研发度量 & 工作负载新品解读

希望以上我的介绍，能让大家对一站式研发管理平台的理念和优势，有一个概览性的认识。现在为大家带来我们一系列的新产品，首先是研发度量。

德鲁克曾写道：“你如果无法度量它，就无法管理它。”这句话充分体现了度量在管理中的份量。对于注重研发效能的团队来说，我们渴望去测量和提升创造价值的速度，我们渴望通过度量去及时发现和改进质量问题，渴望能够比较组织内团队之间，甚至与行业内其它团队之间的工程效能，我们渴望有这样一把好用的尺子。然而，度量确实在许多研发团队的实践中是一个复杂的问题。我们见过许多团队从使用 Excel 去归集各处的报表，到搭建基于 SQL 查询或更复杂的数据仓库的基础设施。度量涉及到数据源的规整和清洗，涉及到指标的选取和基线的设定，涉及到对指标的有效解读和改进措施的判断。

CODING 利用一站式平台的数据集成优势，给注重效能改进的研发团队带来了可对全平台产生的数据进行多维度分析的研发度量工具。它的特征是开箱即用、高度可视化、自带效能指标体系模型，促进 DevOps 工程透明化。

研发度量覆盖从需求、代码、制品到发布的全链路数据源，可以自由组织个人视图和团队视图，度量视图带有健全的权限管理机制。使用度量查询器，团队负责人、PMO 可以定制复杂的可视化报表，数据可以下钻，可以导出，也可以共享投屏。研发团队其实没有必要去进行过度的指标设计，通过少数指标（一般不超过 20 个）基本能覆盖团队和项目主要维度的统计，更重要的是抓住关键指标的有效改进措施。

基于 DevOps 成熟度模型，这里我们选取了一些参考性指标和基线。例如需求交付周期、缺陷修复时长、自动化测试率等等。以往可能覆盖这些关键指标有相当多的工序要配置，尤其是对于中大型组织，覆盖较多团队、较多项目，甚至交叉团队、交叉项目的情景。

CODING 研发度量将预设基于成熟度模型的效能视图和质量视图，视图内有预定义好的指标设计，通过一键开启这项功能可以便捷的应用到你的团队当中，无需进行复杂的配置即可直接使用。随着使用深度增加，研发团队可以自定义适合自己的公式化指标。

最后我为大家带来的是工作负载，这是 CODING 提供的一项全新的人力资源管理工具。这款工具定义了一个工作饱和度的指标，能以直观、可视化的方式度量一组研发人员工作并行的的情况。尤其适用于计划驱动型团队的需求排版，识别闲置开发资源和过度饱和的开发资源。这款工具现在已经上线，可以在 CODING 线上版本中直接体验和使用。

以上就是我今天为大家带来的内容。如下图所示，感谢过去一年这些团队与我们共创产品。CODING 希望通过打造一站式研发平台，让人们相信数字化软件工厂是可以实现的。我邀请您加入，和其他团队一道，迈入高效能研发的数字化工作体验。

点击观看 CIF 峰会回放

本文为 CODING 研发总监 王振威，在腾讯云 CIF 工程效能峰会上所做的分享。

文末可前往峰会官网，观看回放并下载 PPT 。

大家好，我是王振威，CODING 研发总监。非常高兴能在这里给大家分享过去一段时间 CODING 的产品思考和升级，并为大家介绍 CODING 战略升级后的重磅新品。

首先，我们来看一下 CODING 的全景产品矩阵。这里标识出了过去一年里，CODING 做出的重要产品更新，其中有大量产品是全新推出的，也对一些现存的产品进行了升级，这张图几乎囊括了 CODING 现存的所有重要产品模块和功能。我们聚焦于软件研发阶段的管理，从团队协同到项目计划，从代码协作到构建集成，从测试管理到制品管理和部署上线，在部署上线后就完整对接了云基础设施 IaaS 和 PaaS ，这样就可以理解为，如果客户使用了 CODING 并且使用了云，就可以形成一套全链路的云原生体系。

在过去一年里，CODING 坚持以客户为中心，朝着让开发更简单的方向，面向云原生的未来产业大规模增强了既有的产品，并打造了一些非常激动人心的新品。我将在接下来重点介绍一些其中的新品和重要的产品升级。

项目协同 2.0 —— 有条不紊

我们都希望所有的事情进展，都是按照有序的节奏来进行。那么我们知道，软件开发工作是高度复杂的，这需要各种不同类型的专业人员的协同，例如：产品经理、后端工程师、测试工程师、前端工程师、敏捷教练、UI 设计师等等，不同的公司也有不同的角色设置。但如果仅仅只是简单地把这些人员凑在一起，缺乏一套确定的工作交流机制，我想他们的协作将陷入一团乱麻。

CODING 面向开发者团队提供的项目协同，一直都是我们产品的重中之重，项目协同产品团队刚刚完成了产品的 2.0 重大升级，希望让协作有条不紊。这里我将简要介绍几个项目协同 2.0 的重要特性。

第一是新增自定义协作模式。我们都知道，项目管理软件铺天盖地，可能有非常多的选择，但传统的项目管理软件往往都是基于某一种特定的管理理论，比方说敏捷或是瀑布，针对某一种具体场景来深入设计。事实上这种设计方式明显缺乏灵活性，对于大多数企业而言，企业内部的事项往往无法被精准的归类为「需求」、「任务」或者「缺陷」。

例如对于一个金融企业来说，他可能需要管理「风险」这一概念；而对于初创企业来说，新的产品还没有完备的产品需求，他可能需要一个概念叫做「构想」或者「脑洞」；对于一个软件企业来说，可能专门有一类任务叫做「交付」或者「实施」。那么你可以看到，事实上不同的企业没有办法使用传统的项目管理软件里的概念，来表达自己的业务模型。

不论是「风险」、「构想」还是「交付」，项目协同 2.0 都可以非常灵活的应对，使用自定义协作模式不仅可以跳出敏捷和瀑布协作模型的限制，更可以自由依据企业的实际业务来具象化工作项的概念。风险这样的自定义概念不仅可以设置文本、数字、单选框等常规属性类型，项目协同 2.0 还支持非常多的内部信息关联。例如你可以设置一个脑洞的提出人为项目成员中的一个成员，甚至可以设置一个脑洞的预计实现周期为哪几个迭代。这些自定义的概念和自定义的属性，再配合自定义的流程，一套专属于企业自己的项目协作流程就完整建立起来了。

其中事项的状态也可以进行自定义，比如企业可以根据自身的情况，为不同类型的工作项设置如产品评审阶段、设计评审阶段、架构评审阶段、开发中、已测试、待上线、已发布等任何状态。如果新定义一个概念为「风险」，那么可以为「风险」设置：已发现、已识别、评估中、处理中、已消除等等不同的状态。并且这些概念在不同状态间转移时，我们可以定义其转移规则，设置只有某类成员可转换某个状态，例如只有测试人员可以把「开发中」的任务转移到「已测试」状态，这给企业事项流转流程带来了非常大的灵活性和便利性。

第二个是项目协同 2.0 带来的全新的项目集功能。项目集是用于管理在项目层级之外的跨项目事项进展。如图所示，项目集里的需求可以分解到不同团队的不同项目里，并可以在项目集视图进行集中管理和追踪。

下图是一幅经典的项目集页面信息，可以清楚的看到与项目不同，项目集有明确的时间期限，会设置若干个里程碑，整个项目集的里程进度在这里一目了然。此项目集里的任务在不同项目里的进度也记录的非常清楚。从项目集的推动者角度来看，如此透明的信息和明确的时间进度规划，可以高效推进跨团队的协作，有效解决企业部门墙问题。

时间有限，项目协同 2.0 新升级的特性就介绍到这里， 其他方面的功能和体验这里就不再一一列举。我们相信，高度灵活的属性和流程配置，清晰直观的信息展示，规则透明的流转设定，可以让协同有条不紊。项目协同 2.0 的全部功能特性已经可以在 CODING 公有云（ coding.net ）上体验，有私有化诉求的客户和合作伙伴可以与我们联系。

持续部署 2.0 —— 得心应手

服务器软件的发布从来都是一个非常困难且复杂的问题，针对这个问题行业内有非常多的做法，从我们的角度来思考，这个过程其实是衔接 DevOps 中 Dev 和 Ops 的关键环节。但事实上开发者和运维者的关注点是有差异的，开发者要快速交付，而运维者更关注稳定可靠。DevOps 其实难以调和这种矛盾，但通过重塑职责，让运维者专注于运行设施运维，而让开发者承担业务运维；让开发者权责合一，有权发布并查看目标环境的程序以及他的关键信息，并且让开发者承担起对应业务的稳定性责任。做到这样，发布才能真正得心应手。

CODING 持续部署 2.0 正是围绕着这一目标完成了全方位升级，首当其冲的是应用控制台。把开发当做左侧，运维当做右侧来看，那么我们希望实现业务运维的权力和责任完整转移到开发身上，也就是运维左移。开发人员与运维人员的关注点不同，开发人员是应用思维，运维人员是资源思维，那么要做一个支撑开发人员全面接管应用业务运维的功能，就必须以应用为中心出发。

在应用控制台，对应的开发团队可以非常方便地看到关注应用的发布历史、环境列表、监控状态和对应的日志记录。开发人员不再需要去找运维人员查询日志，也不再需要借助运维人员的帮助才能增加一条条告警规则，真正实现了让运维专注于资源设施，而开发者专注于应用。

开发测试完毕的软件需要发布才能真正为用户提供服务，发布阶段的风险也随之而来。虽说绝大多数的发布都是以程序本身的版本升级为主，但实际情况是，大量的发布过程还夹杂着不可控的数据库变更和配置项变更，这种情况往往被大量忽视。过去的持续部署，几乎所有的软件和实施团队都只关注于应用程序本身的变更，这导致实际的发布场景还是需要大量的人工介入。CODING 持续部署 2.0 提出了多维度发布概念，能将程序、数据库等外部服务、配置项等等的相关发布整合成有机整体，全面接管发布过程，真正实现发布过程全自动化。

另外一项重要的特性是，我们实现了 GitOps 理念。GitOps 是近两年非常流行的一种运维实践，因部署工作属于运维的一部分，自然 GitOps 也能解决部署的问题。GitOps 通过 Infrastructure as Code （简称 IaC ）为基础，IaC 把目标环境的基础设施和程序的状态都描述为代码，并存储于 Git 仓库中。在这种情况下，对目标环境的变更不再是由运维直接操作目标环境，而是通过修改 Git 仓库中的代码，再由 GitOps 体系完成代码与目标环境的自动同步。基于 Kubernetes 的应用可以非常方便的实践 GitOps ，因为 Kubernetes 本身就设计为支持声明式定义和终态控制，再配合 YAML 文件定义的 Git 仓库，发布变得得心应手。

CODING 当前已经提供了完备的实践 GitOps 的能力，用 CODING 代码仓库管理 IaC 源码文件，用 CODING 合并请求审查环境变更，由 CODING 持续部署完成源码与环境同步。

CODING 持续部署 2.0 已经可以接受早期用户的试用申请，可进入 CIF 重磅发布页了解并体验新品。

Nocalhost —— 化繁就简

正如前面讲过的一样，服务器软件的发布是复杂的，云原生这一解决服务器软件架构问题的概念，在当下阶段也是相当复杂的。这种复杂性不仅仅体现在基础设施和运维工作上，它也传递到了开发编码阶段。微服务架构的应用经常由几十上百个微服务组成，这些微服务在程序逻辑和维护的人员团队上都分工明确。但如此松散的组织，给开发编码自测带来了巨大的挑战。

CODING 于 2020 年底推出了开源云原生开发环境 Nocalhost。我们希望在云原生时代，开发者可以让云原生微服务编码体验像单机应用一样原始而又纯粹。云下的微服务开发体验是糟糕的，开发者不能也不愿把整套微服务运行起来，既然没有一个完整的开发测试环境，也就无法方便地进行自测和调试；如果运行全部微服务，则需要消耗大量的资源，且难以维护；本地化的运行与实际的容器环境差异过大，往往会导致后续问题的爆发。Nocalhost 此次重大升级，从调试、环境准备等方面进一步简化了云原生开发编码的复杂性，让编码化繁就简。

使用过 Nocalhost 的开发者都知道，当前开发的微服务是运行在远端容器集群里的。这在某种程度上极大的保障了开发自测环境与最终目标环境的一致性，也极大的节约了本机计算资源。但是在这种情况下，想要便捷调试运行在远端容器的进程，并不是一件容易的事情：源码在本地电脑，进程却在远端容器中，想要调试必须进行一系列复杂的网络打通和 IDE 配置。Nocalhost 此次升级新增了一键调试功能，开发者只需要在对应的微服务上点击调试，等待几秒钟，IDE 就会进入调试模式。

如下图所示，左边是目标网页的运行效果，右边是微服务的源码。开发者只需要在对应的代码行设置断点，并去网页端触发请求，当断点到达时，就可以自由的控制语句执行和变量计算等调试过程。所有事情都由 Nocalhost 完整解决。

开发体验中另一个让开发者痛苦的事情，就是等待服务启动的过程。比如写完一段代码，点击重启，等待启动完毕，才能刷新页面看到结果。 重启过程对于一些服务来说可能是以分钟计量的，这时你突然发现自己写错了一个字母，需要再重启一下等待几分钟才能看到结果，此时你的内心可能是崩溃的。

其实不同的语言和框架都提供了实时热加载的能力，但本地源码与云上容器里的进程天各一方，使得这些语言和框架提供的实时热加载能力，大多数情况下都无法使用。Nocalhost 再次化繁为简，免去复杂的配置和原理理解，让实时热加载真切地增强编码体验。开发者在 Nocalhost 中找到对应的服务，右键点击远程启动，然后等待启动完毕，仅需一次，之后就可以愉快写代码了。开发者唯一要做的就是写代码，并保存文件，然后刷新页面看结果就行了。

在规模巨大的微服务架构应用中，开发阶段存在着两个难以调和的矛盾。要想让开发者开心地编码，那么最好给每位开发者都提供一整套完整的微服务架构应用开发环境，而这非常浪费计算资源，成本也居高不下。要想节省计算资源，则只能想办法提供若干套固定的开发测试环境，给开发者共享使用，而当多个人在一个环境里同时开发、调试、测试会造成环境的混乱，开发者的开发自测节奏会被严重干扰，最终效率大为下降。

Nocalhost 此次重大升级实现了构建在基础环境之上的逻辑环境，环境里的微服务组件通过逻辑划分组成虚拟环境，既节省资源，又能让不同的开发者之间相互隔离。如下图所示，假设某个应用是由 ABCDE 五个微服务组成。我们运行这些微服务，并保持其功能和版本的稳定，设置为基础空间。如果有个开发者希望开发 A 服务，而他并不关心 BCDE 四个服务，那么只需要给他一个逻辑空间，也就是一个专属的开发空间，这个空间里只包含用于开发测试的 A1 服务，并复用基础空间的 BCDE 即可；另一个开发者也需要开发 A 服务时，可以给他创建一个 A2 服务，并跟其他的 BCDE 一起组成一个专属的开发空间；另一个开发者或小组需要开发 C 和 D 两个服务，那么只要共享 ABE 就可以。在这样的节奏下，每个开发者都能拥有完备的五个微服务，而不用每人都实际运行一整套服务。上述这套机制的原理是复杂的，实现也不容易，但 Nocalhost 化繁为简，只需要用户指定基础环境，并设定开发空间中需要用的微服务组件，即可搞定一切。

在下图可以看到，正常的流量被标记为蓝色，会被基础空间的服务处理并返回调用者。而专属于开发者（小明）的流量会被标记为绿色，传输到小明专属的开发空间，处理完毕后再返回给调用者。这个染色和流量调度是借助于 Tracing 和 Service Mesh 实现的，但使用者不需要了解细节，直接设置就可以使用。

Nocalhost 是完全开源的产品，并计划于今年捐献给知名开源基金会，以促进行业整体发展。上述介绍的功能都可以在 Nocalhost 官网（ nocalhost.dev ）查看对应的使用文档。

研发度量 —— 清晰了然

我们所处的世界正在经历巨大的数字化浪潮，从工业到农业，从科研到生产，从消费到娱乐，以计算机和软件为核心的技术正在用数据度量整个世界。然而对于软件本身的生产过程来说，数字化程度反而不高。这体现在软件生产过程不透明，阶段进度无法量化，很难用数字来归因成败，难以实施瓶颈分析。软件开发是一项工程，成熟的工程不该是现在这个样子，我们认为成熟的工程应该是可度量、可量化、可追溯、可分析的，软件开发过程本身的数据不够清晰，就会导致上述问题，最终难以管理。

CODING 全新推出研发度量产品，让研发数据清晰了然。

CODING 专注于软件研发过程的管理和效率提升，要想让研发过程的数据清晰了然，就必须全链路收集数据。我们从工作事项、开发编码、测试验证、构建集成、发布部署五个阶段把关键数据指标进行归类与收集，并依据大量的行业调研和案例分析，设计了关键数据项。全链路的关键项数据捕捉确保整个度量体系能掌握要点，同时高度开放的可扩展性，确保了单项的深度延伸。

化繁就简一直都是 CODING 的重要特性。在五大阶段多达几十上百项数据，又区分了项目，时间窗口，人员等多个维度，这些数据非常繁杂，但研发度量可以做到极简配置，大多数数据都可以以推荐方式一键生成数据视图。如下图所示，针对事项计划、人力排版等问题，研发度量也给出了专门的面向人员的人力饱和度视图；在多人合作，多任务并行，常规任务与突发任务混杂的情况下，可以一目了然地了解到每一个人员的工作安排计划。而这项能力的构建必须要求全面的数据收集。

我们通过大量的数据和案例分析，总结了一套研发过程数字化深度，和团队研发效能的成熟度模型，这套模型直接内置到了 CODING 研发度量内部。对于使用者来说，关注这些重点指标就可以了解自身的效能成熟度状况，取长补短，有针对性地优化自身流程和能力，最终取得事半功倍的效果。

当前，研发度量已经全面上线 CODING 公有云，用户可以即刻进行体验。有私有化诉求的客户和合作伙伴可以与我们联系。

Compass —— 行云流水

经过分析研发度量收集的大量研发过程数据后，我们一直在思考软件工程的终极形态是什么？我们曾经拿软件工程和建筑工程类比，又拿软件工程与智能制造类比，还拿软件工程与科研类比，还广泛接纳《编程之美》这类把编程视作艺术的思维。我们的结论是它们有点像，又不完全一样。

终究，软件工程仍然是一项工程，应该具备工程的关键特征，如流程，进度，质量，风险等。然后在工程基础上叠加软件的特性，如并行协作、迭代更新等。

每一个软件开发团队都有自己的特殊情况，但他们都希望团队有规范流程，协作顺畅。CODING 全新推出了 Compass，把我们对于软件工程的深入思考、流程规范的最佳实践、价值交付的核心思想完全内置到了这个产品中。我们相信，软件工程是需要规则规范的，规则规范的设定不仅仅是在单点上体现最优的状态，从全局角度来看也一定是高效的。Compass 为软件工程指引方向，让研发行云流水。

作为我们对软件工程终极思考的答案，我们为这一横跨全链路的规范执行方式和价值交付流，取名为：Compass 。Compass 是罗盘或指南针的意思，我们希望从事软件研发的成员可以被 Compass 指明前进的方向，而不是靠同事或者领导来安排工作。一个精密运转的软件研发过程，应该由系统依据规范和流程来告诉人们他们该干什么，而不是让人盲目的去寻找工作的方向。

流程是 Compass 的核心。对于一个研发团队来说，要想设立高效的研发规范，首当其冲的任务，是确认自己团队以什么样的流程开发交付软件。Compass 的流程引擎高度灵活，可编排从项目的工作项，到代码分支合并规则，到源码质量规范，到构建测试红线，到制品存储结构，最后延续到发布交付流程。

可以说 Compass 设立了一个研发全链路的流程定义，这个流程一旦定义之后，便可非常方便地强制研发团队内的成员，遵照流程来执行工作内容，进而符合规范。我们相信明确的流程会给到明确的预期，也将产生结构化的精准度量数据。对于研发团队来说，其中的每一个角色都会得到一份 Todo List ，这份 Todo List 是 Compass 根据流程的执行节点自动计算得出的，每一个成员只需要不断去完成 Todo List 中的事项，整个流程就会行云流水般自动推进。

例如一个开发者早上起来打开电脑，看到 Compass 列出的 Todo List 中清晰写明，他有三项编码任务，两项代码评审任务，一个发布审批确认待处理。他完全可以依据系统信息了解到每条任务的上游基本状况，也可以根据流程推算了解到任务完成时间对下游的影响。如此清晰的工作指引，就好像时时刻刻都有一个罗盘在指引着工作方向，所有的这些事情，都由系统全自动驱动人往前走。在这样的基础上，可以理解为，我们把软件的生产过程近乎转化成了制造业的车间流水线，流水线的工人唯一要做的事情，就是等待上一个步骤的产出物并进行自己的加工，最终交付给下游进行进一步加工。

由于流程驱动着人推进事务进展，每一个阶段的启动和完毕都被系统记录在案，全部数据会统一上报到研发度量体系内部，管理人员可以很方便地进行瓶颈分析。例如发现过去一个月总是在测试这一环节消耗太多时间，则可以仔细分析，看是人力不够，还是测试工具落后，亦或是人员懈怠。

结构化、流程化、数字化、规范化的研发过程产生了大量实际数据，而这些数据又反过来用于优化研发规则和流程的设定，形成双向正循环，使得流程和规范本身也像产品一样迭代起来，企业的研发效能才能真正步步为营，逐渐提高。从这个角度上说，Compass 把敏捷迭代的思想从软件的产品研发延伸到了管理制度。

由于每一项具体的事项都有具体的规范准则，这可以非常直观便捷地约束操作者的行为，这为 CTO 、CIO 、技术委员会、架构支持部门等核心技术组织，在全企业贯彻技术实践提供了强有力的保障。例如我们都知道 Git 仓库的分支模型场景比较多，而 Compass 单单针对分支合并这一场景，就可以细致化地设定分支命名规则，合并流程，合并权限，事前检查，事后通知等等。诸如此类，我们希望让研发过程中的所有关键环节都有章可循，最终实现按图索骥的效果，让 CTO 的技术管理从口头上的谆谆教诲升级为系统的约束准则。

Compass 是 CODING 在软件工程上思考的终极答案，我们希望把软件研发打造成行云流水的工厂流水线。最终效果是机器推着人往前走，而不是人推着机器往前走。Compass 在 CODING 体系内是凌驾于其他全部产品模块之上的，是一个全局性的、非常庞大的产品体系。当前 Compass 最核心的流程引擎已经打造完毕，大家可以访问 CIF 大会重磅发布页了解 Compass 的更多功能特性和适用场景，并申请试用。

还有更多……

CODING 过去一年产品迭代硕果累累，由于时间有限不再一一赘述，这里列举一些关键更新——

1. CODING 即将推出腾讯自主研发的 CI 引擎，以解决长期受制于 Jenkins 带来的不便。这款引擎已经在腾讯集团内部使用多年，久经验证，功能强大，使用灵活。新的引擎将配合腾讯云安全容器实现更快的调度，更灵活的编排能力。CODING 新的 CI 引擎当前已经可以接受早期用户的试用，可进入 CIF 重磅发布页了解和体验新品。

2. CODING 于 2020 年发布了独立部署的制品库： WePack。当前 WePack 充分融合了腾讯集团的安全能力，与业界知名安全团队云鼎安全实验室和科恩安全实验室强强联合，大幅增强了 WePack 在制品扫描，安全加固等方面的能力。WePack 不仅可以使用行业公开的漏洞库扫描制品，比如大家耳熟能详的 NVD 、CNVD 等，还拥有腾讯安全团队 20 多年的能力积累，自主可控和深度安全的能力在过去一年获得了众多金融客户的认可。WePack 可以便捷私有部署在客户的环境内，更多的信息可以进入 CIF 重磅发布页了解体验新品。

3. CODING 基于 Git 代码库增强了基于目录的读写权限控制。从 SVN 迁移到 Git 的团队往往都在抱怨 Git 无法在目录层面上控制读取权限，了解过 Git 原理的人都知道，Git 是基于整个代码库哈希的算法来进行版本校验的，如果检出的文件不齐全，将无法完成校验，这个基本原理导致 Git 本身无法实现按目录的读取权限控制。CODING 从原理出发，对 Git 进行了扩展，在兼容现存的 Git 用法且不侵入 Git 的基础上，通过扩展 Git 实现了按目录的权限控制。这项能力当前已经可以接受早期用户的试用，可联系我们申请试用。

4. Cloud Studio 团队大幅改进了云上 IDE Cloud Studio 的体验。Cloud Studio 现在变得更方便、更快捷，同时便捷程度已经超越本地 IDE 。开发者不需要安装任何软件，只需要打开浏览器，登入自己的账号就可以开始编程。从打开一个云上的工作空间开始，到工作空间完整可用仅需要 3 秒便可加载完成。新版 Cloud Studio 目前已全面上线，可前往官网（ cloudstudio.net ）注册使用，如有私有化部署需求，可与我们联系。

CODING 希望打造全链条的云原生开发体系，在此由衷感谢客户、合作伙伴、同行给予的支持和帮助。云原生开发体系当前还很不完备，CODING 要走的路还有很长，我们期待未来全面的云原生时代到来后，开发更简单！

点击观看 CIF 峰会回放，深入体验 CODING 新品！

文章来源于 Jenkins ，作者 CDF 本地化 SIG

CDF 首届本土化 Meetup

持续交付基金会（ CDF ）隶属于 Linux 基金会。自 CDF 中文本土化 SIG 成立以来，我们围绕 CDF 做了很多事情，诸如 CDF 托管项目的一些使用视频录制（例如 ArgoCD ）、开源人物访谈以及此次的 CDF 首届本土化 Meetup 举办。关于 CDF 中文本土化 SIG 的成立可以查看公众号文章 CDF Chinese Localization SIG；关于此次活动的背景可以查看公众号文章 CDF 首届本土化 Meetup 议题征集通道正式开启！

活动详情

• 时间：11 月 13 日 13:00 - 17:00
• 活动地点：上海市黄浦区南京西路 399 号上海明天广场 JW 万豪酒店 5 楼会议室 3-4
• 人数规模：50 人左右（方便更多的参会人员能够参与交流分享）
• 活动以线下分享 + 线上直播的方式举行

活动赞助

• 极狐（ GitLab ）将作为此次活动的场地赞助商
• 图灵教育以及 Spinnaker 实战的作者，CODING Nocalhost 研发负责人王炜将作为此次活动的书籍赞助（共 10 本持续交付的书籍，中奖几率大）

活动亮点

• 此次活动是国内关于 CDF 的首次线下 Meetup
• Linux 基金会亚太区负责人 & CDF TOC 主席将发表演讲
• 将有高校学生参与此次分享，新增一个窗口，让更多的人了解高校
• 关于持续交付的实践分享 + 吐槽大会

活动流程

活动报名

为了保证此次活动的质量，也为了能让更多的现场人员参与互动，所以此次活动人数会受限制。报名审核后方可参会，欢迎感兴趣的小伙伴扫描上方海报二维码踊跃报名。

本文为 CODING 创始人兼 CEO 张海龙在腾讯云 CIF 工程效能峰会上所做的分享。

文末可前往峰会官网，观看回放并下载 PPT 。

大家上午好，很高兴能有机会与大家分享 CODING 最近的一些新动作。今天主要分享的内容是 CODING 的战略升级和新产品介绍。在讲整个战略升级之前，我们先来讲一讲“为什么要做云原生时代的标准化工具”。大家都知道 CODING 一直在做开发者相关的工具，从代码托管开始，后来又做了 CI/CD 、项目管理、制品库等等一系列工具。那么为什么我们认为在这个时代做这些工具会有更高的价值？

首先 CODING 在这个行业耕耘了很多年，我们发现一个对社会资源可能造成浪费的现象：每家公司往往都有自己的开发工具团队，并且做的工作大同小异。比如腾讯、美团这种大型企业，或者包括百果园（零售）、更美（医美）、中手游（游戏）等等，这些企业都有一个或大或小的开发工具团队，基本占到研发人员的 1% - 5% 不等。对于一家企业来说，这部分投入并不大，但对于整个行业或者整个社会来讲，累计起来的投入也很客观。

这些团队做的工作，基本上是把一些现成的单点工具串联起来，比如 Jira 、GitLab 、Jenkins 、JFrog ，包括监控的 Prometheus 等等。将这些工具串联，再加上一些上层的定制化开发，就是这些团队的工作。每个企业都在做这样的工作，其实造成了很大的重复浪费。

通过这一现象，我们看到了优化整个行业效率的机会。那么为什么这件事在当下有机会实现，则是因为基础设施发生了很大的变化——云原生带来了基础设施统一的可能性。

以前构建一个应用时，很多基础设施，包括操作系统、数据库、缓存、网关等等，都是每个企业团队自行搭建的。无论是自行开发，还是利用开源的工具去搭建，都存在明显的非标性，不同团队做的应用都不一样。在云时代，包括腾讯云在内的云厂商，提供了非常标准化且高性能的基础设施工具，把网关、数据库等全部纳入进去。作为云的用户，企业在开发应用时，就不用再去重复建设这些工具，那么底层的基础设施就有统一的可能。基础设施的统一带来了架构上的统一，从而有可能带来整个开发工具链、开发模式上的统一。这是我们看到的一个很大的趋势上的变化。

另一方面，我们看到软件工程经历了将近 60 年的发展，发展过程也是由作坊式不断转变为工业化，到现在开始向自动化方向发展。整个社会的信息化与数字化变革，带动了产业互联网的发展，对软件开发的需求迅速增长，也催化了软件工程化的进程。软件工程化一定会对标准化工具提出更高的要求，这也是整个行业的需求。

此外，标准化的统一和数字化带来的开发需求，也带来了软件开发在效率上的更高追求。从效率的角度来讲，我们认为分为两种：单点效率和团队效率。单点效率是指一位开发者个人用的工具如何提高个人的编码调试效率。现在大家更关注团队效率，比如 DevOps 、敏捷开发，都是团队协作的方法论和相应工具。

上图列出的工具，有些更偏向单点效率，有些更偏向团队效率，中间可能会有一些交叉点，不是 100% 的区分，但大致能分为两个维度。在这个大背景下，我们也对 CODING 的战略进行了升级，希望能够在新的时代创造更高的价值。

大家都知道 CODING 最早是做代码托管，在 14 年成立。后来经过不断演进，引进了非常多的上下游产业链相关工具，包括持续集成、敏捷项目管理、持续部署、制品库等等。我们过去的定位是说要做 DevOps 工具的领跑者，但是基于上文提到的大背景，基于团队效率和单点效率双向的改进，以及云原生时代的标准化，我们现在将战略升级为——云原生时代的研发工具领跑者，不局限于 DevOps。下文将会详细讲解，以及我们的新产品，大家会看到其中差异化的东西。

CODING 战略全新升级

刚才讲到单点效率和团队效率，我们其实是有对应的产品，来服务这两个不同的维度的需求。CODING 作为一个研发管理平台，更多的是着眼于团队效率，所以侧重于协作； Nocalhost 和 Cloud Studio 则更多的是偏向于提高单点效率，即提高单个开发者在开发云原生应用的效率。

再讲讲 CODING 目前的发展状况。我们在开发者领域深耕了很多年，也积累了非常多的客户，现在有两百多万开发者，以及五万多家企业都在使用我们的产品。我们对这些企业做了一些整体调研，发现无论是在降低研发工具的成本，还是在提高产品交付效率，或是在提升整个团队的效能上，都有比较显著的进步。下图列举了在不同行业我们的一些典型客户。总体来讲分为四大类，第一大类是金融，第二类是互联网，第三类是政企，第四类是游戏。这四大类企业对于整个研发工具的诉求会有所不同。

比如金融行业，更多的强调的是安全性和可控性。我们的私有化产品能够很好地服务这些金融行业的客户，他们对一站式的诉求也非常强烈，这是金融行业的特性。互联网行业的客户更多的则是公有云客户，我们的 SaaS 产品能更好地帮助互联网行业实现敏捷迭代、快速交付的需求。关于政企，接下来会展示一个案例，也会有很多数字化转型带来的需求。游戏行业则对大型仓库有速度上的需求，这也是我们的产品出色服务的一个行业。

我们做 To B 的企业服务，也是腾讯当下的价值观，要持续关注社会价值，展现科技向善。我们的产品虽然不是直接去服务 C 端的用户，但是能帮助很多 B 端的企业更好地开发产品，去服务 C 端用户。

比如在疫情期间，大家每天都会用到健康码，通过各种小程序或 App 登记扫码，我们也参与到了整个开发的过程中。比如四川的天府健康通小程序，我们帮助开发团队十天上线了这个小程序，我们用一天时间完成了整个工具链的流水线配置，包括制品的迁移等等；然后又做了一些关于小程序开发跟 TCB 开发的整合工作，能够更好地帮助开发团队去交付小程序相关的应用。这个案例也是众多案例的一个缩影，在政企领域里也有很多类似的需求。

接下来为大家介绍 CODING 与合作伙伴共建生态的计划，也是为了能够创造更多的价值。CODING 的产品定位和服务都是专注于做云原生时代的研发工具，拥有很多合作伙伴。比如在线索和商务这一板块，会与腾讯云、安畅、网商云计算等伙伴合作；在交付实施这一板块，则与安畅、忆享、腾云悦智一起合作，去做客户现场的一些个性化支持，包括后续的持续性维护等等；除此以外，我们发现在开发效能，研发工具领域，对于咨询的需求也很大，所以我们跟整个行业的头部咨询厂商都会有一些合作，比如优普丰、安畅、Thoughtworks 等等，配合工具和实施的落地，帮助团队不仅仅是购入一款工具，而是能更好的导入方法论，带动组织变革。我们希望能够共建研发效能和研发工具的生态，在云原生时代更好地去服务客户。

讲完战略上的变化以及对于行业的理解，第三部分我们来讲一讲 CODING 产品上变动和更新。首先回顾一下 CODING 作为一个一站式 DevOps 平台，我们对它的定位和目前的进展。

高效云上研发工作流

如上图所示，这朵云类似工厂流水线，这也是我们思考很久得出的结论，希望能把云和整个研发工具 SaaS 的关系准确表述出来。最底层是计算、网络、存储，中间是容器、虚拟化等等，往上是一些安全性的内容，包括配置管理、微服务等等。而我们则是在所有这些基础设施上，又做了一层整个研发工具的 SaaS 。这跟云有紧密的关系，但客户可以无缝使用这个产品，不需要去关注底层云的复杂性。这便是我们对于 DevOps 平台，乃至整个云产业的定位。

从功能上讲，我们希望能给客户提供一个高效的云上研发工作流。下图中基本包含了一个企业，从知识管理到项目管理、代码管理，再到构建、测试、制品、上线、用户反馈，直到团队的绩效、OKR ，这整个完整闭环的功能关系图，这也是 CODING 目前能够提供给客户的完整价值。多年来我们一直在完成整个闭环的打造，投入了非常多的研发去完善整个工具链，希望能够给客户提供 Total Solution ，带来一站式体验。

但我们也关注到，有很多客户已经有自己的工具投入和基础设施，他们很多时候需要的只是一个单点产品，并不需要一站式的工具。比如能不能只需要一个制品库，或者只需要一个发布产品。在这样的诉求下，我们也开始重新思考产品的逻辑，所以部分产品也可以单点拿出来，让客户能够集成到自己的研发工具流的系统里。

- WePack -

助力企业渐进式 DevOps 转型

首先来看的就是「制品」。其实在整个中国来讲，对制品的认知相对是比较缓慢的，可能在五年前都很少有人提到这个概念，最近才开始慢慢提及。我们认为开发软件没有制品库，就相当于制造业没有仓库一样，是一件不可想象的事情。

但其实以前很少有团队拥有很正规的制品库，要么就是文件夹、FTP ，甚至在各种通信工具上以传包的形式来管理生产的制品。经过调研，60% 以上的企业基本没有一个完整的制品管理模块；从整个产业来看，也有一些开源工具，但也不是特别完善，国外会有一些工具，但是无法达到自主可控和一些信创的要求。所以针对这一痛点，我们将制品库产品单独拿出来，作为一个独立的制品产品，定位是企业级的制品管理平台：WePack 。它是 CODING DevOps 的一部分，也可以成为客户自有 DevOps 工具链的一部分。

- Orbit -

全新云原生应用交付工具

一般在制品后就是发布环节，也是很多团队研发和运维最紧密的合作与最激烈的矛盾产生的地方。因为 DevOps 就是要让开发能够去完成一部分的应用运维的工作，而不是说应用、系统有了问题就直接先找运维，而这里的矛盾就会很激烈。

在云原生时代，需要逐步把应用的运维左移给开发，但资源的运维还是由传统的运维来做，甚至直接交给云来做。在把应用运维左移给开发的过程中，因为要让开发低门槛地去看到这个应用的状态，去扩缩容，去监控日志报警的各种配置，就势必会对应用运维的工具提出很高的要求。这是一个行业的趋势，也是目前面临的挑战。在这个背景下，我们在今年全新的设计了持续交付的产品，在内部叫做 CD 2.0 ，正式对外推出时，全新命名为：Orbit。大家可以想象一下，这个名字带来的意境 - 轨道，跟我们想要交付的意境和给客户提供的价值，是很类似的。

这张图上展示了产品内的截图，左上角是当前的微服务云原生应用，可以看到微服务的架构是什么样，微服务之间的关系是什么样，有多少个微服务，有多少个数据库的表，我们也可以做数据库表的变更；右上角可以看到应用视角，展示了应用有多少变更没有发布到生产环境，包括之前的发布历史、每次发布都由谁操作、什么时间发布、发布了哪些内容；下面可以看到这个应用部署的环境，有测试环境、预发布环境、生产环境等等，包括每个环境当前部署的是什么版本，现在运行的是什么状态，点进去可以看到每一个环境的监控日志报警都能进行配置。相当于把以前传统的运维做的一部分工作，完整搬到了 Orbit 系统里，开发可以在不去打扰运维的情况下，完成整个应用生命周期的管理，这是我们希望 Orbit 能够交付给开发的价值。

- Compass -

让研发井井有条

除了刚刚讲到的制品库，以及持续的交付应用运维的左移，让开发能够更好地管理自己的应用之外，我们在整个研发过程中也发现了其他痛点。因为每个企业都有自己的研发文化和研发规范，那么这些研发规范如何在团队不断扩大的情况下，落实到每一个团队和每一个人。很多时候是靠宣导、靠人事不断去做公司文化的建设，靠每个团队的小组长人工做反复的检查，这也是很多企业的痛点。另外从更上层的管理视角来看，研发团队做的工作往往是一个黑盒，这是很多老板的一大痛点。

针对这些问题，我们也不断在思考，如何才能把软件工程真正工程化、标准化、规范化。所以我们推出了 Compass ，简单来说就是指南针：我们希望能够在开发过程中给团队一个非常清晰的指南。这个指南是产品化的，而不是一个规章制度，定位是让企业的 DevOps 全流程管控能够透视整个研发流程，而不是黑盒，并且能够对整个研发流程做一些价值流的分析。

如下图所示，这是 Compass 产品页面的一个缩影，我们可以配置整个研发过程，从一个 Idea 到需求的分析与评审，到之后代码的构建、测试用例的编写，再到后面的持续集成与交付，每个环节是怎样的流程，环节上有怎样的规范，比如代码、测试用例的规范，都可以在这里进行配置。当整个研发团队按照配置好的流程运作时，如果不符合规范，就没有办法继续流转下去，这样就可以通过产品的方式来帮助团队遵守规范，真正实现整个研发过程的规范化、自动化与透明化。同时因为规范化，每个环节是谁做的，花费了多少时间，为什么慢了 /快了，都会有记录，可以作为事后分析的基础。

- Cloud Studio -

云的开端

讲完 DevOps ，让我们再来看看云原生时代新的挑战和机会。前文提到 CODING 时已经说过，我们以前定位于 DevOps ，现在的定位是云原生的开发套件，除了 DevOps 以外，我们也看到了在开发工具和开发方式上，存在一些新的机会与亟待解决的问题。首先是 IDE ，其在过去的发展已经非常的成熟，比如桌面端的 IDE ，但是这些 IDE 是不是真的适合用来做云原生应用开发呢？开发环境的配置是不是越来越复杂？是不是需要一个随时随地可以写代码的 IDE ？基于这些思考，我们于 2018 年推出了 Cloud Studio 。

这个产品做了挺多年，今年我们对其做了一个非常大的改版，希望定位是一个真正好用的云原生的 IDE 平台，我们不是要取代本地 IDE。而是说在不同的应用类型上，在开发云原生应用时，可以为开发者提供超越本地 IDE 的流畅、便捷的编码体验。目前 Cloud Studio 支持的语言环境已有二十多种，开发者在上面创建的工作空间有十万多个，每天开发者在 Cloud Studio 平台上的开发时长已经累计超过 120 小时。并且我们做了非常多的开放的工作，包括协同编程，你可以进入其他开发者的工作空间，一起做一些开发、调试工作，这在本地 IDE 很难做到；开放的生态也支持各种插件，Cloud Studio 的启动速度基本上是 3 - 5 秒的秒级启动；并且我们做了非常多的模板以及开发环境的配置方式，对新手也非常友好。

除了开发通用的云端的 IDE 之外，这个技术也希望能够帮助不同的行业去落地不同的解决方案，比如在线课堂可以做编码 Demo ，低代码开发是否需要一个编码环境，招聘笔试等等，包括我们跟腾讯会议也会有一些集成，在开会的过程中如果需要对代码互动，是不是可以有这样的工具来更好地支持这样的场景？我们希望能够帮助更多的行业去更好地协同。

- Nocalhost -

让云原生开发回归原始而又简单

在云原生的开发上，除了 IDE 的问题，我们还发现整个研发测试环境的搭建也存在问题。想象一下，如果你有一个 100 个微服务的应用和一个新入职的员工，你该如何让他上手开发这个应用？要给他一个怎样配置的开发机器，才能够让他把这个应用的开发环境跑起来？整个开发测试过程能不能更高效？我们发现其实很多企业都有这样的痛点，在微服务的应用越来越庞大的时候，很少有企业能够让每一个开发都有自己的开发环境。而共享一个开发环境，相互之间就会有各种各样的影响。所以我们在思考，有没有办法可以像开发单体应用一样，开发一个复杂的云原生应用呢？于是我们推出了——Nocalhost。这个产品是去年年底对外发布的，经过将近一年时间的开发和迭代，现在有很多用户已经用在了自己的开发工作中。

在这里解释一下 Nocalhost 名字的由来。十几年前我们做开发都是用 Localhost 来调试，因为当时不需要网络就能模拟网络情况，实现开发网站的反馈循环。而在云原生时代，已经没有 Localhost ，或者从理论上讲没有本地的，所以是 No localhost ，但是我们仍期望能够达到像本地一样的开发反馈。

如图所示，左图是目前开发云原生应用的流程，如果需要调试，查看改一行代码的效果，需要经过大概六个步骤，从编译到上传制品，甚至需要重启某个微服务或容器，这个反馈循环很慢，至少是分钟级，甚至 5 - 10 分钟。而在 Nocalhost 的机制下，反馈直接降低为三步，并且不需要编译，不需要上传制品，体验上基本能做到跟本地的 Localhost 一样。我们也希望在整个开发体验上完全媲美本地开发，所以我们做了很多工作，包括容器的快速部署、快速启动，一键 Debug ，多人共享的开发环境等等；同时也提供了 Server 端，能够让企业的资源管理人员拥有管理能力，去分配不同研发人员的开发资源，更好的回收以及重复利用开发资源。我们希望 Nocalhost 这个产品能够给云原生应用开发带来全新的体验。

展望未来

最后展望一下未来，在这个领域还有哪些我们目前还没有做，但是认为非常有价值，我们将来会去做的事情。这里例举了三个我们认为比较有价值的行业发展方向。

第一个是 Value Stream。我们谈到交付效率的提升是不是一定代表了业务的成功呢？这个问题很多时候答案是否定的。开发团队觉得做了很多的工作，但是业务侧好像没什么用，这也是很多业务团队和开发团队的矛盾所在。所以不光要提升开发团队的交付效率，如何衡量交付的东西的价值，就是 Value Stream 。那么我们如何衡量这里的价值，到最后交付上线后，整个价值流是否能够管控起来？

第二个是 AI。在这个领域，我们是不是可以开发更多的能力，帮助开发者写出更加完备、高质量的代码，通过 AI 的能力做出辅助开发者 Code Review ，甚至 Coding Assistant 的产品？

第三个是在安全领域。也是目前大家关注的一个重要方向。因为整个云原生里所有东西都上云，对于很多企业来讲，对安全有着巨大的担忧。传统的安全往往是独立的团队在做，跟开发测试是相互分离的，我们认为这种组织结构，或者说工作方式相对来说比较低效，有很多返工或者重复劳动的情况。现在更强调的是 DevSecOps ，就是把安全性融入到整个研发测试环境里，这也是我们值得去关注的一个方向。

那么本次分享的内容就到这里，感谢大家的参与。CODING 一直以来都坚持「让开发更简单」的 Slogan ，在云原生时代，我们也希望能够让云原生开发的研发管理变得越来越简单，谢谢大家。

点击此处链接

观看 CIF 峰会回放并下载会议资料