How to do not deploy lambda if no changes on code - aws-lambda

AWS Lambda are deployed even if there is no change on code and serverless configuration. I would like to do not deploy it...
My code is redeployed even after 2 consecutive serverless deploy
I tried to launch, on the same code base, serverless package twice and the only the difference is on the S3Key and artifactDirectoryName.
The resulting serverless-states.json files contain the following S3Key:
serverless/[...]/1560423171166-2019-06-13T10:52:51.166Z
serverless/[...]/1560423200593-2019-06-13T10:53:20.593Z
So I'd like to understand if this can cause deployment ?
Or is this a bad behavior of serverless ?
serverless --version
1.45.1
Actually, I'm expecting to do not deploy my lambdas

Related

AWS PublishVersion together with Serverless

I have a pretty big project that I use Serverless Framework to deploy to AWS (a few lambdas together at a time) using Windows Terminal.
I would do:
serverless deploy -s integration
and it will take all of my lambdas and deploy them. My problem is that I need to use the versioning of AWS, and I don't know how to do it.
After I do the serverless deploy, do I need to open the AWS CLI console and run something like this for each lambda that I already deployed using serverless?
version=$(aws lambda publish-version --function-name test_lambda --description "updated via cli" --region eu-west-1| jq '.Version')
I'm just confused on how to combine the 2 ways of deploying lambdas.
by default, all functions deployed with Serverless Framework are versioned. You can also disable it or turn it on explicitly by setting:
provider:
versionFunctions: true (or false to turn it off)
Please keep in mind that the old versions are not removed automatically, so if you want to keep e.g. only a few previously deployed versions, you might need to use a plugin as https://github.com/claygregory/serverless-prune-plugin

Serverless Framework dry run or test without deploying

There's any way to test Serverless Framework code without deploying it? Similar to Terraform's dry run.
I've tried using the --noDeploy flag, but it doesn't seem to work. I'm trying to create a CI pipeline for it, but can't find any solution.
the closest we have in Serverless Framework is the serverless package command, it will build and save all of the deployment artifacts in the .serverless directory:
https://www.serverless.com/framework/docs/providers/aws/guide/packaging/
you can inspect the CloudFormation and anything else (e.g. code transpilation, plugins etc) generated by Serverless Framework in that folder

CDK: Deploy microservice endpoints (lambdas) individually

I am writing IAAC with CDK for a microservice that'll be using APIGateway's RestAPI.
I have one stack with all the lambdas and the restApi in one place, I can deploy everything just fine.
Now the problem is when two people are working on different endpoints I would want them to be able to deploy just the endpoint(lambda) they are working on. Currently, when they deploy, CDK deploys all the endpoint from their repo overwriting changes someone might have deployed from their branch.
I would happily share some code but I am not really sure what to share. I think I can use some help with how to structure the code in stacks to achieve what I need.
You have one api gateway shared across two different endpoints from two different repos.
There are couple of ways that I can think of:
Option 1: we need 4 stacks.
Gateway Stack: Api Gateway and Root endpoints.
Endpoint1 stack: Lambda and necessary routes.
Endpoint2 stack: Lambda and necessary routes.
Gateway Deploy stack: Deploy the stage.
Each time a lambda function is changed, deploy its own stack and the deploy stack.
Option 2: we just need 1 stack but deploy lambdas separately.
Single CDK project which deploys everything. Only thing to keep in mind is artifacts for the lambda functions should be taken from S3 bucket location.
Within individual pipelines of each lambda, copy artifacts to same S3 location referenced by lambda in cdk and trigger an update to lambda with a aws cli update-function-configuration as simple of update description with a timestamp or an env variable, just to trigger a new deployment.
This way either we can seamlessly deploy CDK pipeline or individual lambda pipeline
You have 2 options to solve this problem without much work.
First one is to use code to identify who is deploying the stack. If developer 1 is deploying the stack then set some environment variable or parameter to stack. Based on that value, CDK code should compile only 1 of the endpoint repos.
Second option is to not build the repos as part of (CDK) deployment. Use Continuous Delivery (or anything else) which builds the repo code separately and CDK only deploys them.
Based on the context of your project any one strategy should work fine for you. Or share more context if it's not covered until now.
Thanks for your input guys. I have taken the following approach which works for me:
const testLambda = new TestLambda(app, "dev-test-lambda", {
...backendProps.dev,
dynamoDbTable: docStoreDev.store,
});
const restApiDev = new RestApiStack(app, "dev-RestApi", {
...backendProps.dev,
hostedZone: hostedZones.test,
testFunction: testLambda.endpointFunction,
});
Now if a developer just wants to deploy their lambda, they will just deploy the stack for the lambda which won't deploy anything else. Since the restApiStack requires lambda as a dependency, deploying that will also deploy all the other lambdas all at the same time.
One idea as well is for the developer to deploy the pipeline with their code branch name, so they can have a fully fledge environment without worrying about overriding the other developer's lambdas.
Once they're done with the feature, they just merge their code in the main branch and destroy their own pipeline.
It's a common approach :-)

Difference between AWS::Serverless::Function and AWS::Lambda::Function

I am developing aws lambda function and I have an option of using one of these two function, but I don't find any good place where I can see the difference between these two. Which one should be used and in which case?
AWS serverless application model i.e. AWS SAM is used to define a serverless application. You need to deploy this application on AWS lambda via s3.
SAM comes in action while testing the AWS Lambda Function locally because it's not easy to deploy and test on AWS Lambda every time you make a code change.
You can configure SAM on your IDE like eclipse, test and finalise the code then deploy it on Lambda.
For more info about sam https://github.com/awslabs/serverless-application-model/blob/master/HOWTO.md

Managing a development codebase in Lambda

I'm moving to serverless with AWS Lambda. I've gotten to "hello world" so far. I'm used to having a development codebase that I work on, test, and then promote to production. Is there an easy way to do this with Lambda?
I use different AWS accounts for dev, staging, and prod. When deploying the Lambda, I just choose which AWS profile to use so it deploys to the right environment.
If you're using a single AWS account, each deployment of a Lambda function will have a version. You can use those.
If you're using API Gateway with Lambda, you can use API Gateway's "Stages".
You should use a deployment framework such as serverless and that will make things easier for you.
Using frameworks like serverless makes it easy to develop, configure and deploy lambdas, API gateways and other events to AWS. I highly recommend that you adapt serverless framework. This makes it easier to integrate and use serveless deployment with your current CI system.
Now if you have all your environments within one AWS account then you can use stages to represent each env. Using serverless you can simply deploy the lambdas to a different env using --stage (-s) argument.
serverless deploy -s <env/stage name>
You put some smarts in configuring serverless yaml file to pick up configuration files based on your stage (assuming that you will require accessing diff resources like db, s3 buckets etc for diff environments)
If you are using different AWS accounts for prod and nonprod (recommended) then all you need to do is provide an additional argument for the profile.
serverless deploy --profile <prod/nonprod profile> --stage <prod/nonprod stage>

Resources