GrowingIO SaaS 产品 CI/CD 实践 (一)

作者：郝阔君
GrowingIO QA Leader，曾任职于中国惠普、奇虎 360。带领 QA 团队负责 GrowingIO 全产品线质量保证工作，目前专注于 DevOps 实践，帮助团队提升质量和效率。

目的

本文主要描述 GrowingIO 过去在 SaaS 产品线上 CI/CD 的一些实践。由于历史原因公司使用的部分工具链比较小众，当前的 CI/CD 的流程还有很大的改进空间 ，但是一些实践经验还是有一定借鉴意义的。

什么是 CI/CD

CI/CD 是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。CI/CD 的核心概念是持续集成（Continuous Integration）、持续交付（Continuous Delivery）和持续部署（Continuous Deployment），业界对 CI/CD 理解如下。

CI 持续集成（Continuous Integration）

持续集成是一种开发实践，在持续集成环境中，开发人员将会频繁地向主干提交代码，这些新提交的代码在最终合并到主干前，需要经过编译和自动化测试流进行验证。

持续集成是在源代码变更后自动检测、拉取、构建和（在大多数情况下）进行单元测试和静态质量分析的过程。

持续集成的目标是快速确保开发人员新提交的变更是好的，并且适合在代码库中进一步使用。CI 的流程执行和理论实践让我们可以确定新代码和原有代码能否正确地集成在一起。

CD 持续交付（Continuous Delivery）

完成 CI 中构建及单元测试和集成测试的自动化流程后，持续交付可自动将已验证的代码发布到存储库。为了实现高效的持续交付流程，务必要确保 CI 已内置于开发管道。持续交付的目标是拥有一个可随时部署到生产环境的代码库。

在持续交付中，每个阶段（从代码更改的合并，到生产就绪型构建版本的交付）都涉及测试自动化和代码发布自动化。在流程结束时，运维团队可以快速、轻松地将应用部署到生产环境中或发布给最终使用的用户。

CD 持续部署（Continuous Deployment）

对于一个成熟的 CI/CD 管道（Pipeline）来说，最后的阶段是持续部署，持续部署可以自动将应用发布到生产环境。

持续部署意味着所有的变更都会被自动部署到生产环境中，但是出于业务考虑，可以选择不部署。如果要实施持续部署，必须先实施持续交付。

持续交付并不是指软件每一个改动都要尽快部署到产品环境中，它指的是任何的代码修改都可以在任何时候实施部署。持续交付表示的是一种能力，而持续部署表示的则是一种方式。持续部署是持续交付的最高阶段。

如何实现 CI/CD

实现一套 CI/CD 流程主要有以下几种途径：

1. 购买现成的产品或服务

很多成熟的产品都提供完善的 DevOps 功能，如 Atlassian、微软的 Azure DevOps、阿里的云效、coding.net 等等。如果是全新的初创公司可以选择购买合适的产品和服务，可以借助 DevOps 产品提供的工具和最佳实践，快速搭建起一套完善的 DevOps 体系。很多 DevOps 服务都是跟云厂商集成的，如果已经使用了对应的云服务产品，再使用对应的 DevOps 服务其成本并不高。

2. 将现有的一些工具集成起来

这是目前多数公司最常见的一种做法，将公司内部的项目管理，代码管理，制品管理等工具集成起来，或做一些简单的二次开发实现一套完整的 CI/CD 流程。这种方式总体成本可控，利用现有的基础设施进行改造，方便灵活，可以根据公司自己的流程来定制。

多数公司都是采用这一种方式，因为多数公司创立之初，必然是先生存后发展，并不会把工程效率放在第一位，会选用一些单独的工具（如代码管理）解决某一领域的问题。随着公司发展才会更多的考虑工程效率，此时将现有工具集成起来显然是最常见的选择，GrowingIO也不例外。

3. 使用一些开源的 DevOps 平台

目前也有一些开源产品，已经基于各种开源产品做了二次开发集成，形成了完整的 DevOps 平台，如猪齿鱼。如果不想购买云服务，又不想做二次开发，可以尝试此类工具。

不过值得注意的是，使用开源工具的资源投入并不一定会少，尤其是出现问题需要解决，或者说工具不能满足自身需要时需要二次改造，都需要对工具进行深入的研究和了解，所以选择这类产品也要考虑是否与公司当前的技术栈匹配，是否有能力进行维护。

4. 自己设计开发实现

自己新造轮子，重头开始设计开发实现一套。显然这种方式是投入成本最高的，但也是