This is the start of a series of posts to get you started with GitLab and GitLab CI.
In this first post we will explain what CI is, why use it and we will briefly explore a higher overview of the components that make GitLab and GitLab CI work together.
Let's dive in!
Martin Fowler described this approach in his article as:
Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.
The benefits of Continuous Integration are huge when automation plays an integral part of your workflow.
They are many applications in the field which try to tackle this practice. The majority of them are either closed source, making you rely on external sources (meaning a single point of failure), or need a lot of configuration just to set up, let alone the millions of plugins you have to install in order to bring it to your needs.
Would you rather have a CI service tightly integrated with your favorite code management tool with next to zero configuration? If so, you will love GitLab CI!
What started as a side project three years ago, has now become one of GitLab's key features. Back then, it was a separate application that talked to GitLab via webhooks. Now, starting from GitLab 8.0, GitLab CI has been fully integrated with GitLab itself. No more need to setup and maintain another application, which means less work for you or your Ops team.
GitLab CI is enabled by default on new projects, so you can start using its features right away. All you need is a file called .gitlab-ci.yml (where you describe how the build should run) placed in the root directory of your git project, and a configured Runner to perform the actual build.
Each project comes with a Builds page where you can follow the output of each build, see the commit that introduced it and other useful information such as the time the build started, how long it lasted and the commiter's name.
The statuses for each build are exposed in the GitLab UI and you can see whether a build succeeded, failed, got canceled or skipped within a single Merge Request or commit, or at the Merge Requests and commits pages.
Another win having GitLab CI integrated with GitLab is that people can see other users' CI/CD approaches and learn from them.
There is one last component without which, most of the features above wouldn't have been possible. It does all the heavy work by performing the actual builds.
Enter GitLab Runner.
GitLab Runner is the missing piece that leverages the power of GitLab CI. A Runner is responsible for the actual build and can be configured to be used with one or many projects. It talks to the GitLab CI API, reads
.gitlab-ci.yml, follows the steps defined in that file and sends the results to GitLab CI.
Some of the key features of GitLab Runner are:
As you can see, there is much flexibility on installing and configuring a GitLab Runner.
We will keep pushing forward in making GitLab CI a breeze to use and extend it to adapt to present and future technologies of the CI field.
Some notable features that we would like to see happening are listed in the issues below:
As always, you can visit our direction page and get a taste of the forthcoming features.
By now you should have an overview of what GitLab CI is and why you should start using it.
If you are eager to give it a go be sure to visit our quick start guide.
In the following posts we will explore how to use GitLab CI to test your projects in specific languages such as PHP.
Subscribe to our newsletter which includes links to our latest blog posts.