Continuous deployment is the principle of continuously shipping code into production and takes continuous delivery a step further. If all of the automated tests pass during our integration testing, then that piece of code or artifact should be immediately released into a production environment. The premise behind this is that, as soon as our tests pass, then there should be no reason why we can't make that new feature or fix available to our customers.

Often, people will use the continuous deployment and continuous delivery terms interchangeably, but the difference is that continuous delivery often requires manual intervention, for example, an approval step or a task to manually kick off the process. 

Let's take a look at serverless pipeline patterns. A traditional CI/CD pipeline would consist of four stages:

Here, the build is performed and tested, the artifact is created, and then it's deployed. Some additional smoke tests may be performed as well to validate the deployment. For a pipeline that handles serverless projects, we may view the process slightly differently. Because we don't need to pre-provision our infrastructure to deploy to, creating a new environment altogether is relatively stress-free. Our unit of deployment is always infrastructure + configuration + code. This means we might deploy the function code, infrastructure, and configuration all at the same time, test it, and then get rid of it. This may look something like this:

We could also prefix that with a local testing stage and wrap some monitoring around the whole process. What happens in our build stage depends on the language we are using. If we're using a non-precompiled language such as Node.js or Python, then our build step would consist only of installing our dependencies and packaging those up with our function code and Serverless Framework configuration. For a compiled language such as Java, our build environment would need to be able to support a build automation tool such as Maven or Gradle. These tools describe how the application is built and manages all the dependencies that are needed.

The next part of the process is the first testing step and includes basic syntax checking or linting of the function code, checking against any coding standards we might be aligned to, and of course our unit tests. It could also include code security testing if your organization requires it. After our tests pass, we can deploy our serverless project to a new stage.

At this point, you will need to know the strategy for how your organization or team uses stages within the Serverless Framework. These stages are so flexible that you can make use of them how you like, and in the next section, we'll explore some best practices. 

When we have a new infrastructure that's been configured correctly and deployed our code, we should be able to run our integration tests to test end-to-end functionality. We may also choose to do some performance benchmarking here as well. If all of these tests pass, then we can terminate the environment and report back on the results. 

Then, we can deploy to the stage of our target environment. What I mean by this is that if we are looking to deploy a branch to the development environment, our CI/CD process will create a brand new environment and run through all of the tests. If the testing process was successful, then we can safely deploy our change to the development environment and throw away the other one. If the testing fails, we don't need to run a rollback. In this approach, we are adding extra stability to the development environment because, by the time our change reaches the environment, we are already comfortable that it will deploy okay. 

For production, we might not have the luxury of spinning up a similar environment. In this case, we can be confident that our code has been through multiple environments already, so the risk of a deployment failing is lower. If the deployment does fail, a rollback can be performed by either deploying the last known-working artifact again or running the sls rollback command (which has the same functionality).

In the next section, we will introduce a mechanism that allows you to move code through the environments in your software development life cycle.