本文重点介绍资源编排服务（Resource Orchestration Service, ROS）的CI/CD最佳实践。
小提示：“基础设施”这个词汇有时有点拗口，或者不直观，其实它就是指系统或应用所依赖的环境，如服务器，数据库等，在云上，环境有各个云产品资源（简称云资源）组成，如服务器是ECS，数据库是RDS，负载均衡是SLB。所以文中会交叉出现“基础设施”和“环境”使用。
资源编排服务ROS和使用场景
资源编排服务ROS是阿里云提供的云资源的自动化部署服务，可以帮忙您实现一键部署系统所依赖的云资源（ECS，RDS，SLB等），以便满足您部署多地域（如北京，上海等），多环境（如测试，预发，生成）的需要。资源编排服务ROS还提供了常见的系统架构，最佳实践，行业解决方案供您参考。ROS控制台：https://rosnext.console.aliyun.com/
上一篇系列文章“云上部署环境（基础设施）的正确姿势——使用资源编排ROS进行基础设施的部署” https://developer.aliyun.com/article/743051 主要向大家介绍了资源编排服务（ROS）的主要用途，即阿里云上的自动化基础架构（环境）部署服务，再次复习ROS的主要几个场景和优点：
- 可以快速地重复部署，如部署测试、预发和生产环境，尤其适合需要在多地域部署的情况。
- 可以减少环境之间的偏差，有助于将部署过程和结果尽量标准化，减少因为环境偏差引入的系统问题。
- 一键部署，极大地提高了部署效率，即可以更快地发布系统和应用。
- 一键销毁，在测试完成，或蓝绿部署时，一键销毁所有资源，减少资源浪费，彻底净除环境，以便于下次部署。
- 阿里云ROS提供了最常见的网站，ML架构，最佳实践，方便您尽快地进行测试、验证或建立产品雏形。
- 最佳实践之基础设施代码化（Infrastructure as Code，IaC）完成度最高且依赖最少的免费服务。（本文介绍的重点）
- 所有操作都集成访问控制（RAM）和操作审计（ActionTrail），确保基础设施的安全。
资源编排服务ROS的CI/CD最佳实践
常见问题 —— 只用到了Infrastructure as Code的10%
一般的用户在使用资源编排ROS时，只用到ROS的创建云资源过程，这类用户通常参考了一个部署架构示例，然后在ROS的控制台上，或通过ALIYUN CLI，根据此模板创建一个资源栈，即一组根据模板定义所创建出来的资源的组合叫做资源栈（简称Stack），然而在日后的维护过程中，却不再通过修改模板加更新堆栈的方式进行云资源的维护，这样即无法享受到ROS所带来的全部优点 —— 即基础设施代码化（Infrastructure as Code，IaC）。
上面提到的ROS的优点和场景，更多的是从模板化，标准化和可复用化的角度来讲的，这里还将补充代码化带来的好处。
基础设施代码化（Infrastructure as Code）和集成CI/CD的好处
像Review代码一样Review基础设施的模板
总所周知，源代码的管理理论和工具都已经非常成熟，无论是国内外，从创业公司到大型企业，都在使用代码版本管理软件，其中又以Git（以下直接用Git举例）为当今的网红工具。将基础设施模板化，然后再代码化，也是让模板享受和代码一样的流程，这里用了一个简化的git flow（或Github flow）来进行示意：
模板代码化以后，也需要经历Code Review和测试这样的自动化CICD集成，Code Review以及Git merge这类的流程可以最大程度上保证模板template的正确性，实际的工作中，有些公司在改变系统环境时根本都不审批，即使有些公司有审批工具，其功能的完善程度也很难和Git媲美，Git可以进行模板内容的diff比较，可以回滚，可以有一个统一的t版本号或tagging，可以集成到Pipeline中等等。
将ROS集成到持续部署（CD）中
一般来说，当基础设施（环境）需要变更时，往往需要先变更环境，然后再部署系统（应用）。如果应用的部署发生在环境变更之前，则会导致应用部署失败或不正常工作，因为应用的依赖性还不存在，如新创建了一个数据表。所以，一般来说，都先进行环境的变更，然后再进行应用的变更。
这里要求Pipeline有能力调用资源编排ROS进行部署，当Pipeline检测到ROS模板有变化后，应该调用ROS服务将变更落实到环境中，并且Pipeline有能力把staging的参数传递给ROS，即可使用同一份模板部署多个环境，多个地域，如下图所示。
一个比较完整的示例流程
该文在最前面的图片，主要展示了基础设施模板的工作流，其他的步骤有所简化，在具体的实施过程，可以有所区别，最大的区别莫过于是选择同一代码库还是将基础设施模板和代码分别放置在2个不同的代码库中，两种方式各有利弊，分别2个代码库时，Pipeline更容易检测是基础设施模板发生了变化还是代码发生了变化。放在一起时，更容易实现整体的蓝绿部署，更加地体现了基础设施和代码构成的整体的一致性，方便整体部署和整体回滚。
始终保持基础设施模板和环境的一致性
有些情况你需要手工去修改环境，如某个故障发生时，此时将造成模板和实际环境的不一致，ROS正在开发的偏差探测（Drift Detection）功能将会提醒存在这种不一致，等到故障出来完毕之后，正确的做法应该同时修改模板，测试模板，然后再次部署一次，如果ROS发现环境已经和模板是一致时，将不会再次修改环境，这是ROS的基本工作原理。但是为了确保ROS的工作方式符合预期，请在测试环境和预发环境进行测试，部分云资源的行为存在少许差异。
一旦基础设施的模板和实际环境发生了偏差，而又不去修正模板，使其和实际环境保持一致时，该文所描述的种种好处将全部消失，即造成了模板和环境之间的中断，偏差累积越多，中断得越是厉害，最终导致模板彻底没用了。
