Accélérez votre "feedback loop" et réduisez vos coûts grâce à une meilleure CI

Lorsqu'un projet mature commence à se fournir en couverture de code au niveau unitaire et fonctionnel, nous mettons en place une CI pour automatiser l'exécution de ces tests.

La plupart du temps nous utilisons des solutions comme Travis, Circle CI, Jenkins ou d'autre.

Il vient un moment où l'accumulation de tous ces tests entrave le rythme de développement par la durée d'exécution. De plus, lorsque l'équipe grossit, le nombre de lancements de tests explose, ajoutant du délai d'attente.

Deux solutions sont envisagées dans la plupart des cas :
1. Soit ne plus attendre la CI pour merger/mettre en production et prendre le risque qu'un bug passe en production.
2. Soit payer plus cher, pour avoir plus de tests en parallèle, pour absorber la charge.

En réalité, il existe une troisième solution, faire une CI plus rapide et en plus la payer moins cher. Elle permet d'accélérer le feedback qui permet un developpement plus vertueux.

Je vous partagerai mon retour d'expérience d'une migration de CI qui a permis de passer la durée des tests de ** 1 heure à 6 minutes **et de **diviser les coûts par 5.**

Transcript

1. Accélérez votre "feedback loop" et réduisez vos coûts grâce à une meilleure CI Desjardins Jérôme Les-Tilleuls.coop
2. Jérôme Desjardins • Lead Dev chez Les-Tilleuls.coop • Amateur de PHP depuis 14 ans • Professionnel depuis 6 ans • Orientation DevOps @jewome62 @J_Desjardin
3. Les-Tilleuls.coop • Entreprise autogérée (SCOP) • 40 salariés • Bureaux à Lille / Paris / Nantes • On recrute : jobs@les-tilleuls.coop
4. C.I ?
5. Intégration Continue • Tester la non-régression • Automatisation • Popularisée par Jenkins • Généralisée par Travis
6. Feedback loop ?
7. Feedback Retour du fonctionnel Déploiement Mise à disposition sur un environnement de test Développement Écriture du code Écriture des tests Conception Spécifications du besoin Feedback Loop
8. Contexte ?
9. Le client Alice’s Garden Alice's Garden est la marque spécialiste du mobilier de jardin et de l'équipement d'extérieur sur Internet • Site Web • Gestion des commandes • Gestion des stocks • Gestion des transporteurs Logiciel Symfony initié par Kévin Dunglas en 2011 CI sous Travis, couverture de tests PHPUnit + Behat
10. Problèmes chez le client • Agrandissement de l’équipe • Ajout de tests multiples • Ajout de nouvelles technologies => la durée des tests augmente
11. 1h00 Durée moyenne d’une suite de tests (Entre 55 minutes et 1h10)
12. 249$/mois Travis - 5 concurrent jobs
13. Possibilités ? Deux idées : • Ne rien changer, donc attendre ou pire : ignorer la CI quand on n’a pas le temps • Payer plus cher pour plus de slots (10 slots à 490$)
14. Non merci
15. Optimiser !
16. Optimiser le Docker • Utiliser les images Alpine => 75% plus légère • Pull les images avant de rebuild (cache) • Purger les fichiers inutiles lors du build ◦ Bibliothèques de développement (compilation) ◦ Code source utilisé pour une compilation ◦ Cache du gestionnaire de paquets ◦ Ne pas importer des fichiers inutiles • Optimiser les instructions du Dockerfile
17. Optimiser le Docker
18. Optimiser les tests • Limiter la dépendance entre les tests • Séparer vos tests selon des scénarios • Charger le jeu de données nécessaires pour le scénario • Désactiver Xdebug • Désactiver le mode debug APP_DEBUG = 0
19. Optimiser les tests Lancer les tests en SQLite ? • SQLite plus rapide sur les petits jeux de données. • Permet de charger les fixtures une fois dans un fichier. Puis de copier-coller pour recharger les fixtures rapidement. • Doctrine est indépendant du SGBD
20. Optimiser les tests Mais en réalité, le projet utilise les spécificités du SGBD
21. Optimiser les tests Utiliser le même SGBD qu’en production ! Utiliser le purge au lieu du delete-create Sauvegarder les fixtures en SQL et les recharger les avec DBAL Transaction in-memory
22. 40 min
24. Paralléliser
25. Ok, mais comment ?
26. Types de parallélisation Créer un container/VM/machine => Un job différent Créer un processus supplémentaire => GNU Parallel
27. Outils pour paralléliser Travis Même script exécuté mais variables d’environnements différentes
28. Outils pour paralléliser Circle CI: Scripts différents par job
29. Mais toujours limité au nombre de jobs
30. Outils pour paralléliser Jenkins
31. Outils pour paralléliser GitLab + GitLab CI
32. J’ai une confession à vous faire
33. I
34. GitLab Solution de versionning ++ Open-core • Logiciel open source • Fonctionnalités supplémentaires payantes • Gestion des tickets, board, merge request, interface Git • Registry Docker privé • CI avec GitLab CI • Connectivité avec Cluster Kubernetes • Une release par mois • Beaucoup d’autres fonctionnalités
35. GitLab Runner Open Source et écrit en Go Installable sur Linux/macOS/Windows en Docker ou dans un cluster Kubernetes Multiple configuration du runner : • Shell • Docker • Docker Machine and Docker Machine SSH • Parallels • VirtualBox • SSH • Kubernetes
36. Docker Machine Outil qui permet de provisionner Docker sur des environnements virtuels • Amazon Web Services • Microsoft Azure • Digital Ocean • Exoscale • Google Compute Engine • Microsoft Hyper-V • OpenStack • Rackspace • IBM Softlayer • Oracle VirtualBox • VMware vCloud Air • VMware Fusion • VMware vSphere
38. Google Cloud Engine Machine virtuelle de ¼ vCPU à 96 CPU et de 0.6 GB à 1433.6 GB de RAM ⇒ Préemptible: 4 fois moins cher
39. Résumons
40. GitLab GitLab Runner Docker Machine VM Compute Engine
41. Configuration du Runner Créer une instance micro avec la configuration suivante : f1-micro: 4.39$/mois
43. Paralléliser les tests • Séparer vos tests techniquement ◦ Ceux qui ne font que lire en base de données ◦ Ceux qui écrivent en base de données ◦ Ceux qui ont besoin d’une autre technologie (ElasticSearch, RabbitMQ)
44. 10min
45. 70$/mois en Moyenne (entre 60-80$) pour 2 783 heures - 3 966 heures (hors coûts d’infogérance)
46. Bénéfices / Inconvénients • Gain de temps ◦ Accélération des cycles de développement ◦ Les devs lancent leurs tests sur la CI => Libère les ressources pour travailler sur autre chose ◦ Les retours sont faits plus rapidement • Gain sur la facture ◦ De la solution SaaS de CI ◦ Du café • Gain sur la facture Infra uniquement • Maintenance par un DevOps => Coût indirect • Pas d'infogérance
47. Rentable ? Peut-être Profitable ? Oui
48. Sources • https://docs.gitlab.com/runner/ • https://docs.gitlab.com/runner/configuration/advanced-configuration.html • https://docs.gitlab.com/runner/configuration/autoscale.html • https://docs.gitlab.com/runner/configuration/runner_autoscale_aws/index.html • https://docs.docker.com/machine/ • https://docs.docker.com/machine/drivers/ • https://cloud.google.com/compute/ • https://cloud.google.com/compute/pricing • https://cloud.google.com/preemptible-vms/ • https://www.minio.io/gcp.html
49. Questions ?