The course is part of these learning paths
What is CD?
What's Involved in Continuous Delivery
Getting Software to Production
The Complete Picture
Introduction to Continuous Delivery
There was a time where it was commonplace for companies to deploy new features on a bi-monthly or monthly, and in some cases even quarterly basis.
Long gone are the days where companies can deploy on such an extended schedule. Customers expect features to be delivered faster, and with higher quality. And this is where continuous delivery comes in.
Continuous delivery is a way of building software, such that it can be deployed to a specified environment, whenever you want to. And deploy only the highest quality versions to production. And ideally with one command, or button push.
With this level of ease for a deployment, not only will you be able to deliver features to users faster, you'll also be able to fix bugs faster. And with all the layers of testing that exist between the continuous integration and continuous delivery processes, the software being delivered will be of higher quality.
Continuous delivery is not only for companies that are considered to be "unicorns," it's within the grasp of all of us. In this course, we'll take a look at what's involved with continuous delivery, and see an example.
This introductory course will be the foundation for future, more advanced courses, that will dive into building a complete continuous delivery process. Before we can start in on trying to implement tools, we need to make sure that we have an understanding of problem we need to solve. And we need to know what kind of changes to our application may be required to support continuous delivery.
Understanding the aspects of the continuous delivery process can help developers and operations engineers to gain a more complete picture of the DevOps philosophy. Continuous delivery covers topics from development through deployment and is a topic that all software engineers should have experience with.
By the end of this course, you'll be able to:
- Define continuous delivery and continuous deployment
- Describe some of the code level changes that will help support continuously delivery
- Describe the pros and cons for monoliths and microservices
- Explain blue / green & canary deployments
- Explain the pros and cons of mutable and immutable servers
- Identify some of the tools that are used for continuous delivery
This is a beginner level course for people with:
- Development experience
- Operations experience
What You'll Learn
|Lecture||What you'll learn|
|Intro||What will be covered in this course|
|What is Continuous Delivery?||What Continuous Delivery is and why it's valuable|
|Coding for Continuous Delivery||What type of code changes may be required to support constant delivery|
|Architecting for Continuous Delivery||What sort of architectural changes may be required to support continuous delivery|
|Mutable vs. Immutable Servers||What are the pros and cons for mutable and immutable servers|
|Deployment Methods||How we can get software to production without downtime|
|Continuous Delivery Tools||What sort of tools are available for creating a continuous delivery process|
|Putting it All Together||What a continuous delivery process looks like|
|Summary||A review of the course|
If you have thoughts or suggestions for this course, please contact Cloud Academy at firstname.lastname@example.org.
Welcome back to Introduction to Continuous Delivery. I'm Ben Lambert and I'll be your instructor for this lecture.
When it comes to continuous delivery, a lot of discussions immediately shift towards the supporting software and tooling options. I've intentionally held off on talking about tooling too much because I didn't want to make it seem like continuous delivery is all about the tools because the tooling we use is to support people and practices.
However, now that we've talked about continuous delivery and what it is and why it's useful, also some of the things that are involved to support it, it's now time to review some of the tools.
We're not going to go into depth. This is gonna be a quick review to kind of highlight some of the tools that are out there that can help when building a continuous delivery process.
We'll start with some of the continuous delivery slash automation servers.
First up is Jenkins. You've seen it in this course. Jenkins is an open source automation server. It just released version 2.0 recently and has a lot of plugins available and has become my go-to for CI CD servers.
Next we have Travis CI. Travis is a CI CD server that has a very clean and easy to use interface and it also has a hosted version that allows you to focus on writing your code and not setting up a build server. That hosted version is also free for open source projects. So try it out for your next GitHub-based project.
Next, GoCD. GoCD is another open source continuous delivery server and it has a very intuitive pipeline view. After using it for a short time, you start to feel very comfortable using it. This is a great tool and one that I'd like to do a bit more with.
Next we have TeamCity. TeamCity is a proprietary CI CD server that has a free version for a limited amount of builds. I've had great experiences with TeamCity. TeamCity has a lot of functionality baked in and it runs on both Windows and Linux. I've only used it for Windows development, but it's a very capable platform and if you're going to use it for Windows development for .NET stuff, I highly recommend it.
Now this isn't an exhaustive list. There are a lot of similar tools out there. Some are well supported and others less so and when selecting an automation server, look for something that can be extended via some sort of plugins. As your project grows, your automation tasks will also and you don't want to outgrow your automation servers too quickly. So being able to create plugins will help to support any changes.
All of these options allow you to set up multiple agents so that you can run the builds on multiple operating systems or architecture or just parallelize your test running.
Alright, now let's check out some configuration management tools.
Configuration management offers the ability to manage your servers and infrastructure in a scriptable way. There's no shortage for configuration management tools and there are some great options and here's a few of them that I like.
First, we have Ansible. This has become my current favorite for Linux-based tasks. You define your tasks in a YAML playbook and combine and run these playbooks to have your servers managed. You can also run ad-hoc commands on a set of servers to patch things like security holes or update software. It does require Python to be loaded on the servers it's managing, which for the most part exists on Linux systems.
Next up is Chef. This is a Ruby-based tool. It uses a Ruby DSL to allow engineers to script out their tasks with a full programming language. Oftentimes this is an easier task for developers than those without a lot of experience writing code. Chef has been around for a very long time and has a very large community around it. So finding documentation and examples tends to be fairly easy.
Next, we have Puppet. This is a tool that allows you to specify the desired state of your server or infrastructure for that matter and tell Puppet to make sure that things match up with the desired state. Puppet has its own language and it's a bit different from languages such as Ruby or Python. The syntax looks more like a configuration file and may be easier for non-developers to pick up and run with.
Next up is PowerShell DSC. If you're on the Windows side of things, you can certainly use tools mentioned above, however, you can also use Microsoft's own desired state configuration tool. Now, PowerShell lives up to its name. It offers a rich set of tools for managing a Windows environment on the command line and PowerShell DSC takes that a step further and also applies that to Linux servers.
As I mentioned before, there are a lot of great tools out there. When selecting a configuration management tool, make sure you review your needs and the tools carefully. Investing a lot of time into one of them to learn that it's not right for you can be costly. For example, if you're a Ruby development team, then Chef may be a good choice for you because extending it when needed will be fairly easy since those skills already exist on the team.
Next, let's take a look at a couple of tools that will help if you choose to use immutable servers.
First up is Packer. This is a great tool by HashiCorp. It allows you to create different machine images from a single configuration. So you'll be able to generate a snapshot of a server that's based on some image, provision it with your latest software, and then save that image to a different format such as Amazon AMI or Azure VMs among others.
Next we have Spinnaker. Now I was tempted to include this in the automation server section we looked at earlier, however, because this is really about baking and deploying your machine images, I figured I would leave it here. This is a tool that has been open sourced by Netflix. It allows you to trigger builds in different ways including from Jenkins and then it takes your base machine image and installs your software on it. For this, it assumes the use of the operating system's package manager and bakes that image and saves it to your cloud provider. From here, it allows you to deploy to different environments. Now this is a very powerful tool and one that I recommend that you check out.
Since we talked about immutable servers, it's only natural that we talk about containers since containers are another form of immutable server. The use of containers makes the phrase "it works on my machine" a bit less rage-inducing because the development environment and production environment should be the same.
Containers will be a subject of their own course. However, for now I'll just mention a few container options without going into detail on what containers are or how they work.
First, we have LXC. LXC provides a virtual environment with its own process and network space with operating system level virtualization. It's been around for many years and has become a much more secure environment than it used to be. It basically allows you to have multiple virtual Linux environments all share the same kernel.
Next we have Docker. I'm not sure that you can make it through a day in the tech world without somebody talking about Docker. It's designed to allow developers to build in a container and then bundle up the container with their code and ship it off to a Docker repo and then deploy that same container to production. Now, Docker is a fairly new tool in the industry, however, it's gained a lot of excitement around it and that's because of its potential power.
Next we have Rocket. This is an interesting tool because it has a similar feel to Docker, however, it aims to address the security concerns around Docker. It's created and maintained by the core OS Linux team and looks like it's evolving pretty quickly.
So we've covered about a dozen tools and we haven't even scratched the surface. There are a lot of tools out there to help with implementing a continuous delivery process and there's no single right way to implement it.
In our next lecture, we're gonna walk through a continuous delivery process and talk about each step.
Okay, let's get started.
About the Author
Ben Lambert is the Director of Engineering and was previously the lead author for DevOps and Microsoft Azure training content at Cloud Academy. His courses and learning paths covered Cloud Ecosystem technologies such as DC/OS, configuration management tools, and containers. As a software engineer, Ben’s experience includes building highly available web and mobile apps.
When he’s not building the first platform to run and measure enterprise transformation initiatives at Cloud Academy, he’s hiking, camping, or creating video games.