Sls package/deploy improvement ideas


#1

I just wanted to open some discussion on the serverless deploy feature. We are using it to deploy our solution to multiple different environments. Our use case is quite a simple one. We are having most of our resources (S3 buckets, IAM roles, etc.) separated from the sls and we are using sls mainly for deploying lambdas + API gateways.

Our solution has grown up and now the deployment is starting to get too slow. I was investigating where does all the time go and I noticed that sls deploy runs npm install command during deployment. Why? Why isn’t there a way to skip that? We build our deployment package before the deployment so we can run all unit tests etc. This requires all the dependencies to be on place. That’s why it’s difficult to understand why sls deploy does the same thing without a possibility to skip it. In my opinion the deployment package shall not be touched at that point anyhow if we talk about pipeline thinking, right?

Another use case we’d like to have is a possibility to build an universal deployment package. Currently there’s no possibility to do it like this. If there was a possibility to give the environment variables as a parameter for the deployment (e.g. json file containing all the required parameters) that would solve the issue completely and support the pipeline thinking so that the same deployment package can be deployed to multiple different environments.


#2

Are you using the --package option when running sls deploy? If you aren’t using it that would explain why Serverless is rebuilding the entire package.

The serverless deployment package consists of the code and the Cloud Formation template. I don’t believe Cloud Formation supports variables inside the template (but I could be wrong). Requests to change the way it works are best raised as an issue on Github.