Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Docker e git lab

1,390 views

Published on

Docker & GitLab as a Continuous Integration platform. In this talk we describe how we use gitlab and docker as a platform to implement Continuous Integration in a simple and effective weay.

Published in: Software

Docker e git lab

  1. 1. Docker & GitLab Docker & GitLab as a Continuous Integration platform
  2. 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. 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. 4. Technologies
  5. 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. 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. 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. 8. How we used to do it ...
  9. 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. 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. 11. GitLab
  12. 12. GitLab as CI
  13. 13. GitLab as CI
  14. 14. GitLab as CI
  15. 15. GitLab as CI
  16. 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. 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. 18. Install becomes Declare
  19. 19. Install becomes Declare
  20. 20. Install becomes Declare
  21. 21. Install becomes Declare
  22. 22. Install becomes Declare
  23. 23. Install becomes Declare
  24. 24. Install becomes Declare
  25. 25. Install becomes Declare
  26. 26. Install becomes Declare
  27. 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. 28. Easily replicable Local:
  29. 29. Easily replicable ... GitLab:
  30. 30. Easily replicable ... GitLab:
  31. 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. 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. 33. Evolution ?!? Start to use Docker on development machine with Compose
  34. 34. Evolution ?!? Start to use Docker in production ...
  35. 35. Thank you!!!! Q&A!!!

×