我在一个使用 Git 作为版本控制的开发团队中。
我们希望我们的开发过程至少有 3 个阶段：登台、开发和生产。
在这些阶段之间唯一应该改变的是一个配置文件，它告诉无服务器框架应该为 lambda 函数、S3 存储桶以及需要为 CloudFormation 堆栈创建的任何其他资源命名什么。
但是，这会使源代码控制变得更加困难。如果我们将配置文件直接放在源代码中，那么我们必须确保当我们提交/推送到源时这些文件不会被覆盖。但是 CodeBuild 必须以某种方式访问它，并且必须确保为指定阶段获取正确的配置文件。
我更喜欢 AWS 生态系统的一部分来解决这个问题。
【问题讨论】：
标签： git amazon-web-services staging aws-codepipeline aws-codebuild
我的建议是将您的环境变量存储在 EC2 Parameter Store 中，您可以在 CodeBuild buildspec.yml 中引用这些变量。
要在您的案例中使用 CodePipeline，您还需要针对每个环境使用不同的管道和不同的 CodeBuild 项目。
例如，假设您将以下变量存储在 EC2 Parameter Store（或 AWS SSM）中，
DEVELOPMENT_DB_PASSWORD='helloworld'
STAGING_DB_PASSWORD='helloworld'
PRODUCTION_DB_PASSWORD='helloworld'
在您的 CodeBuild 项目中，您必须将环境指定为变量（例如 $ENVIRONMENT=DEVELOPMENT）。不要为此使用buildspec。您可以使用 AWS 控制台或 CloudFormation。
那么，您的buildspec.yml 可以如下所示：
env:
parameter-store:
DEVELOPMENT_DB_PASS: "DEVELOPMENT_DB_PASSWORD"
STAGING_DB_PASS: "DEVELOPMENT_DB_PASSWORD"
PRODUCTION_DB_PASS: "DEVELOPMENT_DB_PASSWORD"
然后可以使用${env:ENVIRONMENT}_DB_PASS 在您的 serverless.yml 中访问这些变量，如下所示：
provider:
environment:
DB_PASS: ${env:${env:ENVIRONMENT}_DB_PASS}
您现在要做的就是创建这三个 CodePipelines，每个都有自己的 CodeBuild 项目（每个项目使用不同的 $ENVIRONMENT）。
【讨论】：
为什么不使用三个配置文件？每个阶段一个。
【讨论】：