DevOps: A Simple Continuous Integration Tutorial

The software industry is complex, and so is the software itself. Because of this, working on software is hard unless you apply some modern techniques to cool things down. In recent years, the industry experienced a boom of methods aiming to make development simpler, cleaner, and faster. One of the most important is Continuous Integration or CI. This is a  good starting point for any self-made developer who wants to achieve his goals. In this Continuous Integration tutorial, we will see how you can apply CI to your project in minutes.

Before CI: Git

Before we start this continuous integration tutorial, we need to talk about git. Git is a standard protocol that allows developers to upload the source code to a common “cloud” the team can access. Imagine you are working on an Excel document with several people, you can put it in Google Drive to share it with your team. Git allows you to do the same thing, but with the source code. Plus, since it is specific for coders, it has some cool features you’ll love.

The common “cloud” the team can access is the repository. Unlike a standard hosting platform, git repositories have a good system of file versioning. This allows many people to work on the same files at once, without creating conflicts. How does it work? The entire codebase (all the files) is in a branch, known as the master. When you want to work on them, you create a new branch from the master. This branch now contains the same files of the master, it is a copy. You can now work on the files without changing the ones on the master. Once you finish, you can merge your branch back into the master. At the same time, other developers may do the same things on other branches.

You can create a branch from any other branch, indefinitely. Thus, you may make a branch from the master, and then a new one from this other branch.

Git also keeps track of changes to files, so every time you will merge a branch back it will verify there are no conflicts. In fact, the original branch may have been modified by other developers why you were working on your branch.

I am a solo developer: do I need git?

Yes! Any developer worth that name needs git. This Continuous Integration tutorial is for you as well. In fact, having a git repository allows you to keep track of changes and roll back in case you have issues. You simply can’t do Continuous Integration without git, CI relies on that. Furthermore, if you will expand your team later you will be already set.

Okay, how can I get git?

Git is a standard framework, which relies on two things: the repository and the client. The repository hosts the files and handles branches and other cool stuff, while the client is on your PC. The client allows you to fetch the code or upload it to your repository (push). Of course, you need both. Below a quick guide to help you choose.

This is a continuous integration tutorial, so we will only see the continuous integration part. We won’t go deeper on Git here.

Continuous Integration Tutorial

What is Continuous Integration?

ToughtWorks has a clean definition of Continuous Integration (read more here).

Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.

Let’s try to break it down. First, integrating code into a shared repository means you will upload your changes to the branch you are working on. Instead of keeping everything on your PC, and pushing code to the branch once you finish, you should push to the branch even several times a day. Now, the other cool part is the verification with the automated build.

With an automated build, a specific tool attempts to get the code from your branch and build it for a release. It then logs the results, indicating if this was successful, or – if not – what were the problems. In other words, every time you push code to your branch a tool will check if the code is okay. At this point, you may think tests should always be successful, but they don’t. They allow you to keep track of problems, but you may want to solve these problems later. This is up to your team.

What are the benefits of Continuous Integration?

Continuous Integration is there because it provides benefits. As part of this Continuous Integration tutorial, it is important we understand the benefits it brings to the table.

• Testing early and often allows you to avoid last-minute chaos when you are close to a release date
• You can detect integration bugs earlier when they are small and easy to correct. An integration bug is a bug caused when joining together two parts of the code that do not integrate as expected.
• In case you need to revert back to a previous state of the branch, you can do that by loosing only little code
• The up-to-date build is always available for tests and demo
• Forces developer to create less-complex and modular code

To put it simply, it allows you to have a more predictable development process.

Continuous Integration in practice

The goal of this Continuous Integration tutorial is to show how you can use CI in practice. Pushing your code to the repository several times a day is easy, and you can do that with no training. However, automated tests are not so immediate to grasp. To run automated tests and builds, you need software that is able to do that. This software will check the git repository (like a developer!) and when it sees changes, it will start the process. In other words, this software is tracking branches.

It may be worthless to track a branch that is short-lived, or where you know commits are only temporary states and building with their code will be a sure failure. However, a common practice is to have two main branches:

• The master is the branch which should almost reflect the production version of the software, it should receive updates only when they are ready to go in production
• The dev branch is the “beta of the new version” branch. It contains incremental changes to the production branch (master), it originated from it and it will merge from it.

You should create feature branches from the dev branch, never from the master. Thus, it will be worth to have CI tests and builds run when you merge a feature branch back into dev, and when you merge dev back into master.

Tools for Automated Builds

Okay, how can we make automated builds and tests? Git providers won’t do that on their own, we need to have a tool for that. Probably, the most famous CI tool is Jenkins, which is also open source. You can install it virtually anywhere, even in a container. Then, you can configure pipelines, a cool name for sequences of tasks. Such sequences will include tests and builds. Since Jenkins can run CLI commands, it can do pretty much everything it needs to automate the build of the code.

Furthermore, it has a clean graphic interface you can access from the web that allows you to have a good overview of the situation.

Other tools also exists. For example, if you are using VSTS as your git repository, you can benefit from the “in-the-cloud” pipelines hosted by Microsoft. You even get some computing power for free! However, these are well-integrated for Microsoft languages like C#, while they need a little bit more tuning for other languages like PHP. Nonetheless, they work well and Microsoft is quickly improving on this product.

Wrapping it up

In this Continuous Integration tutorial, we presented what CI can do for you, and where you can get the tools to start. Now you are able to create a simpler and less stressful development process, thanks to more integrations and automated tests.

What do you think about Continuous Integration? Do you see improvements in using it? Let me know your opinions in the comments!