在数字化浪潮席卷之下，很多传统行业的线上业务急速增长，其业务场景、用户行为都发生了转变，面对敏捷的业务和IT应变需求，如何快速地进行创新实验，提高IT部门的总体运营效率，高效融合开发和运维的能力等一系列问题，已成为企业需要直面的挑战。
2009年以来，DevOps越来越被重视，最开始是为了让开发和运维人员更好地沟通协作，后来逐渐成为打通软件产品交付过程中IT工具链和高效解决团队成员协作沟通问题的有效理念。但DevOps的整体发展是独木不成林的，现在已经有越来越多的技术支撑，微服务架构理念、容器技术等使得DevOps的实施变得更加容易。
我们研发团队从内部产品研发需求出发，将敏捷管理、CI/CD、自动化测试、运营管理、基于SpringCloud的微服务架构、容器编排等相关工具整合为一个PaaS平台，用来支持这些传统企业的数字化转型。
本文主要分析了项目研发团队在开发过程中存在的一些问题，介绍了Choerodon猪齿鱼对此的解决方法，最后解答了应用迁移到Choerodon猪齿鱼平台前的几点疑虑。
主要分为以下几个部分：
一、为什么要使用Choerodon猪齿鱼
- 一般研发项目现状分析
- Choerodon猪齿鱼能做哪些事情？
二、使用Choerodon猪齿鱼之前的疑问
- 编程语言
- 容器化
- 数据库
- 前后端分离
- 微服务
- 移动端支持
- 公有云、混合云
三、总结
为什么要使用Choerodon猪齿鱼
在Choerodon开发团队接触的大部分传统企业中，他们面临着业务创新的需求和压力，同时也面临着无法很好得使用新型技术和方法快速将创意转化为产品的困境，IT团队希望能够利用Agile/DevOps、微服务和容器技术帮助业务进行快速创新，相关的工具非常多，而且工具链条很长，把它们整合应用起来对IT部门来说要求非常高，很多传统的企业并不具备这样的能力。
一般研发项目现状分析
应对易变的需求能力弱
传统的研发项目往往采用瀑布式的开发方式，从立项、需求、设计、开发，测试到最终运营管理，由于市场或者用户的需求经常性发生变化，瀑布式模型的能力比较弱；当然，现在很多项目并不是完全遵循瀑布式的开发方式，在进入运营期当需求变化时，会进行灵活地处理，尤其是持续更新的产品。但这种情况仍缺乏明确的管理策略，更多的是“东补西凑”的“理念”，与敏捷开发还是有所不同。另外，开发人员往往没有书面记录用户的变更需求，可能会导致无法追溯系统软件变更的历史。
缺乏有效的分支管理与版本控制机制
现在越来越多的项目使用Git作为版本控制的工具，通过Git进行分支和Tag管理，大多数情况这个过程都由手工完成，缺乏相应的规范，对于分支和版本号的控制也很随意，出现这样的情况往往是大家对软件交付过程中的软件版本控制不够重视，“只要确保软件是最新的版本即可”，甚至是项目管理的漏洞或者缺陷。
多采用手工或者半自动的部署方式
能否实现自动化和高效地部署是衡量一个团队工作能力的核心标志之一。很多团队采用手工的部署方式，有经验的“老司机”都知道，部署过程往往都是拉取源代码、编译、构建，然后上传到服务器、停止服务器、覆盖代码，最后启动，甚至还有各种系统设置等。每次部署都要经历这个过程，小到一个Bug的修复，大到发布一个大版本。这样直接会导致部署频率较低，进而降低用户需求或者价值的交付频率。
文档缺乏规范管理
文档是项目或者系统的积累和沉淀，包括项目初期的应用蓝图、架构图、分阶段实施计划，以及开发过程中的设计文档、产品功能文档等。在系统开发前期，大家可能对于维护文档还是比较积极的，但是随着产品不断迭代，慢慢大家就会疏于更新文档，导致文档与功能没有办法衔接对照。
缺乏驾驭微服务架构的能力
近几年微服务方兴未艾，尤其是Spring Cloud架构的不断成熟，以及Service Mesh的正式版本发布。由于微服务架构体系涉及到的技术种类非常多，几乎所有的微服务框架不能直接拿来使用，需要投入很大的人力物力进行前期研究、基础系统框架的搭建，这对于很多传统研发团队来说是一件很难的事情。
软硬件资源及交付过程缺乏统一管控
项目组在申请软硬件资源时，缺乏统一管控，各项目组独立部署，无法实现资源有效共享，资源利用率低，浪费严重。另外，在企业内部缺乏统一的支撑平台，每个项目组从开发到上线，基本上都是从零开始，项目交付过程中的沉淀很少，功能模块无法复用，交付过程也缺乏统一，交付周期长，需求响应慢。
以上是Choerodon团队在实践过程中遇到看到的情况，这些情况的存在可能导致研发团队效能的低下，进而影响到用户需求和价值的交付。对于研发团队效能的问题，国际上的一些组织也有相关的研究和定义，DORA 与 Google Cloud 合作发布的 2018 年《DevOps 现状报告》中，将团队根据 DORA 的软件交付效能基准划分为三种类型：高效能、中效能与低效能团队，以团队产出来进行评价，发布频率、变更响应时间、服务恢复时间，以及变更故障率等指标作为划分的参考标准。其划分标准如下：
| 软件交付性能的考量方面 | 精英团队 | 高效能团队 | 中效能团队 | 低效能团队 |
|---|---|---|---|---|
| 部署频率 对于使用的主要应用程序或服务，您的组织部署代码的频率为？ | 按需（一天多次） | 一天一次到一小时一次之间 | 一周一次到一月一次之间 | 一周一次到一月一次之间 |
| 变更响应时间 对于使用的主要应用程序或服务，您更改的前置时间（即，从代码提交到代码在生产中成功运行的时间）为？ | 小于一小时 | 一天到一周之间 | 一周到一月之间 | 一个月到6个月之间 |
| 服务恢复时间 对于使用的主要应用程序或服务，在服务发生事故后（例如，计划外中断，服务损伤）恢复服务通常需要多长时间？ | 小于1小时 | 小于1天 | 小于1天 | 1天到1月之间 |
| 变更故障率 对于使用的主要应用程序或服务，变更有多大比例会导致服务质量下降或随后需要修复（例如，导致服务受损，服务中断，需要修补程序，回滚，修复转发，修补程序）？ | 0-15% | 0-15% | 0-15% | 46%-60% |
对于低效能团队如何改进才能进一步释放潜能，提高团队的效率，DORA 的研究强调技术转型实践至关重要。这些重要的实践包括版本控制，自动化部署，持续集成（CI），基于主干的开发以及松耦合架构。 今年DORA还发现，有助于持续交付（CD）的实践包括：使用监控和可观察性解决方案，持续测试，将数据库更改集成到这样的软件交付流程中，以及关注安全性。
Choerodon猪齿鱼能做哪些事情？
对于一般软件研发类项目，往往包含产品立项、需求分析、应用设计，以及开发 、测试、持续部署与发布，生产运维等。本节将给大家阐述，Choerodon猪齿鱼是如何支持整个研发过程的，以及采用哪些手段来提高软件交付的效率。
产品立项
产品立项是启动产品研发的第一个阶段，最核心的工作是要确定产品的定位，包括目标用户、用户需要、产品名称、产品类型、关键优点、主要竞品、主要不同，以及相关成本投入、团队建设等。此时，可以使用Choerodon猪齿鱼的知识管理功能，方便的记录产品立项阶段的各种输出文档。
需求分析
针对产品立项中的要求（例如用户需要、关键优点）进行需求分析，做好用户访谈等。此时，可以使用Choerodon猪齿鱼的知识管理功能，方便的记录需求分析的各种输出文档。
应用设计
在应用设计阶段，将设计应用蓝图，构建整体系统架构和指定分阶段实施计划等。此时，可以使用Choerodon猪齿鱼的知识管理功能，方便地记录应用设计阶段的各种输出文档。
知识管理是一个轻量级的强大Wiki平台，允许用户根据自己的特定需求自定义Wiki，为企业、IT团队提供方便的项目协作平台和强大的项目内容管理平台，集中式管理产品相关内容等，例如需求收集、架构设计、功能设计、开发规范、命名规范、会议记录、计划安排等。
开发
在项目进入开发阶段，主要进行代码开发、单元测试、分支管理和版本控制等。Choerodon的开发流水线采用Gitlab CI作为持续集成工具，研发团队可以进行代码托管、分支管理、版本控制，有效简化应用开发、缩短应用生命周期，快速迭代。
测试
在测试过程中，团队需要进行测试用例管理、测试计划和执行，以及测试分析等。Choerodon的测试管理为用户提供敏捷化的持续测试工具，包括测试用例管理、测试循环、测试分析等，可以有效地提高软件测试的效率和质量，提高测试的灵活性和可视化水平，最终减少测试时间，让用户将主要精力放到软件功能构建上。
持续部署与发布
持续部署与发布是采用自动化的手段，持续地发布可部署的系统版本，并能够实现方便自动地将系统版本部署到目标环境中。此过程可以借助Choerodon猪齿鱼的部署流水线，方便地管理各种使用Choerodon开发部署的应用服务和资源，包括一键部署、应用启停、状态监控，以及应容器管理等。
生产运维
在生产运维阶段要对系统进行监控等，可以借助Choerndon的运营管理服务，其提供一整套完整的运营管理工具，在软件交付生产的各个环节建立数据收集和度量，监控主要包含开发类指标、服务器日志、应用系统日志和微服务调用链等信息；同时，提供各种分析报告，帮助用户优化IT资源配置。
另外，还有项目管理，项目管理贯穿整个产品的研发周期，借助Choerodon的敏捷管理服务，通过故事地图、用户故事来管理用户故事和发布计划，通过迭代来管理冲刺，最后通过看板来可视化冲刺的执行，让需求、计划、执行一目了然，使整个软件开发流程管理规范化。
并且，Choerodon猪齿鱼提供了一套基于Spring Cloud的微服务开发框架，在其中，做了大量的集成和封装，预置了权限、数据一致性、登录、前端UI 、审批、系统管理、个人中心等诸多模块，可以让用户专注基于业务的实现开发。
迁移之前的疑问
在迁移之前，系统架构师或者软件工程师对Choerodon猪齿鱼可能有一些疑问，例如，Choerodon是否有编程语言限制，对数据库的支持情况怎么样，是否支持公有云等。下面就对于普遍的疑问，一一作答。
编程语言
Choerodon猪齿鱼的核心部分是一个PaaS平台，采用Sping Cloud微服务架构进行开发构建。根据Choerodon猪齿鱼的设计思路，只要是能够容器化的应用都可以使用Choerodon的PaaS平台进行开发和部署，应用本身可以采用不同的编程语言，例如Java、C、C++、C#、Python、Go，以及由编程语言衍生出来的各种开发框架，例如Spring Cloud、Spring、Struts、Mybatis、Django、Flask、ReactJs、AngularJs等（这里不一一列举）。
容器化
Choerodon猪齿鱼一个核心的特性是通过镜像和容器实现“不可变架构”，不可变架构的好处是在程序开发阶段生成的可部署版本是镜像，在镜像中已经做过系统需要的各种设置，可直接通过镜像生成部署容器，不管是开发环境、测试环境还是正式环境，镜像不可变化，即所有环境的系统设置是一致的，避免不一致导致的各种系统问题。
Choerodon的开发流水线结束生成后将生成版本化的镜像和相关的配置文件，在部署阶段，直接将镜像部署到Kubernetes集群中，所以，如果要使用Choerodon猪齿鱼的部署功能，应用程序必须容器化。
数据库
软件系统一般分为应用层（前端、后端）和数据库层，以及部署相关，Choerodon猪齿鱼主要覆盖应用层，以及部署相关的容器层，现在还没有覆盖数据库层的相关内容。对于数据库层，用户可以选择自建或者是使用公有云的RDS服务。另外，程序中依然可以使用自动化的脚本构建数据库和初始化数据等，与原来没有任何区别。
前后端分离
目前很流行前后端分离的架构，例如后端使用SSM，前端采用React、Ant Design，移动端采用React Native等。Choerodon猪齿鱼完全支持这样的前后端分离架构，其实还是那句话“只要是能够容器化的应用都可以使用Choerodon的PaaS平台进行开发和部署”。
微服务
微服务是目前非常流行的技术之一，代表有Spring Cloud、Dubbo等。现在大家在谈微服务的时候一定要加上Agile/DevOps，貌似微服务+Agile/DevOps是不可分割的整体。根据实践经验，微服务的实施和落地需要从项目管理，开发，部署，运营监控，以及容器化等多个方面来考虑和配套。Choerodon猪齿鱼实际上是因微服务而生，有一整套完整的工具链条来支撑微服务的实施和落地。
移动应用支持
现在有各种移动应用技术，如React Native，Weex，PWA等。用这些或者别的框架开发的模块应用，只要能够打包成一个文件并且能够在原生应用中使用的，就可以通过Choerodon猪齿鱼进行移动微服务的版本跟踪、发布、回退甚至是根据不同主版本号进行个性化定制。
但是总应用的开发（一般用原生的Java或者OC或者Swift来开发原生应用）作为一个前置条件，是不通过微服务管理的（因为往往要涉及到应用的审核、推送、上架等），所以这里说的移动应用微服务化是指其中的模块应用。总应用只要能够实现文件的下载、覆盖，版本的对比即可。
如果总应用开发完成，在日常开发中开发人员要做的只是独立的模块开发，推送到Git库，触发CI，这时会生成模块的镜像并推送，然后在Choerodon猪齿鱼中选择是否可见和版本管理，即可在手机的应用上查看或者更新该模块。
公有云、混合云
Choerodon猪齿鱼是基于Kubernetes部署的，只要是能够安装部署Kubernetes就可以安装使用猪齿鱼，所以公有云、私有云或者混合云，只要安装了Kubernetes，就可以安装使用Choerodon猪齿鱼，另外，对于公有云中提供的RDS、NFS等服务Choerodon也可以使用，但是对于公有云提供的Kubernetes服务，阿里云、腾讯云的K8s服务是没有问题的，AWS的K8s服务可能有问题，因为AWS的Kubernetes服务是经过客户化的版本的可能有所不同。
关于猪齿鱼
Choerodon 猪齿鱼是一个全场景效能平台，基于 Kubernetes 的容器编排和管理能力，整合 DevOps 工具链、微服务和移动应用框架，来帮助企业实现敏捷化的应用交付和自动化的运营管理的平台，同时提供 IoT、支付、数据、智能洞察、企业应用市场等业务组件，致力帮助企业聚焦于业务，加速数字化转型。
大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：
Git库是拉式流水线模式的核心，它存储应用程序和配置文件集。开发人员将更新的代码推送到Git代码库; CI工具获取更改并最终构建Docker镜像。GitOps检测到有镜像，从存储库中提取新镜像，然后在Git配置仓库中更新其YAML。然后，GitOps会检测到群集已过期，并从配置库中提取已更改的清单，并将新镜像部署到群集。
这是一个新图，显示部署上游的所有内容都围绕Git库工作的。在“拉式流水线”中讲过，开发人员将更新的代码推送到Git代码库，CI工具获取更改并最终构建Docker镜像。GitOps的Config Update检测到有镜像，从存储库中提取新镜像，然后在Git配置仓库中更新其YAML。然后，GitOps的Deploy Operator会检测到群集已过期，并从配置库中提取已更改的清单，并将新镜像部署到群集。
