CODING —— 云原生时代的研发工具领跑者

[CodingNET]

本文为 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 峰会回放并下载会议资料