Retour d'expérience sur la mise en place de l'intégration continue sur les projets chez Identicar

1. Intégration continue
Jeudi 27 octobre 2016
Apéro techno

2. Continuous Integration
Continuous Delivery
Continuous Deployment
C'est quoi pour vous ?

3. Définition
Développement Intégration
Développement
Intégration
Intégration classique
Intégration continue

4. Définition
« L'intégration continue est une pratique en
génie logiciel, qui consiste à faire en sorte que
les développeurs intègrent fréquemment
leurs travaux à l'application »

5. Définition

6. Définition
Agilité DevOps
Qualité logicielle
Software Craftsmanship
Intégration
continue

8. Panorama
Référentiel de sources
Automatisation
du build
Des tests et encore des tests
Contrôle de la
qualité du code
Packaging
Indicateurs,
métriques et tableau
de bord
Gestion de
configuration
Gestion des
dépendances

10. Pourquoi ?
 Nombreuses taches répétitives et pénibles
 Perte de temps à traiter les problèmes de livraison, de configuration
 Risque élevé d’erreurs humaines
 Conflits récurrents entre Dev et Ops sur les problématiques de déploiement
 Besoin d’augmenter la fréquence des livraisons #Agilité
« Les gros changements
créent de gros
problèmes, des petits
changements créent de
petits problèmes »

11. Par quoi commencer ?
 Savoir définir et s’approprier collectivement des règles de développement
=> tests unitaires, codage, nommage,…
Toute activité qui n'apparaît qu'au moment d'une livraison intermédiaire et que l'équipe vit comme longue et pénible est
candidate pour être prise en compte au titre de l'intégration continue
 Avoir une stratégie de test partagée (développeur, métier, exploitants)
 Partager les objectifs de l’intégration continue
 Compléter et améliorer en continu le processus d’intégration et de déploiement
 Disposer des bonnes compétences pour avancer de manière efficace
 Identifier les outils disponibles en fonction du contexte techno

12. Outils
« L'intégration continue n'est pas en premier lieu une
question d'outil mais d'attitude »

13. Exemple
Définition d’objectifs de qualité :
Couverture de tests de 80%
D’ici à 3 mois, tous les développeurs ont écrit 20 tests unitaires
D’ici à 3 mois, tous les bugs rencontrés amèneront à l’écriture d’un test
Tests automatiques :
Tests unitaires demandés à chaque dev sur tous les nouveaux développements
Tests fonctionnels Bihat sur les fonctionnalités clés
Qualité du code :
Scrutinizer sur tous les projets GitHub PHP
Relecture systématique du code par 2 dévs avant chaque merge
Lancement automatique des tests et de l’analyse de qualité lors de chaque PR (Pull Request)

14. Retour d’expérience
Olivier CONDON

15. Release X.Y.Z
Service A
Service B
Site web
Fixtures
Deploy
BuildCommit
Deploy
Dépot
Intégration
US/Workitems
Pré-recette
Tests fonctionnels
automatiques
Build
Analyse qualité du code
Test
Recette
Demande de déploiement
Approbation
Deploy

16. Pourquoi ?
• Besoin d’avoir des résultats de tests fonctionnels en temps réel
=> validation US
• Besoin d’avoir un environnement dispo et à jour pour la pré-
recette
• Diminuer le temps perdu par l’équipe OPS à faire des
copier/coller et mise en conformité pour les déploiement sur les
environnements
• Sécuriser le process, éviter les erreurs humaines
• Améliorer la communication DEV-OPS
• Focaliser le temps des devs et des ops sur des tâches utiles

17. Etapes de mises en oeuvre
Obtenir des droits d’admin complet sur un serveur (IC)
Obtenir la confiance des OPS, expliquer la démarche
Mettre en place un build auto au commit sur un serveur de build
Déployer ces build auto sur le moteur de tests fonctionnels
Exécuter une analyse automatique et régulière du code
Etudier l’écosystème réseau / Droits / Domaines / AD / zones DMZ
avec les OPS, étudier leur process de déploiement manuel
Mettre en place un déploiement automatique sur
l’environnement d’intégration
Mettre en place un déploiement automatique à la
demande sur l’environnement de recette
Définir un workflow d’approbation consensuel
Mettre en place un déploiement automatique à
la demande sur l’environnement de production

18. Difficultés rencontrées
• Infrastructure réseau en mouvement
• VSTS en constante et rapide évolution
• Trouver un projet en pause, ou qui tolère une perte d’efficacité pendant la
transition
• Découvrir l’ancien rôle et définir le nouveau rôle du Release Manager
• Rassurer les DBA

19. Prochaines étapes
• Ajout dans le process auto de la seule partie manquante : SQL
 Permettre aux DBA de continuer d’assurer leur rôle de validateur des livraisons
 Poc terminé, RedGate sur la rampe de lancement
• Passage de TFS à GIT
 une branche par US
 Pull request forcés sur MASTER & DEV
 « Commiteur d’acier » ou relecture de code croisée
• IaC (Infrastructure as Code)
 Créer à la volée les environnements à la demande : 1 par branche de code

20. Merci !