serverless: BREAKING - Support packaging and deploying artefacts as separate steps

Feature Proposal

Description

For CI / CD scenarios it is common to package and deploy software as separate steps. The package step generates artefacts and the deploy steps deploys those artefacts to different environments. This allows for scenarios like environment promotion ect.

At this stage we sort of have a package step with sls deploy --noDeploy. We might need to consider adding a command like sls package that performs the same task. I remember the discussion around the naming of --noDeploy. Having a separate command was discussed then.

The missing step is a sls deploy --package ./package.zip. This would deploy the package that had been created earlier.

Similar or dependent issues:

#2460 - This covers the same code base. We should wait until that issue is resolved first.

Additional Data

_Serverless Framework Version_: 1.0.2

About this issue

Original URL
State: closed
Created 8 years ago
Reactions: 29
Comments: 15 (13 by maintainers)

Most upvoted comments

@nicka it should include CF but it should also support other providers. This is how I think it should work

Examples

Scenario 1 - separate package and deploy

sls package generates the required files. For example:

|_ .serverless
  |_ cloudformation-template-create-stack.json
  |_ cloudformation-template-update-stack.json
  |_ your-service.zip

These files are zipped and stored as an artefact artefact.zip. This can be done by CI or could be done by serverless
sls deploy --package artefact.zip skips the package process, extracts the package to .serverless and deploys .serverless

Scenario 2 - normal and deploy

sls deploy generates the required files in .serverless and deploys .serverless

More thoughts

The implementation I am thinking of is not provider specific. It merely works which .serverless in different ways.

The reason why I would go with this is that as @gertjvr says, the package should not change between environments (except for environment variables).

I’m open to suggestions for improving this.

johncmckim on Oct 20, 2016

@johncmckim interesting proposal. I’ll have to think this through a bit and will come back with my opionion then in the next days.

flomotlik on Oct 20, 2016