Incremental deployments #10900
Unanswered
martinsson
asked this question in
Q&A
Replies: 1 comment 1 reply
-
I totally agree with @martinsson, the deployment time is very annoying. Couldn't serverless just cache previous builds and avoid re-uploading when the hash of the file is the same?? This would probably bring the deployment time down by 90% or similar in average deployments... |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I find deployments to be unnecessarily slow which greatly limits our ability to deploy often and quickly
Currently if a single lambda in a service changes the whole service is redeployed. This includes
It'd be great if functions that did not change were not re-uploaded and it'd be great if there was some sort
of diff algorithm to the serverless descriptor file to exclude some things from the SAM update. For some-one
not familiar with the underlying code this seems like a not-so-hard feature to implement. It also seems like a total killer feature so
I'm puzzled to why this is not implemented or even visible on the roadmap. Seed has this since quite some time for instance.
There's also an extension to this idea of incremental deploys : Now that we're in the world of immutability, we have git, we have docker-hub and all sorts of tools that avoids re-building or re-storing the same thing. So why don't we a registry for lambdas? For instance once a compiled lambda binary has been uploaded to S3 for one stage why does it have to be re-uploaded to another stage?
So my question is, is this planned for any near future or is this subject to important technical constraints?
Also isn't everyone impatient for this feature?
Beta Was this translation helpful? Give feedback.
All reactions