CI/CD正解与实践：Git与Nacos的协作

引用Redhat对CI、CD的解释：【CI/CD 是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。CI/CD 的核心概念是持续集成、持续交付和持续部署。】

https://www.redhat.com/zh/topics/devops/what-is-ci-cd

基于微服务的系统设计，通常使用注册中心来管理服务，实现相互之间的寻址。如nacos、eureka、consul等。考虑到持续集成中，从开发调试、集成测试到生产运营环境要尽量做到各个阶段的一致性，有必要保持交付件的一致性。

什么是交付件？简单来说，包含了程序包和依赖的数据（配置文件，应用数据，环境变量等）。你可能会问为什么不是代码？有些团队就是把代码当做交付件，在开发、测试、运维团队间传递。类比于一个整装销售的硬件产品，在生产阶段、物流阶段、使用阶段，其物流与使用阶段的形态是一致的。当然软件产品为了保障可回溯到具体代码，需要在测试阶段对此再次验证，代码将作为交付件在开发、测试之间传递。

 类比下：CI CD CD

怎么保持一致性？ 有团队仅仅保持代码的一致性，统一从指定的版本库拉取，分别在开发、测试、生产环境构建生成程序包，但明显是不够的；如果在各个阶段都需要独立构建程序包，手工修改配置文件，持续的交付就会出现困境。团队之间会经常出现“我以为”的增量提交变动造成的问题，不可遏制。进而失控。理想地说，我们应该保障程序包和依赖数据的一致性；但一般不可能，所以我们应该确保程序包的一致性，每一次程序的变更要对依赖的数据进行充分的描述，并尽可能的确保其中的配置文件可分离出来以指向不同的环境，并将这部分一致化。其依赖的其余数据，应该明确责任人，确保CD过程中，职责清晰，要求的前后向兼容能获得充分的解释。

依赖的数据分层

上面定义依赖的数据为配置文件，应用数据，环境变量等，无论形态如何，大体可分为如下几类。

1. 节点信息 ：IP与端口、用户与密码对、域名与库、表、队列名、文件路径与环境变量等
2. 负载信息 ： 灰度策略、分级服务、日志级别、线程数、内存数等
3. 业务信息 ： 参数格式、存在性、版本与检查性数据常量等
4. 会话信息 ： 初始不存在，程序包运行后存取的信息，会影响下次的运行路径

除了会话信息之外，我们可以使用nacos统一配置。按照这里的分层可以让运维、测试、开发工程师协作各自负责其所应该承担的部分职能。

Nacos的能力

 

nacos提供了名字空间与分组来区分配置文件，名字空间可以用来分离不同的产品，分组可用来分离同一个产品下的不同模块。