Code Repository Organization - Serverless Architectures with AWS Lambda

Code Repository Organization

We recommend that you organize your Lambda function source code to be very fine-grained within your source code management solution of choice. This usually means having a 1:1 relationship between Lambda functions and code repositories or repository projects. (The lexicon differs from one source code management tool to another.) However, if you are following a strategy of creating separate Lambda functions for different lifecycle stages of the same logical function (that is, you have two Lambda functions, one called MyLambdaFunction-DEV and another called MyLambdaFunction-PROD), it makes sense to have those separate Lambda functions share a code base (perhaps deploying from separate release branches).

The main purpose of organizing your code this way is to help ensure that all of the code that contributes to the code package of a particular Lambda function is independently versioned and committed to, and defines its own dependencies and those dependencies’ versions. Each Lambda function should be fully decoupled from a source code perspective from other Lambda functions, just as it will be when it’s deployed. You don’t want to go through the process of modernizing an application architecture to be modular and decoupled with Lambda only to be left with a monolithic and tightly coupled code base.