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.