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 conteneurssur 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

● Creer 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