本文为 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 过去一年产品迭代硕果累累，由于时间有限不再一一赘述，这里列举一些关键更新——
- CODING 即将推出腾讯自主研发的 CI 引擎，以解决长期受制于 Jenkins 带来的不便。这款引擎已经在腾讯集团内部使用多年，久经验证，功能强大，使用灵活。新的引擎将配合腾讯云安全容器实现更快的调度，更灵活的编排能力。CODING 新的 CI 引擎当前已经可以接受早期用户的试用，可进入 CIF 重磅发布页了解和体验新品。
- CODING 于 2020 年发布了独立部署的制品库： WePack。当前 WePack 充分融合了腾讯集团的安全能力，与业界知名安全团队云鼎安全实验室和科恩安全实验室强强联合，大幅增强了 WePack 在制品扫描，安全加固等方面的能力。WePack 不仅可以使用行业公开的漏洞库扫描制品，比如大家耳熟能详的 NVD、CNVD 等，还拥有腾讯安全团队 20 多年的能力积累，自主可控和深度安全的能力在过去一年获得了众多金融客户的认可。WePack 可以便捷私有部署在客户的环境内，更多的信息可以进入 CIF 重磅发布页了解体验新品。
- CODING 基于 Git 代码库增强了基于目录的读写权限控制。从 SVN 迁移到 Git 的团队往往都在抱怨 Git 无法在目录层面上控制读取权限，了解过 Git 原理的人都知道，Git 是基于整个代码库哈希的算法来进行版本校验的，如果检出的文件不齐全，将无法完成校验，这个基本原理导致 Git 本身无法实现按目录的读取权限控制。CODING 从原理出发，对 Git 进行了扩展，在兼容现存的 Git 用法且不侵入 Git 的基础上，通过扩展 Git 实现了按目录的权限控制。这项能力当前已经可以接受早期用户的试用，可联系我们申请试用。
- Cloud Studio 团队大幅改进了云上 IDE Cloud Studio 的体验。Cloud Studio 现在变得更方便、更快捷，同时便捷程度已经超越本地 IDE。开发者不需要安装任何软件，只需要打开浏览器，登入自己的账号就可以开始编程。从打开一个云上的工作空间开始，到工作空间完整可用仅需要 3 秒便可加载完成。新版 Cloud Studio 目前已全面上线，可前往官网（cloudstudio.net）注册使用，如有私有化部署需求，可与我们联系。
CODING 希望打造全链条的云原生开发体系，在此由衷感谢客户、合作伙伴、同行给予的支持和帮助。云原生开发体系当前还很不完备，CODING 要走的路还有很长，我们期待未来全面的云原生时代到来后，开发更简单！
点击观看 CIF 峰会回放，深入体验 CODING 新品！
