The first and most basic method is to deploy everything at once. This includes the infrastructure (such as Lambda, API Gateway, and DynamoDB), the function code, and any configuration that's required. This is the pattern we have been using throughout all the examples in this book.
The good thing about the Serverless Framework is that, if you already have a whole stack deployed, the framework will update the deployed CloudFormation stack instead of deploying an entirely new environment, provided you are deploying to the same stage. CloudFormation can then make a decision about which parts of the template have changed and update the resources accordingly. It also knows how to handle updates for each service, for example, if the change to the resource needs a whole redeploy or an in-place update.
The key thing to get right in this and all the other patterns is to make sure rollbacks work. Test your rollback strategy from time to time to make sure the process goes to plan. But how do you know when you need to do a rollback? It would be an obvious case for a roll back if a deployment doesn't make it all the way to the end, but crucially what we're looking for here is a key metric that will prompt us to fail a deployment. Your deploy process might have made it all the way to the end, only to find out that the error rates for logins to your product are significantly increasing. This could be a sign that the version you deployed is adversely affecting another service, so you should use this as a trigger to fail and roll back your deployment.
In this case, we need to add a monitor component to our diagram:
It's a good idea to use your application performance monitoring tool to watch application-level metrics. This will provide additional confidence of a successful deployment above the usual infrastructure and log monitoring capabilities.
As we mentioned previously, if a deployment goes wrong for any reason, there could be a redeploy process, which may involve an outage to a service while it takes place.
A less risky method is to make sure our entire environment deploys properly by testing it out of band and then switching to it.