Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

git version control lambda functions

In an attempt to give developers the ability to write their lambda function locally, then commit and push to git, we used SAM and SAM Local.

We have about 50 lambda functions and anticipate this number to grow into the hundreds if not thousands.

I'm wondering how to group the lambda functions repositories i.e should we group all the lambda functions that get triggered by api gateway in their own repo, then all the ones that get triggered by s3 separately etc ...

The challenge is some lambda functions have their own dependencies and it just looks weird to try and have multiple lambdas with different dependencies within same repo. One lambda might have npm package dependencies, another might have python libraries dependencies, etc ... so do I git commit and git push those two lambda in their own separate repos or organize them in separate folders and push them to same repo? Or have separe repos per lambda function?

It doesn't seem feasible to commit each lambda to its own repo especially as the number of those functions grow overtime.

I'm new to aws tools and would appreciate someone's insights on this!

Maybe you've ran into this problem before?

like image 452
pelican Avatar asked Feb 23 '18 16:02

pelican


People also ask

Does Lambda have version control?

Lambda allows you to publish one or more immutable versions for individual Lambda functions; such that previous versions cannot be changed. Each Lambda function version has a unique Amazon Resource Name (ARN) and new version changes are auditable as they are recorded in CloudTrail .

Does Lambda support for versioning and Alias?

You can create one or more aliases for your Lambda function. A Lambda alias is like a pointer to a specific function version. Users can access the function version using the alias Amazon Resource Name (ARN).


1 Answers

I would group them according to their purpose. For example,

  • REST API (HTTP endpoints)
  • GraphQL API (HTTP endpoints)
  • Auth API (HTTP endpoints)
  • Admin API (HTTP endpoints not part of our user-facing product but is essential for managing our customers such as billing systems and company dashboards)
  • Background workers (for processing background tasks like image resize, sending emails, aggregating data, etc.)
  • Operations (not directly part of the product but is essential in daily operations such as Slack WebHooks, CI/CD triggers)

I'd also recommend tools such as serverless-framework to help manage each project.

like image 135
Noel Llevares Avatar answered Oct 01 '22 02:10

Noel Llevares