Chapter 11. Continuous Integration

In the previous chapters, we adopted a Test-Driven Development (TDD) approach to developing a backend API server, which exposes a user directory platform. However, there are still many areas for improvement in our workflow:

• We are running tests on our local, development environment, which may contain artifacts that lead to inaccurate test results
• Carrying out all these steps manually is slow and error-prone

In this chapter, we are going to eliminate these two issues by integrating with a Continuous Integration server. In essence, a CI server is a service that watches for changes in your repository, and then automatically runs the test suite inside a clean environment. This ensures the test results are more deterministic and repeatable. In other words, it prevents situations where something works on one person's machine but not another's.

By following this chapter, you will:

• Understand what CI is
• Integrate our GitHub repository with a hosted CI platform called...

Continuous Integration (CI)

On a large-scale project, you're going to have many developers working on many features, releases, hotfixes, and so on, at the same time. CI is the practice of integrating work from different developers continuously. This means merging code from feature branches into the dev branch, or from a release branch into master. At every integration point, there's a chance that the integration would cause something to break. Therefore, we must perform tests at these integration points, and only carry through with the integration if all tests pass.

We already do this in our current workflow, but it is done manually. By having automated builds and tests that detect errors in these integration points, it allows members of a software development team to integrate their work frequently.

By practicing CI, we can abide by the "test early, test often" mantra, and ensure bugs are identified and fixed as early as possible. It also means that at any point, we will always have a fully...

Integrating with Travis CI

Travis is an online CI service that installs, builds, and tests our project. Travis is free for open source projects and integrates well with other popular services such as GitHub. There's also nothing to install—all we have to do is include a .travis.yml configuration file at the root of our repository, and configure the repository in Travis's web application. Travis has a very shallow learning curve and can save us a lot of time. To get started, go to travis-ci.org and sign in using your GitHub account.

Note

Travis has two URLs travis-ci.org, which is used for open source projects, and travis-ci.com, which is used for private projects. Make sure you're using the right one.

It will ask you for many permissions; these permissions are required for Travis to do the following:

• Read the contents of all repositories associated with your account: This allows Travis to view the content of the .travis.yml file, as well as to be able to clone your repository in order to build...

Continuous Integration with Jenkins

Now you know how to integrate with Travis CI, and know what you can expect from a CI server, let's try to replicate the same results using Jenkins, a self-hosted alternative. We have chosen Jenkins here because, at the time of writing, it is the most popular CI tool, with over 1 million users and 150,000 installs.

First, we will give you a brief introduction to Jenkins, and then we'll install and integrate it with our repository.

Introduction to Jenkins

While Travis is purely a CI server, Jenkins is much more powerful. Generally speaking, Jenkins is an open source automation server. This means it can automate any processes that are tricky to do by hand, either because it is repetitive, time-consuming, prone to human errors, or all of the above. For example, we can use Jenkins for the following:

• Building/packaging applications
• Dynamically generating documentation
• Running pre-deployment E2E/integration/unit/UI tests
• Deployment onto various testing environments...

Summary

In this chapter, we have integrated our project with two CI services—Travis and Jenkins. With CI, we are able to trigger tests to run after certain events and automate the testing of our app. We have also used Docker to provide an isolated environment for our tests, ensuring our tests remain reliable and repeatable. In Chapter 17, Migrating to Docker, we will even migrate our entire deployment to using Docker.

In the next chapter, we will learn how to secure our application by implement authentication and authorization checks in our API.