In the previous section, we briefly introduced the concept of Serverless Framework stages and how they work. Well, it turns out that stages are a great way to logically and physically separate our environments. Stages are really useful for deploying the same infrastructure, configuration, and code multiple times. Naming a stage is a completely arbitrary endeavor; the framework doesn't care if you call a stage dev instead of scott. This gives you the flexibility to use stages in a way that best suits your team or organization. On the flip side, because stages are so flexible, this means you should probably think about how you also implement governance so that your development standards are being followed. 

The framework is also extensible in that you can use the stage you specify as a variable to set other configurations. For example, in your serverless.yml file, you can set variables for where to find the relevant credentials for that stage. The following snippets show some of these options:

provider:
 name: aws
 stage: ${opt:stage, 'dev'}

functions:
 hello:
   handler: handler.hello
   environment:
     MY_SECRET: ${ssm:/path/to/service/mySecret}-${self:provider.stage}

The preceding example takes the stage you provide on the command line using the --stage option. If you don't specify this option, then it defaults to using dev. In the function declaration, we are setting an environment variable called MY_SECRET for the function called hello. The value of the secret will be pulled from the Systems Manager and it will be a different secret depending on the stage.

Let's talk about best practices. In my experiences, it has been valuable to use stages as part of the production API versioning strategy. Name your stages so that they align with non-production environments, for example, dev, uat, and so on, so that entirely new CloudFormation stacks are deployed for each environment. When it comes to production, this is where you would want to name stages so that they align with the current major version of the interface specification, for example, v1, v2, and so on. By doing this, we can still maintain our agility when we need to move clients between versions. We're not forcing our consumers to update their implementation of our API all the time, and we're also not requiring our developers to release things that are always backward-compatible.

So far, we have learned about CI/CD patterns and how we can implement them with features from the Serverless Framework. In the next chapter, we will explore the various options for rolling out code, and see which method might work best for our own deployments.