The document discusses the integration of Docker and GitLab as a Continuous Integration (CI) platform, highlighting the benefits of creating isolated environments and simplifying dependency management through declarative configuration. It outlines the problems with traditional CI setups, such as differences between development and CI environments, and emphasizes the advantages of automatic cleanup and easy replication using Docker. Additionally, it mentions potential drawbacks like slow dependency downloads and the need to adapt to new technologies.

1. Docker & GitLab
Docker & GitLab as a Continuous Integration platform

2. GPad
Born to be a developer with an interest in “system admin”
I develop using many languages like C++, C#, js and ruby. I have recently fallen in love
with functional programming, especially with elixir, erlang, clojure and haskell.
CTO & founder of coders51

3. We develop web and mobile solutions for the entire galaxy
We don’t develop web sites
At least not simple ones ...
Every time there is something new and interesting, we want to be there!!

4. Technologies

5. Continuous Integration
https://en.wikipedia.org/wiki/Continuous_integration:
Continuous integration (CI) is the practice, in software engineering, of merging all
developer working copies to a shared mainline several times a day. It was first
named and proposed by Grady Booch in his 1991 method, although Booch did not
advocate integrating several times a day. It was adopted as part of extreme
programming (XP), which did advocate integrating more than once per day,
perhaps as many as tens of times per day.

6. Continuous Integration
http://www.martinfowler.com/articles/continuousIntegration.html:
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.
Many teams find that ….

7. Install Install Install
Each software should be installed on a CI computer
Each software with its own dependencies
Each software has different dependencies
Each software has different dependencies with different versions
This is a mess ...

8. How we used to do it ...

9. It works on my computer ...
One test fails on the CI computer, but not on the developer’s computer
The CI environment is different from the production environment
The CI environment is different from the development environment

10. Who cleans up this mess ?!?
After running the tests we have some dirty data
Dirty data in the database
Dirty data in the file system
Some dirty states on the external services

11. GitLab

12. GitLab as CI

13. GitLab as CI

14. GitLab as CI

15. GitLab as CI

16. Why Docker?!?
If we use Docker:
- We can create an isolated environment
- It’s not necessary to clean data after the tests
- It’s “simple” to put together all the necessary external services
- It’s easy to replicate on different computers

17. Install becomes Declare
It’s not necessary to install all software on the CI computer
We can “declare” external dependencies
In .gitlab-ci.yml we can declare everything regarding the software under test:
- which images we require
- which services we depend on
- which scripts we want to execute

18. Install becomes Declare

19. Install becomes Declare

20. Install becomes Declare

21. Install becomes Declare

22. Install becomes Declare

23. Install becomes Declare

24. Install becomes Declare

25. Install becomes Declare

26. Install becomes Declare

27. Auto-cleaning system ...
The images are stored in cache on the CI server
At every restart the state of the container is known
It’s simple to avoid a corrupted situation
If the test fails we don’t have any “garbage data” left over

28. Easily replicable
Local:

29. Easily replicable ...
GitLab:

30. Easily replicable ...
GitLab:

31. Easily replicable ...
Run mongo:
sudo docker run --name mongo-dockerops -d mongo
Run node:
sudo docker run -it --link mongo-dockerops:mongo -v
`pwd`:/opt/app node:0.12 /bin/bash
root@9b71e87dfd1c:/# grunt test

32. Pros & Cons
PROS
No need to install all software on the
CI computer
The environment is always clean at
every restart
The CI environment can be replicated
on every computer
CONS
It’s slow when there are a lot of
dependencies to download
We need to manage new technologies
(Docker)

33. Evolution ?!?
Start to use Docker on development machine with Compose

34. Evolution ?!?
Start to use Docker in production ...

35. Thank you!!!!
Q&A!!!