AWS Lambda - What is a best practice for versioning and promoting lambdas in CI/CD pipeline

Question

I'm new to AWS Lambdas and wanted to check what are the best practices of versioning lambdas and promoting them to the higher environments in the CI/CD pipeline.

As an example, let's go with following assumptions:

• I have 3 environments: dev / ci / prod
• I have multiple lambdas inside one Git repo (which share some common code)

I see the process as following:

• Shared code would be packaged in separate layer
• Every lambda would be packaged separately and it would re-use the shared layer

Now, going back to the CI process, I would need some way to differentiate between set of lambdas/layers from one env. to another.

My first assumption was to utilise Tags for this purpose to have:

"Environment=Dev"
"Environment=CI"
"Environment=Prod" 

tags which would differentiate between same lambda used on different environments. Unfortunately, there is no way to have multiple lambdas with same name (even though tag is different), if I'm correct?

Next idea would be to keep different names of lambda functions based on environment. For example:

mylambda-dev-<DEV_NAME>-<SPECIFIC_BRANCH_NAME> # where <DEV_NAME> is used to differentiate between dev env. for multiple developers
mylambda-ci-<INTEGRATION_BRANCH_NAME>
mylambda-prod

• During the development process, developer would run CI job which would create/update mylambda-dev-<DEV_NAME>-<SPECIFIC_BRANCH_NAME>
• When it is in good state to be integrated (and code merged to integration branch), there would be a CI job which would create/update mylambda-ci-<INTEGRATION_BRANCH_NAME>
• Finally, when we are ready to release in production, there would be a CI job which would create mylambda-prod with specific version (1, 2, 3....) to make released lambda immutable. Also, an alias would be created to point to specific version in production. This alias would map numeric versions into something more meaningful for the project like: <PROJECT_NAME>_v1.0.0

Same process would be applied for layers also.

These are my initial thoughts on this topic. Any help/guidance/experience which leads toward the best practice to cover this topic would be great.

Thanks.

Answer 1

What we are following for Lambda promotion is

1. Each lambda has -{{ environment }} such as my-lambda-dev, my-lambda-stage, my-lambda-prod

2. Each lambda has 'Smoke' and 'Live' alias.

When we perform CI/CD job, follow below steps

Loop on a list of environments (such as dev-> stage -> prod)

2.1 Backup a green build for 'Live' version on the current working environment such as 5.1.0

2.2 Deploy to the current working environment AND on 'Smoke' alias only

2.3 Perform Test Cases on 'Smoke' alias

2.4 If the test cases are all passed, apply it to Live alias and then continue the loop (it means continue for promotion to higher environments)

2.5 If any failed, roll back to a version which backed up at 2.1 for current environments and below. After that break the loop

Note: Make sure all source events, use Live version, not Smoke version.

Thanks,