Git 如何处理AWS代码管道的配置文件？

我是一个使用Git作为版本控制的开发团队

我们希望开发过程至少有3个阶段：阶段、开发和生产

在这两个阶段之间，唯一需要更改的是一个配置文件，用于告诉无服务器框架lambda函数、S3 bucket以及需要为CloudFormation堆栈创建的任何其他资源的名称

然而，这使得源代码控制有点困难。如果我们将配置文件直接放在源代码中，那么我们必须确保在提交/推送到源代码时不会覆盖这些文件。但是代码构建必须以某种方式访问它，并且必须确保获取指定阶段的正确配置文件

---

我更希望这个问题的解决方案是AWS生态系统的一部分。

为什么不使用三个配置文件？每个阶段一个。

我建议将环境变量存储在EC2参数存储中，您可以在CodeBuild buildspec.yml中引用它

要在您的案例中使用CodePipeline，您还需要为每个环境使用不同的管道和不同的CodeBuild项目

例如，假设您将以下变量存储在EC2参数存储（或AWS SSM）中

在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"

然后，可以在serverless.yml中使用

${env:ENVIRONMENT}\u DB\u PASS

访问这些变量，如下所示：

provider:
  environment:
    DB_PASS: ${env:${env:ENVIRONMENT}_DB_PASS}

---

您现在所要做的就是创建这三个代码管道，每个代码管道都有自己的代码构建项目（每个项目使用不同的

$ENVIRONMENT

）。

您读过吗？它看起来与您想要做的非常相似。我陷入了最后一步，我认为我的serverless.yml文件将值解释为文本字符串，而没有意识到它是一个环境变量

provider:
  environment:
    DB_PASS: ${env:${env:ENVIRONMENT}_DB_PASS}