Industrialisation et automatisation chez M6 Web Lille

Retour d'expérience sur un an de mise en place de process et de workflow chez M6 Web Lille - sfPot à Lille de juin 2016

Transcript

1. Industrialisation des développements Be lazy, automate. Pierre Marichez Renaud Bougré Nicolas Beze
2. Nos sites Nos services
3. Constat 2015 ◎ Organisation trop compartimentée ◦ Organisation verticale ◦ SPOF ◎ Pas de process ◦ Mise en production risquée ◦ Outil de gestion de projet non performant ◦ Correction des bugs en production ◦ Pas de workflow de developpements ◎ Mal outillé ◦ Pas d’alerting en place ◦ Aucun monitoring
4. Schéma 2015 Projets Radins Radins bon plan Météo Météo mobile Radins mobile Fourchette Croqkilos Devs capable de déployer 2 3 2 0 2 1 3 Techno php maison SF2 php maison bis jquery mobile Angular 1 / ionic drupal 7 php 5.6 SF2 Env de dev distant vagrant distant distant distant vagrant Livraison delivery git pull capistrano + intervention manuelle git pull git pull git pull git pull capistrano Livraison prod rsync capistrano git pull git pull git pull drush rsync capistrano
5. Schéma 2016 Projets Radins Radins bon plan Météo Météo mobile Radins mobile Fourchett e Croqkilos Radins batch Devs capable de déployer Toute l’équipe Techno php maison SF2 php maison bis jquery mobile Angular 1 / ionic drupal 7 php 5.6 SF2 SF3 php7 Env de dev Docker Env de test Gitlab-ci Livraison staging Jenkins Livraison delivery Livraison prod
6. Comment c’est-y qu’on a fait ? ◎ Uniformisation des environnements de dev ◎ Formalisation des étapes de vies des Us/Bug ◎ Définition d’un workflow de dev ◎ Intégration continue ◎ Automatisation ◎ Monitoring ◎ Alerting
7. Uniformisation des environnements de dev Passage à docker : ◎ Une baleine ◎ Le standard émergeant ◎ Plus d’environnements de dev distants ◎ Flexibilité et sécurité en se passant des VM ◎ Performance en local ◎ Rationalisation des projets
8. Cycle de vie d’une User Story US_1234 → SEO - correction arborescence TargetProcess 3 5 8 → SEO - correction arborescence 8pt - Renaud Sprint Code... branch feature/US_1234-SEO-correction push build Déploiement Validation Scrum Master Validation Product Owner Mise en production --------------- --------------- --------------- --------------- --------------- # Slack
9. Workflow de développement - Feature git clone git@gitlab.m6 : radins.git feature/US_346-cashback Code Tests unitaires Tests fonctionnels Git pull rebase origin develop Git push Code review Merge sur develop • Q/A (sniff, etc…) • Tests unitaires • Tests fonctionnels Build gitlab-ci Création merge request auto Déploiement automatique sur staging
10. Gitlab-ci : pourquoi faire ? Après un push : ◎ Contrôles qualité ◎ Tests ◎ Création de MR auto
11. Gitlab-ci ◎ Créer le(s) runner(s) (executor : docker) ◎ Configurer .gitlab-ci.yml ◎ image docker de base (si différente du runner), redéfinissable par job ◎ services : liste des images pour les services de base, redéfinissable par job ◎ variables d’environnement partagées entre tous les containers
12. Gitlab-ci ◎ N stages redéfinissables (build, test, deploy par défaut) ◎ N “jobs” par stage pas de persistance de données ◎ job échoué = on ne passe pas au stage suivant
13. Gitlab-ci ◎ filtres “only” / “except”, “when” (“on_failure”, “on_success”) ◎ “before_script” (commun aux jobs) ◎ cache ◎ artefacts ◎ syntaxe avancée YAML ◎ jobs “cachés” pour factoriser la conf
17. Utilisation de Jenkins (pour de vrai) Sonar Jenkins Sentry Grafana Slack Target Process Mail release note Change Log Capistrano
18. Monitoring ◎ ElasticSearch et Packetbeat pour le trafic, les codes HTTP et temps de réponse. ◎ Grafana et statsd pour les applications. ◎ Sonar pour la qualité du code
19. Alerting ◎ Sentry pour les erreurs applicatives (serveur et javascript) avec alerting par mails ou notifs via slack ou création US dans TargetProcess. ◎ Alerting humain via les écrans de monitoring dans le bureau. ◎ Directement par l’hébergeur
20. Boîte à outils ◎ Slack ◎ Versions.sh ◎ User script versions ◎ TargetProcess ◎ Jenkins ◎ Grafana ◎ Kibana ◎ Sonar ◎ Sentry
21. Slack
22. Bash script
23. User script
24. TargetProcess
25. Jenkins
26. Grafana
27. Kibana
28. Sonar
29. Sentry
30. J’adore quand un plan se déroule sans accroc ◎ Docker Toolbox ◎ Docker + windows = Joie ◎ Docker for mac (beta) : plus d’IP pour les containers ◎ Communication dockers (eg. client / API) ◎ Timeout gitlab-ci ◎ Capistrano (FPM + symlink) ◎ Full disk jenkins ◎ Faux positifs gitlab-ci ◎ 30 min pour créer un environnement à la volée ◎ Dépassement de quota dans sentry ◎ Monitoring qui freeze ◎ Pas de procédure de déploiement
31. Aujourd’hui
32. Demain
33. Rendez-vous en SEPTEMBRE
34. Liens utiles ◎ Doc runners gitlab-ci http://docs.gitlab.com/ce/ci/runners/README.html ◎ Doc fichier de conf gitlab-ci http://docs.gitlab.com/ce/ci/yaml/README.html ◎ Tester sa conf gitlab-ci en local https://gitlab.com/gitlab-org/gitlab-ci-multi-runner ◎ PacketBeat https://www.elastic.co/fr/products/beats/packetbeat ◎ Github https://github.m6web.fr/repositories ◎ Docker hub M6 https://hub.docker.com/r/m6web/ ◎ Licornes http://www.cornify.com/ www.odiso.com www.mindbaz.com tech.m6web.fr