Welcome to Tools of Continuous Integration. After watching this video, you will be able to describe how the Jenkins tool works, describe how the CircleCI tool works, and describe how the Travis CI tool works. Jenkins, the oldest of the three tools, implements both Continuous Integration and Continuous Delivery. It used to be the cream of the crop in this space. One of the things that made it so popular was that it is open source, and you can run your own Jenkins servers. Jenkins has a large ecosystem of plugins to integrate with other tools such as Docker, Jira, and Maven, but the downside is this means there are many plugins to manage. You have to spend a lot of time making sure that all the plugins are up to date and secure, as well as compatible with all the other plugins. It describes the CI pipeline using the ‘Groovy’ language in a Jenkinsfile. This requires users to understand a bit of Groovy to use it. The Jenkinsfile enables developers to treat their CI/CD pipelines as code, as you can see in this short example. It describes a simple pipeline with two stages to check out and test the code. To implement Jenkins into your workflow, you first need to set up your project on the Jenkins website. This is a drawback. As you will see, other tools allow you to specify a pipeline simply by adding a file to your repository, making them very repeatable. Requiring you to use a website for some configuration means manual steps that are not automatable and may not be reproducible. There are two ways to use Jenkins. We’re going to cover the Jenkins Pipeline workflow. To set up your repository for Jenkins Pipeline, you need to create a Jenkinsfile to specify the CI instructions and place it in the root of your project repository. These instructions tell Jenkins how to run the pipeline to build and test your code. Jenkins can build your code in a virtual machine or inside a Docker container. You can also specify what actions trigger a build. Unfortunately, you can’t do this in the Jenkinsfile; you must configure this on the Jenkins server using the user interface. You can specify to execute a build when you push to the master branch, whenever you issue a pull request, or on the occurrence of many other events. Now let’s take a look at a realistic example of a Jenkinsfile. This example Jenkinsfile runs unit tests on a Python project. It has four stages. When Jenkins is notified by a webhook, it runs through the Jenkinsfile. At the top, it sets up the code to run in a Docker environment. The pipeline first checks out the code. The next step in this pipeline installs any specified Python package dependencies. Next, it lints every Python module in your code. This means it goes into your code and checks that it follows best coding practices. And lastly, it runs unit tests on your code. The process is straightforward and works similarly in other CI tools. CircleCI is provided as a service, and implements both CI and CD. Because it’s a service, you can’t run this on your own server like you can with Jenkins, and it’s not open source. It enables developers to treat their CI/CD pipelines as code, which is a common theme you’ll see with all these tools. Similar to the Jenkinsfile with Jenkins, CircleCI uses a YAML file to specify the CI process, as seen in this short example that checks out the code, installs Python package dependencies, and runs some unit tests. The advantage of using YAML is that it is easily readable by both humans and machines and is a very popular format for configuring systems and services. To implement CircleCI into your workflow, you need to first set up your project on the CircleCI website. Unfortunately, this is a manual step. To set up your repository for CircleCI, you need to create a config file to specify the CI instructions. These instructions tell CircleCI when and how you want your code built. It can build your code in a virtual machine or inside a Docker container. You can also specify what actions trigger a build. You may see a pattern emerging; all of these tools in this lesson support both native and Docker builds and specify the pipeline instructions as code, like in the Jenkinsfile in Jenkins. So, let’s take a look at an example circle.yaml file. CircleCI natively supports languages such as Closure, Java, JavaScript, Python, PHP, and some others. It also supports databases such as MySQL, MongoDB, and Postgres. And since it supports Docker, anything you can build in Docker, you can build with CircleCI. This section of the YAML file asks CircleCI to get a Docker Python image and sets an environment variable for the database URL. The next section sets up PostgreSQL and several environment variables to configure Postgres. Once the environment is set up, it checks out your code, installs packages, and runs tests. Clearly, you can see a pattern in how both Jenkins and CircleCI work. Travis CI is just like the other two tools; it implements both CI and CD. Like CircleCI, Travis CI is a hosted service, which means you cannot run it on your own servers. It’s only available as a service. You can, however, get an enterprise license and run it internally in your own company. Also, like CircleCI and Jenkins, you must set up your project first in their admin UI, which is a manual step. It enables developers to treat their CI/CD pipelines as code. Unlike CircleCI, it supports many more languages and databases natively, as well as Docker, so you can really run anything with Travis CI. And like CircleCI, you use a YAML file to specify the CI process, as you can see in this example that requests a Python 3.9 environment, installs dependencies, runs unit tests, and uploads the code coverage. That’s a lot of functionality for a little file. To implement Travis CI into your workflow, you first need to set up your project on the Travis CI website. This is a manual step, but unlike Jenkins and CircleCI, Travis allows you to enable it for all of your repositories, so it only has to be done once for all of your repos. Next, to set up your repository for Travis CI, you need to create a .travis.yml file and place it in the root of your repository. These instructions tell Travis when and how you want your code built. You can build your code in a virtual machine or in a Docker container. Like the other tools, you can specify what actions trigger a build, but unlike the other tools, this is not done in the .travis.yml file. It can only be done manually from the Travis CI admin UI, just like Jenkins, which is a drawback. As you can tell, each of these tools provides a means to reach the same goal: enabling Continuous Integration of your code. Let’s take a look at an example Travis YAML file. Like the other two tools, the .travis.yml file defines the instructions to run the build. The top of this file specifies the language to use to build the code. Then, it requests a PostgreSQL database, sets an environment variable to the database URL, and provisions a test database to run the tests with. After that, it installs the required Python dependency packages. Once the environment is set up, this script then tests the code. And finally, it collects and uploads the test results to Codecov.io. This is a very simple example, but it shows that it doesn’t take much to automate Continuous Integration with Travis CI. There is one more tool we didn’t mention in this overview, and that’s GitHub Actions. GitHub Actions is a CI/CD tool that is available in every GitHub repository. It is integrated into GitHub as a service. It allows you to fully treat your CI pipeline as code, and is controlled by YAML files. GitHub Actions will be covered in more depth in subsequent videos, and it will be the tool that you use in this course. In this video, you learned that there are many automated CI tools out there with different pros and cons, and most of them have similar characteristics, each of these tools provides CI pipelines that can be written as code, enabling automation and repeatability, and tools such as CircleCI and Travis CI are offered as services so that you don’t have to worry about managing them.
