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 drone.io 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
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
+ 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
- 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
In GitLab, User can also click to enable merge when CI and approvals validate the PR
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.
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 ?
Request test execution on runner
Fork, register runner for fork
Publish runner logs and result
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:
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
Prepare for OMFG
Merge request created
Rebasing onto master
Approving as James Pic
Approving as James Pitt
Merging as James Pic
Scheduled for GitLab 8.10 (current: 8.8)
gitlab-workhorse is a proxy for HTTP and git pull/push
|$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 GitLab.com 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
Our Tanuki logo symbolizes this with a smart animal that works in a group to achieve a common goal.
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