前段时间翻到几条留言，问：
“配置即代码和基础设施即代码一样吗？”
“配置即代码是什么？怎么都是基础设施即代码？”
我们都是知道，DevOp的快速发展，让服务器管理与配置的时间大大减少，配置即代码和基础设施即代码作为DevOps的重要实践，在其中起到了关键性作用。
不少人将二者看作是一件事，配置即大代码是关于管理特定的应用程序配置设置本身，而基础设施即代码更关注的是部署支持应用程序环境所需的底层基础设施。
二者虽然相互补充，经常一起使用，但为了避免混淆，我将从概念、意义以及做法三个方面介绍配置即代码。
配置即代码（Configuration as Code，CaC）是不同环境之间配置的版本迁移。在配置即代码的实践中，配置信息通常以文本文件的形式存储，这些文件可以用版本控制系统（如Git）进行管理。通过这种方式，每次环境配置的变更都可以被追踪和审查，有助于团队协作和问题的快速定位。
配置即代码一般用于管理软件包和组件的设置。这适用于广泛的行业。在应用程序开发过程中，可能会使用配置来支持多种操作系统。通过维护配置即代码，您可以跟踪数百甚至数千个硬件原理图和嵌入式开发的测试信息。
团队可以通过多种方式从实现配置为代码中受益。
像IaC一样将配置更改作为代码处理，使团队能够从单个集中位置创建、更新和维护配置文件，同时利用一致的部署方法。举个例子，如果正在开发USB设备，则需要每个存储选项的配置文件。我们可以将这些文件与所需的软件结合起来创建数千种配置。
当配置像源代码一样编写时，开发团队可以使用开发最佳实践，例如linting和安全扫描。在提交之前，必须审查并测试配置文件以保证修改符合团队的标准。配置可以通过复杂的微服务架构保持稳定和一致。当建立起一套流程时，服务可以更有效地协同运作。
将配置设置为代码需要版本控制，可以方便地保存和跟踪配置和代码文件的更改，这可以提高软件发布的质量水平。一旦出现错误，开发团队可以通过比较版本化的配置文件来找到其来源并快速识别、修复问题。
开发团队可以通过将配置转换为托管代码来简化构建周期。这样一来，IT和最终用户的工作效率都会提高。管理员可以将所有内容合并到发布版或从单一版本控制系统构建中。开发人员对他们所做的更改的准确性充满信心，因为工作流程的每个组件都经过了一致的测试。
我们需要决定如何在版本控制系统中保存在代码中创建或重构的配置文件，可以通过以下方式实现：
如果所有文件都放在一个存储库中，那么工作流程可能会变得更简单。但如果我们将配置文件视为源代码，那对设置的任何更改都可能会造成新的构建，导致团队的工作速度变慢。
其实，并不是所有配置更新都需要构建。系统管理员会对其进行配置，以启用对配置文件的更改合并，最终将其部署到一个预生产环境中进行测试。除此之外，我们需要建立跨团队统一的命名约定，因为一切都是代码，所以在执行审计时区分配置文件和源代码极易出现错误。
通常情况下，开发团队会将代码分成多个存储库，再根据此架构将配置文件与特定微服务一起进行保存和版本控制。在此过程中，即便遇到与触发器构建类似的问题，但处理起来可能更简单。另外一提，如果准备使用其微服务对配置文件进行版本控制，我们需要提前规划如何分发配置更改。
对于简单的配置修改来说，我们没有必要设置完整的应用程序代码测试环境。团队可以通过将测试环境的范围限制在配置部署过程的要求范围内来节省时间和金钱。
配置即代码可以以多种不同的方式实施，但并非所有方式都适合每个开发团队。开发团队需要根据自身需要选择适合的方式：
通过将配置作为代码纳入流程，开发团队可以获得显著的优势。通过自动跨环境部署配置，可以更轻松地应用更新并确保一切按预期运行。由于它使用单个存储库，因此更改易于管理和跟踪。
在增强代码开发和部署的同时，配置即代码也是管理和控制复杂基础设施和管道的宝贵工具。因此，您可以获得加快开发所需的可见性和控制力，而不会损害部署的安全性。
参考资料：
【1】Hanmid Akhtar,Configuration as code: everything to know,2024.
【2】Adam Bertram,Config as code: what is it and how is it beneficial,2021.
众所周知，当子组件使用setup后，父组件就不能像vue2那样直接就可以访问子组件内的属性和方法。这个时候就需要在子组件内使用defineExpose宏函数来指定想要暴露出去的属性和方法