It's time for the new Serverless Framework v1.12 release! Let's take a look at all the new features and improvements.
Note: You can find a complete list of all the updates in the changelog.
This long awaited feature has arrived! Serverless v1.12 introduces a way to separate the packaging step from the deployment of your service.
This gives you more control over the build process, which will also improve CI/CD usage in combination with the Serverless Framework.
Let's take a closer at look how we can use this new feature.
package command enables you to package all of your service artifacts and store them on your disk.
Running the following command will build and save all of the deployment artifacts in the service's
However, you can also use the
--package option to add a destination path and Serverless will store your deployment artifacts there (
./my-artifacts in the following case):
serverless package --package my-artifacts
The "simple" deployment process via
serverless deploy has not changed. It will still package all of your artifacts, store them in the
.serverless directory and deploy your service after that:
However, you're now able to use the
--package option to specify which package you want to use for deployment:
Note: This package needs to be created (e.g. with the
serverless package command) and available beforehand.
serverless deploy --package my-artifacts
Furthermore, you can set the path to the package directory in your
serverless.yml file like this:
package: path: my-artiacts
Serverless will now use this path automatically if you run the
deploy command without the
AWS recently announced support for Python 3.6 and added the corresponding runtime to their Lambda compute service.
Serverless has you covered and ships with a new
aws-python3 template you can use to deploy your Python 3 services to AWS.
Run the following command to generate a new Python 3 template:
serverless create --template aws-python3
You can also migrate an "old" Python 2 service so that it uses the new
provider: name: aws - runtime: python2.7 + runtime: python3.6
Just make sure that your code is compatible with Python 3 and run
serverless deploy to update your service.
serverless invoke local command was also updated so that you can emulate a Python 3 function invocation locally.
This update is a huge step forwards as it now supports Python, Swift, Docker and Binaries as runtimes.
Serverless Framework v1.12 adds the
openwhisk-swift templates to streamline this process.
Just run the following command to create a new Python template:
serverless create --template openwhisk-python
This command will generate a new Swift service template for you:
serverless --create openwhisk-swift
Curious how to take it from there? Take a look at the docs to learn more:
The SNS event source is now updated so that it supports CloudFormation intrinsic functions such as
This way you can e.g. reference other resources in your
Here's an in-depth example of what this looks like in practice:
functions: ingestFn1: handler: handler.hello events: - sns: topicName: myTopic arn: Fn::Join: - "" - - "arn:aws:sns:" - Ref: "AWS::Region" - ":" - Ref: "AWS::AccountId" - ":myTopic" resources: Resources: myTopic: Type: AWS::SNS::Topic Properties: TopicName: myTopic Subscription: - Endpoint: Fn::Join: - "" - - "arn:aws:sqs:" - Ref: "AWS::Region" - ":" - Ref: "AWS::AccountId" - ":mySqs" Protocol: sqs
Take a look at the SNS documentation for more information.
The separation of the
deploy command was a tough one since our goal was to introduce this change in a non-breaking way.
Frank Schmid worked really hard on new concepts around our core plugin system to help plugin authors deprecate and redirect lifecycle usages. This makes it possible to use both old lifecycle events and new lifecycle events alongside each other.
A huge thanks goes out to Frank for all his ideas and help here since these additions made it possible to introduce the package and deploy separation in a non-breaking way! (As a day-to-day Framework user you might not even notice a difference altough the whole system behind the scenes works entirely differently)
This release includes the option to show a warning message if a plugin hooks into deprecated lifecycle events.
Showing this warning message is disabled by default. You need to enable it by setting the
SLS_DEBUG=* system environment variable.
After setting this you'll see a message in the console every time your plugin uses an old lifecycle event.
We encourage all plugin authors to enable the debugging information and check whether their plugin uses old, deprecated lifecycle events.
You can see all the deprecated lifecycle events with the corresponding redirections Serverless introduces with v1.12 here.
Those lines of code also show how the redirection of deprecated lifecycle events works. So you can now use the same mechanism to deprecate your own plugin lifecycle events.
Want to know more about this topic? Read Frank's gist to learn why this was needed and how it works behind the scenes.
This release also includes bug fixes and introduces several enhancements.
Thanks for reporting bugs and opening issues!
This release contains lots of hard work from our awesome community, and wouldn't have been possible without passionate people who decided to spend their time contributing to make Serverless better.
Thank You to all of the contributors who submitted changes for this release:
Serverless has a really helpful, vibrant and awesome community. Want to help us build the best Serverless tooling out there?
Furthermore, we're always seeking feedback from our community to build the features in the best way possible. Here's a list with issues where we need your feedback and insights in your real world usage of Serverless.
We use our own Serverless open source tool called "Scope" to manage the Framework's development process:
Here you can see all the current discussions, to-be-reviewed PRs and recently closed issues and PRs.
You can use this status board to see all the important things currently happening in the Framework development phase.
The Serverless Examples Repository is an excellent resource if you want to explore some real world examples and learn more about what Serverless architectures look like.
Philipp Müns is a core developer at Serverless, Inc.