Lambda deployment BeforeAllowTraffic and AfterAllowTraffic events

[keruzu]

[Case 10185456491] BeforeAllowTraffic and AfterAllowTraffic events to receive:

LifeCycleEvent: BeforeAllowTraffic or AfterAllowTraffic Alias: ARN to the alias CurrentVersion: ARN to the version TargetVersion: ARN to the version

Note: the appspec should be adjusted to NOT require the 'CurrentVersion' to be required. This should be gathered from the environment automatically.

Rationale: There are a number of issues with the current implementation:

1. The assumption that the code deployed via CloudFormation is the code to be deployed Scenario 1: Updates made in console and published are put into CodeDeploy appspec

   Scenario 2: Latest version is NOT the target version being deployed in CodeDeploy appspec eg one version is to be deployed in one environment in one stack, and another version in another stack

In this case, the writer of the BeforeAllowTraffic or AfterAllowTraffic lambda must assume (\"pray\" might be a better word choice) that the appspec parsed by CodeDeploy resembles the actual version going into production.

At this point, CodeDeploy has all of the information required, but decides NOT to share it.

3. Poor programming practice that violates the Don't Repeat Yourself (DRY) principle The current implementation requires the same data to be consistent in three places: a. The Lamba alias version b. The environment variable in for the BeforeAllowTraffic or AfterAllowTraffic lambda c. The appspec.yml file

The workaround of using a reference to get at the version means that the same data only requires the same data to be consistent across the deploy. However, the workaround explicitly requires a new lambda definition to be created -- in other words, difficult to scale and manage.

4. Requires the customer to: a. Retrieve the appspec file from where it is stored AND keep all of the access mechanisms up-to-date if AWS ever offers other options eg today I need to support S3, locally stored file b. Parse the variations of data in the appspec file AND keep up to date with any changes AWS might make to the file format

and then the customer can know precisely which version is being used and act appropriately

5. Requires separate test functions for every lambda x 2 (BeforeAllowTraffic + AfterAllowTraffic versions) This is a significant amount of CFN duplication to try to achieve a result (ie exactly the type of \"undifferentiated heavy lifting\" that AWS likes to talk about)

Here's the pseudo-code for what the test lambda needs to accomplish:

deploymentId, executionId, lambda_name = getTestMetaData(event) test_data = getTestEventData(lambda_name) response = run_lambda(lambda_name, **test_data) test_result = isValidResponse(response) report(deploymentId, executionId, lambda_name, test_result)

Much of the above is boilerplate, with only two functions that really need to be filled out by the customer:

getTestEventData() - for the lambda alias/version, retrieve the test + expected response series from DynamoDB / SSM parameter store / wherever isValidResponse() - compare the test result to the expected result and return true / false

Given this example structure, a customer could implement a data-driven solution, rather than a code-driven solution. In other words, write the lambda to evaluate the tests once, and re-use the same solution without re-inventing the wheel across an entire organization.

[mwjones-aws]

Hello,

This GitHub repo is home to CodeDeploy Agent. Customers who use CodeDeploy's EC2 and on-premise compute platform install this software on their instances. This agent is not used for CodeDeploy deployments to Lambda functions.

You list a case number at the top of the issue, and I see you have a ticket open with Premium Support. Please continue to track this issue using that case number.