Continuous Deployment explained in code

Table of contents
Text Link
October 6, 2020
|
Continuous Deployment

Continuous Deployment explained in code

Go from zero to one hundred deploys a day.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Continuous Deployment explained in code

October 6, 2020
|
5:18
Continuous Deployment

Continuous deployment is, in a nutshell, when the code is pushed to master your target branch, automated processes take it all the way to your target deployment. Now, ideally that's production, but more often than not, that's a staging or testing server.

Let me show you how we use continuous deployment to create Sleuth, my company. At Sleuth we use Circle CI for RCI, or continuous integration. Within the Sleuth codebase is a directory called.circleci, and inside of it is a file doc called config.yml, and that contains our CI and CD workflows. So, let's jump into this file and take a look at what's involved.

First, we define a workflow that runs on every push to a branch not named master. When triggered, this executes a few jobs you'd expect, such as running tasks or building a Docker image. These jobs are defined elsewhere in the file. For example, run-tests is defined up here to run our tests and then take the output of those tasks and save the test files or screenshots. As you can imagine, by adding a few more jobs, we can now implement full continuous deployment, and that's exactly what we do.

So, let's take a look at our build and deploy workflow. Here, we're doing what we were doing before, running the test, building an image, but now, we also deploy. Now, the eagle-eyed among you will notice, we actually only automatically deployed a staging. This configuration tells Circle CI to pause and wait for manual approval, and then once given by the web UI it then will continue with the deployment and actually deploy it down to master. So, let's take a look at what happens inside of this deployment.

So, you can see it's actually not that complicated. We do some setup and then we actually run our deployment. Now, in the setup is a thing called setup-aws-credentials. Inside of Circle CI, we store secrets that will allow us to access API keys and things like that, so that we can make the necessary AWS CLI commands. So, if I jump into that command, the set-aws-credentials, what you can see is it's taking these environment variables provided by Circle CI, and then it's configuring AWS so that it has all the right information.

Going back down into our release, you can see that we up some versions with some timestamps, and then down here, we actually deploy the file using a framework called Fabric. The fab file is executed by a Python automation tool called Fabric, so let's jump into that fab file. So, we'll go out of the Circle CI directory, and we'll jump right into our fab file.

In our fab file, we created a command called deploy. Notice the matching parameters that we passed in from the command; the sha, the tag, and the environment. Now, Sleuth uses Amazon Fargate to deploy our services, which basically means it runs inside Docker containers. To deploy our app, we simply change the latest tag, Docker tag, to point to the new Docker tag containing our new version.

Now, before we do deploy the app, we also need to run any database migrations, and that's what's happening down here. So, we set up a special fargate task, run a database migrations using the new Docker container. Then, we tell fargate to restart Sleuth, and it's the web and the worker processes. Fargate will do what's called a "rolling deploy" where first it stands up the new version, points traffic at the new instances, drains a connection from the old, and finally shuts down the old containers. When that succeeded, Sleuth will then tell... Well, because after all Sleuth is a deployment tracker, and so we want to tell Sleuth itself about the deployment, so we can visualize our deployments, see what's happened, check their health, things like that.

And that's it. Continuous deployment from beginning to end in a few lines of YAML in Python. Now there is so much more we could talk about regarding continuous deployment, from the types of tests you need to have, the types of coverage, and how continuous deployment changes your business processes, your testing, QA processes, all that sort of thing, but we'll leave that for another day.

If you'd like to learn more about how to track your deployments and their health across multiple environments, check out this video right here on Sleuth. If you want to learn about mistakes to avoid with continuous deployment, check out this video right here, the very first video I ever made. As always, like and subscribe for more tips, and let me know in the comments down below about anything I missed.Adopting continuous deployment is like starting a diet. We all want to do it. We're not sure what it entails, but we will totally do it tomorrow. Well, I can't help your procrastination, but I can help explain, in code, not pretty graphics or lots of talking- Okay, maybe a little bit of graphics here, what continuous deployment is and how to get started, for tomorrow.

Go from zero to one hundred deploys a day.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.