Lesson Outline

Continuous Deployment

In this lesson, we are going to look into setting up Continuous Deployment and - again - this isn't something that you have to do. For some projects you might decide that it doesn't provide any real value, for other projects it might provide tremendous value.

Continuous Delivery (CD), and similarly Continuous Deployment, are also terms that are a little bit slippery to define. Not everyone is going to agree on what they mean, nor what the difference between delivery and deployment is. We are going to get into the specifics of that in a moment, but the key point is that CD is the final step in the workflow we have been setting up. This is the step that will result in our application running somewhere where we (and potentially our clients/customers/users) can actually use it.

One important thing to note for Ionic developers is that Ionic's AppFlow product is a great way to manage the entire CI/CD process, especially if you want to deploy natively to app stores. I will likely add a complete module on AppFlow at some point, but this module is just going to focus on publishing an Ionic PWA to the web using Netlify.

A Brief Introduction to Continuous Delivery (or Deployment)

This module has been littered with terms and definitions that don't really have a 100% accepted definition. The terms Continuous Delivery/Deployment will often be used interchangeably (perhaps incorrectly), but for our purposes in this lesson let's take the following definitions:

• Continuous Delivery: An automated release process that will allow easily deploying new code changes live to a testing/production environment
• Continuous Deployment: The same as Continuous Delivery, except all changes that successfully pass through the CI/CD pipeline will automatically be deployed live to a production environment (no manual review step between build and deploy)

If you are going with a Continuous Deployment process then you will definitely want to make sure you have a rather robust Continuous Integration process defined. Any code that makes it into your production branch is going to be deployed for users to use automatically, so you want to be quite certain that the code that makes it to that point is good to go. If you don't have a robust suite of automated tests defined that are run as part of your CI Builds, or governance controls/processes that determine who is allowed to merge code, then using a Continuous Deployment approach may not be wise.

We have been creating a rather simple Continuous Integration process in this module. We have CI builds being created to run our tests against code that is pushed to the repo, but we don't have any governance controls in place to actually stop failing code from getting into the main branch. Nor do we have restrictions that require approvals/reviews before merging code into main.