I don’t know as I’ve ever seen Lambda versioning being used for anything in the wild. Folks just spin up different dev and staging environments for testing.
> Consider this scenario: 1. You have a critical DynamoDB table with a Lambda trigger handling important business logic 2. A developer pushes changes to the Lambda's `$LATEST` version for testing 3. Surprise! Those changes are now processing your production data
...why would a DynamoDB trigger for prod data be pointing to a Lambda where people push things that are still being tested?
> The workarounds are all suboptimal...- Maintain separate tables for different environments
This is not "suboptimal" or a "workaround"; it's the proper way to do things lol
Just as one would have separate RDS instances for QA/staging/test versus production.
I mean the solution would be to have a different test table an also a test lambda. You can deploy to test lambda and test it by changes to the test table.
I don’t know as I’ve ever seen Lambda versioning being used for anything in the wild. Folks just spin up different dev and staging environments for testing.
> Consider this scenario: 1. You have a critical DynamoDB table with a Lambda trigger handling important business logic 2. A developer pushes changes to the Lambda's `$LATEST` version for testing 3. Surprise! Those changes are now processing your production data
...why would a DynamoDB trigger for prod data be pointing to a Lambda where people push things that are still being tested?
> The workarounds are all suboptimal...- Maintain separate tables for different environments
This is not "suboptimal" or a "workaround"; it's the proper way to do things lol
Just as one would have separate RDS instances for QA/staging/test versus production.
Test Lambda --> Test DynamoDB table
Prod Lambda --> Prod DynamoDB table
I mean the solution would be to have a different test table an also a test lambda. You can deploy to test lambda and test it by changes to the test table.