Du Docker dans mon
workflow de Dev

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

?

4

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

6

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

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

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

11

12

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

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

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

Docker
(encore ?)

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

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

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

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

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

Backend
22

Backend
23

Le build

● 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

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

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

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

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

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
Merci !
https://kodokojo.io
https://github.com/kodokojo
https://gitter.im/kodokojo/kodokojo
@kodokojo