Le document décrit l'intégration de Docker dans le workflow de développement, mettant l'accent sur la conteneurisation des outils et des processus pour améliorer l'efficacité des tests et de l'intégration continue. Il aborde également les challenges liés à l'orchestration des conteneurs et à la gestion des tests sur différents environnements de développement. Enfin, il souligne les avantages de Docker, tels que la reproductibilité des tests et la simplification des builds sans nécessiter l'installation complète de la stack de développement.

1. Du Docker dans mon
workflow de Dev

2. L’équipe Kodo Kojo
Jean-Pascal THIERY
@jpthiery
2
Antoine LE TAXIN
@modulom

3. ?

4. 4

5. Démocratisation de la conteneurisation
● Conteneuriser des agents de build
● Conteneuriser Jenkins
● Conteneuriser toute une usine logicielle ?
5

6. 6

7. Orchestration, le chaînon manquant
● Piloter un ensemble de conteneurs
sur un ensemble de machines
7
● Outils d’infrastructure

8. De nouvelles solutions d’usines...
● La fin du Jenkins hyper-mutualisé inmaintenable
● La fin de la ferme de Jenkins qui n’est utilisée que 2 h / jour
8

9. 9

10. … avec quelques contraintes
10
● Le monitoring dans tout ça ?
● La gestion de mes différents projets ?
● La gestion de mes utilisateurs ?

11. 11

12. 12

13. Et les tests ?
● Node, npm
● Java / Maven
● Redis
● Mesos / Marathon / Docker
● Gitlab / Ruby
● Jenkins
● Nexus
● ...
13

14. Tester le front
Tests unitaires, tests d’intégration (composants), Style Guide...
● Pour monter en local l’UI avec un backend ?
● Pour tester l’intégration avec l’API ?
14

15. Tester le back
Tests unitaires
● Interactions avec les briques (Gitlab, etc.) ?
● Interactions avec Marathon ?
15

16. Docker
(encore ?)

17. Tests - Tu te mock ?
● Avoir la main sur le comportement des scénarios de tests
● Implémenter tous les comportements de tous les outils…
et les maintenir tout le temps
17

18. Lancer chaque type de service sur le poste
● Pouvoir lancer de vrais tests d’intégration
● Maintenir les versions à jour
● Il faut s’assurer à la main de l’état initial entre chaque test
18

19. Les containers à la rescousse !
● Pouvoir lancer les tests de la même manière quel que soit l’environnement
● L’état initial d’un test est reproductible très facilement
● Pouvoir paralléliser l’exécution des tests
● Introduit de la complexité (gestion réseau, logs, …)
19

20. Frontend, comment tester l’intégration de l’API ?
=> Tests fonctionnels (ou e2e)
=> API pour développement
● Monter en local le cluster avec docker-compose
● Se brancher sur l’API d’un serveur distant (environnement de dev)
● Se brancher sur un serveur de mock (kodokojo-mocks)
20

21. Backend, objectif des tests d’intégration
● Interaction avec les briques d’une usines logicielle
● Couvrir plus de code
○ API Rest
○ Configuration des briques
21

22. Backend
22

23. Backend
23

24. Le build

25. ● Gestion isolée des versions des dépendances
● Délégation des étapes de tests
● Facilite le partage de la partie front
Faire une image du front pour le backeux
25

26. ● Créer une image de build
● Packager l’application dans une image de déploiement
Construire l’image front en deux étapes
26

27. Faire « une » image du back pour le fronteux
● Pas besoin d’installer toute la stack back (Java, Maven, etc.)
● Grâce à docker-compose, on peut lancer toutes les images qui constituent la
stack back
● Facilite l’accès aux logs
27

28. Les gains du build avec Docker
● Tests reproductibles
● Build reproductible
● Pas besoin s’installer toutes la stack, juste Docker
● Pas besoin de savoir comment le composant est contruit: lancer le build.sh et
utiliser l’image en sortie
28

29. Intégration continue avec Docker
● Jenkins
○ Multi-branch pipeline plugin
○ Jenkinsfile
29

30. Conclusion
● Développement puis intégration Front <-> Back
● Docker -> deploy anywhere !
● Test d’intégration continu avec d’autres briques technologiques tierces
(Redis, RabbitMq, Marathon, …)
30

31. 31
Merci !
https://kodokojo.io
https://github.com/kodokojo
https://gitter.im/kodokojo/kodokojo
@kodokojo