运用GitOps来启动环境，可为开发团队带来一致性、版本控制、速度等多方面的好处。
译自How We Evolved from IaC to Environments as Code，作者 Edan Evantal 是 Quali 的CTO Edan Evantal负责Quali基础设施自动化和环境交付平台的所有产品工程。在加入Quali之前，Edan曾在Matrix IT和Sibam Ltd担任工程管理职务。他在高科技行业拥有18年以上的经验……
这些年来，在构建我们的平台的过程中，并与我们的产品所支持的其他DevOps和平台工程师一起工作，我亲眼见证了应用基础架构的演变正在打破它本来意在提供的自动化。
基础设施即代码(IaC)工具对于定义和自动交付云服务非常宝贵。当一个开发团队的需求扩展到此范围之外时，自动化通常就会中断。
原因有两个:
- IaC工具的设计目的在于速度和自动化，而不是作为环境的真实来源。大型团队在大规模利用基础设施和了解代码更改可能如何扰乱应用性能方面可能会遇到困难。
- IaC工具之间不兼容。应用日益依赖于用各种技术定义的复杂基础设施，需要手动编排来协调工具的细微差异。
开发人员在基础设施自动化功能与应用需求实际情况之间存在鸿沟。其结果是速度降低，基础设施存在未管理或配置错误的风险增加。
我们询问自己，我们能做些什么来弥合这一鸿沟，这让我们想到了一个简单的问题:
如果您可以以代码的形式启动所有环境，而不管基础设施的范围或用于定义它的 IaC 工具是什么，会怎么样？
在Git中将环境定义为代码
为了将环境定义为代码，我们首先需要以开发人员启动环境所需的一切来定义，这种格式对于DevOps来说既易于理解，又方便自动化机器读取。
使用我们的Torque平台，我们连接到一个Git仓库，发现其中定义的IaC模块，并将资源配置打包成一个新的由平台自动生成的YAML。
从那里，我们可以修改任何YAML代码，以包含环境启动时将生成的基础架构组件、参数、依赖项、元数据、身份验证和输出。
下面是YAML代码片段示例:
kind: environment
environment_name: "Workstation Staging A"
description: "EC2 workstation for staging workloads"
state: inactive
owner_email: "myemail@email.com"
blueprint:
name: "test-workstation"
repository_name: "cloud-native-application"
branch: "main"
commit: "536955389cd4ecbd1b8895c4a1093fe14a809b65"
inputs:
service-account: "sa"
agent: "review3"
grains:
create-ec2:
source:
commit: "697d1"
specs:
instance_type: "t2.large"
ami: "ami-0c55b159ertafe1f0"
security_groups: ["sg-0246e9ddc2b2f23f4"]
post-deployment:
scripts: ["./configure-environment.sh", "./deploy-application.sh"]