Introduction to continuous deployment

In this video we're going to take a high-level look at continuous deployment and how it works.

CD is the process where we push code changes to a remote server, build the app on the remote server, then run our unit and e2e tests on it.

If the tests pass, the code changes are then pushed to a production web hosting service or platform where they will be made available to users.

The main advantage of CD as a deployment workflow is that it helps ensure the integrity of the live app as new code changes are introduced. It does this in two main ways...

Firstly, CD allows us to bundles all the deployment steps, including checking out of the code, installing dependencies, setting environment variables, copying files and so on.

This means we no longer have to rely on developers remembering to do all this on each deploy, and will therefore minimize human error.

Secondly, CD will only complete a deploy conditional on the app building and tests passing. So, if a developer updates the code and the app fails to build or the tests fail to pass, the pipeline will abort before the deployment process begins, preventing developers from pushing any bugs into the live app.

The CD workflow

Let's now talk more specifically about how we can use CD for deploying PrintBay.

Once we've set up our pipline, we can commit a code change to a special deployment git branch, then push it to the CD server. This push triggers the various jobs we've set up, collectively known as the CD pipeline.

The first stage of the pipeline is to build the app inside a virtual machine on the CD server.

The second stage is to run all the tests, including both client and server unit tests, and the E2E tests.

Finally, the CD server will initiate a deployment of the app to our production server.

CD services

The easiest way to get started with CD is to use a Continuous Integration SaaS product.

We're going to be using GitLab CI in this course, but there are similar products including Circle CI, Bitbucket Pipelines, and many more. You can even set up your own CI service on your company servers.

GitLab CI is good for us in this course, because we're using GitLab to host our source code, and the CI service is closely integrated with this as you'll see shortly.

YAML file

The GitLab CI server doesn't know how to build our app, or run our tests, or where to deploy our app, so we need to create a YAML configuration file telling it how to do all this.

If you've never used the YAML format before, it's a declarative file format that makes configuration easy. You can think of it as a short-hand way of writing JSON.

On the screen you can see the completed YAML file that we'll be creating over the duration of this module. Despite not being too long, this file contains all the information needed for a fairly robust CD pipeline.

CI vs CD

Before we finish this video, let's answer a question that may be on your mind - what is the difference between CI and CD?

Well, these are two closely related but distinctly different workflows.

We've just seen how continuous deployment is a workflow that helps us in deploying code.

Continuous integration is a workflow that helps us with integrating code. For example, say you have multiple developers working on a feature from the same code base. CI helps the team leader or maintainer ensure that merge and pull requests are prevented untils the code change can be successfully built and the automated tests pass.

So could you use both a CI and CD workflow together? Absolutely, and I'd highly recommend that for an enterprise app. The only reason we aren't covering CI specifically in this module is that it's pretty useless when you only have one developer working on a repository as we currently do. You need multiple developers to get any benefit from it.

Rest assured, though, the skills you learn in this module in setting up CD will allow you to easily set up CI for your development team as well.