## Retour d'experience sur la mise en place de déploiement continu ### Capitole du Libre 2018 ![](https://i.imgur.com/OuMt8zg.png) #### Arthur Lutz & Philippe Pepiot (Logilab) ![](https://www.logilab.fr/file/2831/raw/logo-logilab.svg =100x) --- ## Introduction * Arthur Lutz * [![](https://social.logilab.org/system/custom_emojis/images/000/002/815/original/d91b01cc6bc88981.png =30x)<!-- .element style="border:0;margin:0;background:black" --> @arthurlutz](https://twitter.com/arthurlutz) * ![](https://social.logilab.org/system/custom_emojis/images/000/002/814/original/63c72d3387d84738.png =30x)<!-- .element style="border:0;margin:0;background:black" --> [@arthurlutz@social.logilab.org](https://social.logilab.org/@arthurlutz) * Philippe Pepiot * [![](https://social.logilab.org/system/custom_emojis/images/000/002/815/original/d91b01cc6bc88981.png =30x)<!-- .element style="border:0;margin:0;background:black" --> @philpep_](https://twitter.com/philpep_/) * ![](https://social.logilab.org/system/custom_emojis/images/000/002/814/original/63c72d3387d84738.png =30x)<!-- .element style="border:0;margin:0;background:black" --> [@philpep@mastodon.tetaneutral.net](https://mastodon.tetaneutral.net/@philpep) * [Logilab](https://www.logilab.fr) * [![](https://social.logilab.org/system/custom_emojis/images/000/002/815/original/d91b01cc6bc88981.png =30x)<!-- .element style="border:0;margin:0;background:black" --> @logilab](https://twitter.com/logilab/) --- ## Déploiement continu ![](https://images.itnewsinfo.com/lmi/dossiers/grande/000000061239.png)<!-- .element style="border:0;background:white" --> [Article wikipedia](https://en.wikipedia.org/wiki/Continuous_delivery) --- ## Pourquoi * éviter le stock de code à intégrer / non publié * boucle de retroaction rapide avec le client * validation répartie sur de courtes périodes * confiance augmentée pour la mise en production * corriger des bugs sur du code écrit récemment * sentiment partagé que le projet avance --- ## Tester souvent, casser, corriger, tester à nouveau > Outils utilisés en dev et CI/test. * [tox](https://tox.readthedocs.io/en/latest/) - environnements de tests reproductibles * [pytest](https://pytest.org) - lance les tests python * [flake8](https://gitlab.com/pycqa/flake8) / [isort](https://github.com/timothycrosley/isort) - conventions de code * [pifpaf](https://github.com/jd/pifpaf) - tests fonctionnels (lance des serveurs postgresql, redis, rabbitmq éphémères) --- ## Intégration continue * Jenkins * [jenkins-job-builder](https://pypi.org/project/jenkins-job-builder/) * [Docker Slaves Plugin](https://wiki.jenkins.io/display/JENKINS/Docker+Slaves+Plugin) * Phabricator + Jenkins = [Differential jenkins job](https://hg.logilab.org/master/differential) et `JenkinsFile` --- ## Test d'acceptance , casser, corriger, tester à nouveau * BDD (Behaviour Driven Development) avec [behave](https://github.com/behave/behave) / [robber](https://github.com/vesln/robber.py) * [selenium](https://docs.seleniumhq.org/) * [cwclientlib](https://pypi.org/project/cwclientlib/) & [requests](http://docs.python-requests.org/en/master/) & CLI python qui teste l'API ![](https://upload.wikimedia.org/wikipedia/en/5/5c/Seleniumlogo.png =100x)<!-- .element style="border:0;background:white" --> --- ## Pousser, modifier la qualité, pousser à nouveau * Métriques collectées par Jenkins * [SonarQube](https://www.sonarqube.org/) * Métriques collectées avec [carbon](https://github.com/graphite-project/carbon) et [graphite](https://github.com/brutasse/graphite-api/) * Pour l'orchestration de cette collecte voir [cfmgmtcamp: Use Saltstack to deploy a full monitoring and supervision stack](http://slides.logilab.fr/2018/cfgmgmtcamp_saltstack_monitoring.pdf) ![](https://www.sonarqube.org/assets/logo-31ad3115b1b4b120f3d1efd63e6b13ac9f1f89437f0cf6881cc4d8b5603a52b4.svg =x100)<!-- .element style="border:0;background:white" --> --- ## Agile infrastructure > Infrastructure as code * [saltstack](https://github.com/saltstack/salt/) , [salt-cloud](https://docs.saltstack.com/en/latest/topics/cloud/), [awscli](https://aws.amazon.com/fr/cli/) * docker / docker-compose * Utiliser les mêmes images docker pour les environnements `acceptance testing`, `pre-production` et `production` * kubernetes * openshift / OKD ![](https://res.cloudinary.com/crunchbase-production/image/upload/v1397185611/ddd2130f2a69731ce90ebf4fc205866f.jpg =200x)<!-- .element style="border:0;margin" --> --- ## Infrastructure agile - supervision, metriques et tests * [sensu](https://sensu.io/) pour la supervision avec [sensu-formula](https://github.com/saltstack-formulas/sensu-formula) * [netdata](https://my-netdata.io/) pour la collecte de métriques * [testinfra](https://testinfra.readthedocs.io/en/latest/) pour les tests d'infrastructure ![](https://testinfra.readthedocs.io/en/latest/_static/logo.svg =100x)<!-- .element style="background:white" --> --- ## Livrer souvent, casser, corriger, livrer à nouveau * [rundeck](https://www.rundeck.com/) ou [Jenkins](https://jenkins.io/) * Géneration des numéros de version * Tickets automatiquement taggués pour validation * Tester les nouvelles versions upstream des dépendances (pip & npm) ![](https://ifireball.files.wordpress.com/2015/01/rundeck_400x400.png =100x)<!-- .element style="border:0;margin-left:700px" --> ![](https://upload.wikimedia.org/wikipedia/commons/thumb/e/e3/Jenkins_logo_with_title.svg/1280px-Jenkins_logo_with_title.svg.png =x100)<!-- .element style="border:0;background:white" --> --- ## Livrer souvent, collecter les erreurs, corriger, livrer à nouveau * [sentry](https://github.com/getsentry/sentry) pour la collecte d'erreurs structurées * [sentry-python](https://github.com/getsentry/sentry-python), [sentry-javascript](https://github.com/getsentry/sentry-javascript) à brancher coté applicatif * Création de tickets Jira/Phabricator à partir des erreurs collectées ![](https://sentry-brand.storage.googleapis.com/sentry-logo-black.png =x100)<!-- .element style="border:0;background:white;margin-left:500px" --> --- ## Livrer l'environnement de qualification vers la production ![](https://i.imgur.com/OfvtRwf.png) --- ## Dashboards everywhere * [Jira python bindings](https://pypi.org/project/jira/) pour extraire les données de Jira * [requests](http://docs.python-requests.org/en/master/) pour extraire les données de RunDeck * *Badges everywhere!* avec https://shields.io * [Grafana](https://grafana.com/) en interface à [graphite](https://github.com/brutasse/graphite-api/) --- ![](https://i.imgur.com/VRS2cJE.png) --- ![](http://docs.grafana.org/img/docs/v45/table_annotations.png) --- ## Impacts * tickets courts, découper ceux-ci en plus petits * les environments de validation instables doivent être expliqués aux utilisateurs * *feature flags* pour intégrer des nouvelles fonctionnalités sans les activer par défaut * abandon du *semantic versionning* (avantages & inconvénients) * pour les développeurs : * le matin on corrige les bugs, * l'après-midi on code des fonctionnalités --- ## Futur / la suite * Environnements déployés à la volée sur les patches * Restauration automatique des données de production en validation * *A/B testing* et/ou *Canary testing* * Utilisation de la gestion de version dans Sentry et l'identification de regressions * Environnements de dev moins nécessaires --- ![](https://www.logilab.fr/file/2622/raw) --- ## Conclusion / Questions * Merci pour votre attention * Des questions ? * Diapositives (avec les liens !) : [html](https://hackmd.logilab.org/p/Bk9mTZ_TQ#/), [pdf ](http://slides.logilab.fr/2018/capitoledulibre2018_deploiement_continu.pdf) ![](https://www.logilab.fr/file/2831/raw/logo-logilab.svg =100x)
{}