If the application is built on top of SAM, then all of the tooling is already in place for automated deployments. You can orchestrate this with CodePipeline, which can essentially pull your code (from the code repository), pull down the required packages, create the deployment package, and build the application. You can test the application using third-party tools that are natively supported by CodePipeline.

You can use the power of SAM to deploy in multiple environments. The problem here is that there is an immediate switch from the old to the new version of the code. And that is not how we usually deploy in production (see blue-green deployment in Chapter 7, Deploying to Production and Going Live). Usually, we incrementally roll out new versions to help reduce deployment risks.

However, you can do safe deployments with SAM. Lambda aliases now enable traffic shifting that is you can point an alias to two different versions and shift traffic between them using preassigned weights. Alias is essentially a pointer to a version. With weighted aliases, you can actually publish a new version and add it to the alias with percentages defined for each version. You can divert 5% of the traffic to the new version while 95% continues using the earlier version.

You also automate the deployment process using CodeDeploy. It comes with preconfigured canary and linear deployments (that is, you can linearly increase traffic as time progresses). It provides guardrails for safe deployments, for example, autoalarm-based rollbacks; pre- and post-traffic validation hooks (that is, test hooks as Lambda functions and can run before or after your traffic has shifted to the new version). You can easily monitor the deployment using the CodeDeploy console.

As SAM is natively supported, you just need to add a few lines to the SAM template for safe deployments. You can define function configurations for all the functions in the SAM template: tags, runtime, and other essential things that are common across all your functions. This is useful to define the deployment strategy for all the functions in the application at one place rather than for each function, separately. Next, you have to include a line for creating the alias (that autopublishes a version with each deployment). Lastly, you can define your deployment preferences with respect to the kind of deployment you would like to execute. For example, shift 10% of the traffic to the new version, if all goes well, then after 10 minutes shift all the traffic to the new version.

For test hooks and alarms, you can define pre- and post-traffic hooks (lambda functions that run as tests), they succeed or fail and accordingly they communicate back to CodeDeploy (so it knows how to react). The alarms can also be defined easily using the alarms construct within SAM. If any of the alarms are triggered during deployment, then that is going to prompt a rollback to the earlier version. It's easy to monitor through the CodeDeploy console.