GitHub to GitLab (r)Evolution

Continuous Integration ?

What it is not

What it is

A method of finding software bugs and defects as early as possible in the development cycle.

Something that can be bypassed because it takes too much time or effort.


Average test time: 1h30

Wait time: 0 to 4h

No distro matrix

Time wasted during provisionning

Solved by executing tests on a pre-built binary image, either by maintaining custom scripts, either OOTB with and gitlab-ci

Time wasted while waiting in queue

Solved by maintaining a CI infra with parallel build slots
Must grow continuously

CI Systems Landscape

  • Jenkins
  • Buildbot
  • CruiseControl
  • TeamCity
  • Travis
  • Strider-CD
  • GitLab-CI
  • CircleCI
  • Codeship
  • Travis

Can 1 CI rule them all ?

Perhaps, if it meets all requirements of all projects:

  • Sends feedback to the git tracker UI
  • Test matrix
  • Programable pipeline
  • Does not require maintenance
  • Is able to run on pre-provisioned systems
  • Does not require waiting in line
  • Can run on our VPN



Dedicated box



+ no maintenance

- shared CPU: how secure ?

- shared RAM: how much ?

- shared bandwidth: how much ?

- developers waiting: how long ?

- closed source

- paid option for container cache

- cache over network: slow

- highly expensive


+ maintained by a hacker*

* that you already have when you need 48 executors of CI !

+ dedicated CPU

+ dedicated RAM: 256G

+ dedicated bandwidth: 1Gbps

+ CI *jumps* on patches

+ container cache on host

+ triple 1TB NVME SSD: fast !

+ super cheap
+ best ROI
+ Open Source

nomatch :)

Feature story

  • User runs tests on patch
  • Commits pushed in branch
  • User waits for a turn in CI
  • User waits for code review
  • Approval is manual
  • CI runs tests on patch (again)
  • User rebases branch
  • User merges OR
  • User rebases branch again
  • User commits on branch
  • CI tests on the user machine
  • Peers approve the patch
  • User clicks rebase and merge



Extra Automation

In GitLab, User can also click to enable merge when CI and approvals validate the PR


Merge Methods

Fast-forward merge 

No merge commits are created and all merges are fast-forwarded, which means that merging is only allowed if the branch has been rebased.
When the branch has not been rebased, the user is given the option to do so.

Git Hooks

Private container registry

Of course, for CI pre-provisioning !

Also: deployment pipelines

Distributing CI on developer machines

  • The developer machine needs to be able to run tests exactly like in CI
  • Why not publish the result directly ?

GitLab CI


Public Repository

Push commit

Request test execution on runner

Fork, register runner for fork

Publish runner logs and result


Fork Project

Optionnal step, allowing me to run my own dedicated CI on my laptop, otherwise I can push in a branch of the main repo like on GitHub

Get the runner token

In my fork, settings:

Register runner

(Developer machine)

Git Push,

CI Started

Build history for commit anyone ?

On GitHub UI, only the last build is shown for 1 commit

No time wasted while waiting in line

No test on the developer machine is wasted or has to be re-run

Merge request

Prepare for OMFG

Merge request created

Rebasing onto master

Tests passed

Approving as James Pic

Approving as James Pitt

Merging as James Pic

Issue board

Scheduled for GitLab 8.10 (current: 8.8)


gitlab-workhorse is a proxy for HTTP and git pull/push


GitHub GitLab
$108/user/year ($9 / month)
+ Jenkins maintenance
+ Container registry maintainance
- includes CI
- includes container registry

2011: Start of GitLab

Dmitriy was unsatisfied with the options for git repository management. So together with Valery, he started to build GitLab as a solution for this.


Sid saw GitLab for the first time. He thought it was natural that a collaboration tool for programmers was open source. Being a Ruby programmer he checked out the source code and was impressed with the code quality of GitLab. He started as the first SaaS offering for GitLab.

In November 2012, Dmitriy also made the first version of GitLab CI.

2013: "I want to work on GitLab full time"

In 2013, Dmitriy tweeted that he wanted to work on GitLab full time. Sid and Dmitriy teamed up and started bootstrapping GitLab as a company.

In the same year in August, we introduced GitLab Enterprise Edition.

2014: GitLab was incorporated

In 2014 GitLab was officially incorporated as a limited liability corporation. GitLab released a new version every month on the 22nd, just as every year before and after. The first release of the year at January 22nd: GitLab 6.5. At the end of 2014, December 2014, GitLab 7.6 was released.

2015: Y Combinator

In the very start of 2015, almost the entire GitLab team flew over to Silicon Valley to participate in Y Combinator.

At this point, over 1000 people worldwide have contributed to GitLab and more than 100,000 organizations are using GitLab.


Our Tanuki logo symbolizes this with a smart animal that works in a group to achieve a common goal.

GitLab: Vision

At GitLab we have one vision. Everyone can contribute to all digital content.

To ensure that everyone can contribute to our organization we have open business processes that allow all team members to suggest improvements to our handbook. 

Conclusion by Richard Stallman


Y'a moins bien

mais c'est plus cher

GitLab: CI revolution

By James Pic

GitLab: CI revolution

  • 2,642