管理AWS Lambda的Serverless多环境（dev/prod）：现有做法是否常规？

你的这套步骤确实能实现独立dev环境的部署，但在Serverless框架的生态里，更常规、更易维护的多环境管理方式是基于单配置文件+命令行stage参数，而非创建多个独立的yml文件。

常规多环境管理的正确姿势 #

1. 只维护一个serverless.yml，通过变量动态适配不同环境：

   provider:
     name: aws
     runtime: nodejs14.x
     stage: ${opt:stage, 'prod'} # 默认用prod，部署时可通过--stage指定其他环境
     region: eu-west-2
     profile: ${opt:stage, 'prod'} # 自动匹配对应环境的AWS CLI profile
     memorySize: ${self:custom.envConfig.${opt:stage, 'prod'}.memorySize}
     timeout: ${self:custom.envConfig.${opt:stage, 'prod'}.timeout}
   
   custom:
     envConfig:
       prod:
         memorySize: 256
         timeout: 30
       dev:
         memorySize: 128
         timeout: 30
   
   resources:
     Resources:
       <My Logical ID>:
         Type: AWS::IAM::Role
         Properties:
           Path: /my/cust/path/
           RoleName: clearbit-lambda-role-${self:provider.stage} # 用stage变量自动生成唯一角色名
   

2. 部署dev环境只需执行命令：

   sls deploy --stage dev
   

你当前做法的问题 #

• 多配置文件会产生大量重复代码，后续修改基础配置（比如runtime、region）时，需要在所有yml文件中同步更新，容易遗漏出错
• 手动修改RoleName属于硬编码操作，随着环境增多（比如新增test、staging），重复劳动量会越来越大，也容易出现命名冲突

为什么你会遇到角色名称冲突 #

因为你在resources里硬写了固定的RoleName，没有结合stage动态生成。Serverless框架默认会给所有资源名称自动添加stage后缀（比如Lambda函数名、角色名），只要不硬编码固定名称，就能自动避免冲突。如果需要自定义命名，用${self:provider.stage}变量拼接即可。

如果你坚持用多配置文件 #

建议通过extends关键字继承主配置，减少重复代码：

# serverless-dev.yml
extends: serverless.yml
provider:
  stage: dev
  profile: dev
  memorySize: 128
resources:
  Resources:
    <My Logical ID>:
      Properties:
        RoleName: clearbit-lambda-role-dev

这样只需在dev配置文件中覆盖差异项，其余配置继承自主文件，比完全复制一份yml更高效。

内容的提问来源于stack exchange，提问作者JimmyTheCode