首先来看的就是「制品」。其实在整个中国来讲，对制品的认知相对是比较缓慢的，可能在五年前都很少有人提到这个概念，最近才开始慢慢提及。我们认为开发软件没有制品库，就相当于制造业没有仓库一样，是一件不可想象的事情。
但其实以前很少有团队拥有很正规的制品库，要么就是文件夹、FTP，甚至在各种通信工具上以传包的形式来管理生产的制品。经过调研，60% 以上的企业基本没有一个完整的制品管理模块；从整个产业来看，也有一些开源工具，但也不是特别完善，国外会有一些工具，但是无法达到自主可控和一些信创的要求。所以针对这一痛点，我们将制品库产品单独拿出来，作为一个独立的制品产品，定位是企业级的制品管理平台：WePack。它是 CODING DevOps 的一部分，也可以成为客户自有 DevOps 工具链的一部分。
- Orbit - 全新云原生应用交付工具一般在制品后就是发布环节，也是很多团队研发和运维最紧密的合作与最激烈的矛盾产生的地方。因为 DevOps 就是要让开发能够去完成一部分的应用运维的工作，而不是说应用、系统有了问题就直接先找运维，而这里的矛盾就会很激烈。
在云原生时代，需要逐步把应用的运维左移给开发，但资源的运维还是由传统的运维来做，甚至直接交给云来做。在把应用运维左移给开发的过程中，因为要让开发低门槛地去看到这个应用的状态，去扩缩容，去监控日志报警的各种配置，就势必会对应用运维的工具提出很高的要求。这是一个行业的趋势，也是目前面临的挑战。在这个背景下，我们在今年全新的设计了持续交付的产品，在内部叫做 CD 2.0，正式对外推出时，全新命名为：Orbit。大家可以想象一下，这个名字带来的意境 - 轨道，跟我们想要交付的意境和给客户提供的价值，是很类似的。
这张图上展示了产品内的截图，左上角是当前的微服务云原生应用，可以看到微服务的架构是什么样，微服务之间的关系是什么样，有多少个微服务，有多少个数据库的表，我们也可以做数据库表的变更；右上角可以看到应用视角，展示了应用有多少变更没有发布到生产环境，包括之前的发布历史、每次发布都由谁操作、什么时间发布、发布了哪些内容；下面可以看到这个应用部署的环境，有测试环境、预发布环境、生产环境等等，包括每个环境当前部署的是什么版本，现在运行的是什么状态，点进去可以看到每一个环境的监控日志报警都能进行配置。相当于把以前传统的运维做的一部分工作，完整搬到了 Orbit 系统里，开发可以在不去打扰运维的情况下，完成整个应用生命周期的管理，这是我们希望 Orbit 能够交付给开发的价值。
- Compass - 让研发井井有条除了刚刚讲到的制品库，以及持续的交付应用运维的左移，让开发能够更好地管理自己的应用之外，我们在整个研发过程中也发现了其他痛点。因为每个企业都有自己的研发文化和研发规范，那么这些研发规范如何在团队不断扩大的情况下，落实到每一个团队和每一个人。很多时候是靠宣导、靠人事不断去做公司文化的建设，靠每个团队的小组长人工做反复的检查，这也是很多企业的痛点。另外从更上层的管理视角来看，研发团队做的工作往往是一个黑盒，这是很多老板的一大痛点。
针对这些问题，我们也不断在思考，如何才能把软件工程真正工程化、标准化、规范化。所以我们推出了 Compass，简单来说就是指南针：我们希望能够在开发过程中给团队一个非常清晰的指南。这个指南是产品化的，而不是一个规章制度，定位是让企业的 DevOps 全流程管控能够透视整个研发流程，而不是黑盒，并且能够对整个研发流程做一些价值流的分析。
如下图所示，这是 Compass 产品页面的一个缩影，我们可以配置整个研发过程，从一个 Idea 到需求的分析与评审，到之后代码的构建、测试用例的编写，再到后面的持续集成与交付，每个环节是怎样的流程，环节上有怎样的规范，比如代码、测试用例的规范，都可以在这里进行配置。当整个研发团队按照配置好的流程运作时，如果不符合规范，就没有办法继续流转下去，这样就可以通过产品的方式来帮助团队遵守规范，真正实现整个研发过程的规范化、自动化与透明化。同时因为规范化，每个环节是谁做的，花费了多少时间，为什么慢了/快了，都会有记录，可以作为事后分析的基础。
