Communauté Agile de Sherbrooke. Formation CI / CD GABRIEL BLAIS BOURGET CA.LINKEDIN.COM/IN/GABRIELBBOURGET MARS 2016

Transcription

1 Communauté Agile de Sherbrooke Formation CI / CD GABRIEL BLAIS BOURGET GABRIEL.B.BOURGET@GMAIL.COM CA.LINKEDIN.COM/IN/GABRIELBBOURGET MARS 2016

2 Organisation de la rencontre - Merci à La Ville de Sherbrooke pour l organisation de la rencontre - Jean-Pierre Grenier - Site web -

3 Nos partenaires - Votre logo pourrait être ici!

4 Devenir partenaire - Programmes de partenariat Contactez-nous - info@agilesherbrooke.ca

5 Devenez membre - Inscrivez vous à la liste de distribution Suivez notre page Facebook - Communauté Agile de Sherbrooke - Sherbrooke /

6 CI et CD Quand? Comment? Pourquoi?

7 Agenda Pourquoi parle-t-on de CI et/ou CD dans chaque conférence Agile? Qu est-ce que le CI? De la théorie à l application Qu est-ce que le CD? De la théorie à l application Comment se mesurer?

8 Pourquoi parle-t-on de CI et/ou CD dans chaque conférence Agile? Agile Manifesto, premier principe : Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée - Pleins de personnes intelligentes

9 Pourquoi parle-t-on de CI et/ou CD dans chaque conférence Agile? L XP dit : Si c est une bonne pratique de faire X, alors on va le faire tout le temps! Attendre trop longtemps avant de review le code ou de tester sera douloureux. Le faire souvent fait en sorte que tu deviens meilleur, procastine moins, etc. C est la même chose pour la livraison de logiciel.

10 Qu est-ce que le CI? «L'intégration continue est une pratique de développement de logiciels, où les membres d'une équipe intègrent leur travail souvent, habituellement chaque personne intègre au moins quotidiennement - conduisant à de multiples intégrations par jour. Chaque intégration est vérifiée par une construction automatique (y compris les tests) pour détecter les erreurs d'intégration aussi rapidement que possible.» - Martin Fowler

11 Le CI ne règle pas tout Le CI aide plus souvent à trouver le problème plus tôt. Par exemple: Un problème architectural de l application pourrait faire en sorte qu on rencontre plus de problèmes d intégration.

12 Qu est-ce que le CI? Maintain a single source repository Un simple «Pull» devrait être suffisant pour «Builder» l application. Inclus le nécessaire pour la BD, configuration, tout!

13 Qu est-ce que le CI? Automatisation du Build L application devrait être construite d une seule commande. Donc, rapidement utilisable. Inclus le nécessaire pour la BD, configurations, tout!

14 Dans la vraie vie Automatisation du «Build» Presqu impossible lorsqu on pense à un système complet. (Front-End, Back-End, services web, etc.)

15 Solution Automatisation du «Build» 1 Build par solution/projet/etc Le regroupement qui fait le plus de sens selon vous. Difficulté anticipée: Comment gère-t-on les versions entre elles?

16 Qu est-ce que le CI? Faire que le Build soit testable Ajouter des tests qui assurent que vos changements ne régressent pas. Implique de faire du TDD-ish. Chaque «commit» devrait valider que rien n a régressé et que le système fonctionne.

17 Dans la vraie vie. Faire que le Build soit testable Il est utopique de penser que l on peut développer des tests qui nous mettent 100% en confiance et qui s exécutent dans un délai raisonnable. Prenons l exemple des tests de charge qui peuvent être vraiment longs à exécuter.

18 Solution Faire que le Build soit testable Avoir une batterie de tests qui prend moins de 10min à rouler. Implique presque seulement des tests unitaires, a.k. a business logic. Laisser le CD prendre la balle pour la suite.

19 Qu est-ce que le CI? Chaque personne intègre à chaque jour. Implique un minimum de branches. Le CI est plus qu un ensemble d outils. C est une manière de travailler.

20 Dans la vraie vie. Chaque personne intègre à chaque jour. Inspire la peur même aux développeurs. Beaucoup de résistance. Demande absolument le «buy-in» des développeurs.

21 Solution Chaque personne intègre à chaque jour. L essayer. Branchage par abstraction. Ne pas travailler avec des commits qui brisent des fonctionnalités.

22 Qu est-ce que le CI? Chaque commit déclenche un build sur la machine d intégration. Certains préfèrent le faire manuellement.

23 Qu est-ce que le CI? Préserver le Build rapide La règle de pouce dit ~10 minutes. Incluant les tests unitaires et tout.

24 Dans la vraie vie Préserver le Build rapide Il arrive que la cadence de commit moyenne dans une application soit plus rapide que 10 min. Les développeurs doivent attendre.

25 Solution Préserver le Build rapide Faire du «Bundling» de commit. Optimiser le build ou travailler sur la grosseur de l application.

26 Qu est-ce que le CI? Tout le monde peut voir ce qui arrive. Les développeurs ont un feedback rapide sur la condition d un build. (Avec un pipeline de déploiements, c est merveilleux)

27 Dans la vraie vie Tout le monde peut voir ce qui arrive. Commit and Run!

28 Qu est-ce que le CI? Un build brisé doit être réparé immédiatement. Si on ne peut pas le réparer en dedans de 10, on doit faire un «rollback». JAMAIS on ne doit mettre un test en commentaire ou à ignore. Un build en santé devrait être plus important que tout le reste.

29 Dans la vraie vie Un build brisé doit être réparé immédiatement. Parfois plus long que prévu... C est une question d habitude. Demande le buy-in des développeurs

30 Qu est-ce que le CD? «La livraison continue est une discipline de développement où le logiciel est construit de sorte qu il soit livrable en production à tout moment.» Fowler - Martin Pour ce qui est des déploiements en production, il peut être très intéressant de faire cette distinction entre le CD et les déploiements en continu.

31 Qu est-ce que le CD? Créer un procédé fiable et répétable pour la livraison «Livrer une application devrait être facile : Cela fait plusieurs fois qu on utilise le même procédé Le tout a été testé des centaines de fois» «Quand ça fait mal, il faut le faire souvent»

32 D abord Un prérequis pour faire du CD: Très bonne confiance au code produit. Implique d être déjà à l aise avec les tests automatisés. Faire du CI

33 Qu est-ce que le CD? Chaque commit devrait être considéré comme un candidat potentiel pour la production. Chaque commit est une version de l application Chaque version a été testée et déployée dans un ou plusieurs environnements.

34 Comment? Automatiser le plus possible C est ici que les plus gros gains seront fait. Possiblement des milliers d heures seront sauvées Presque tout est automatisable Il faut le faire pour les configurations et les BDs!

35 Comment? Tout doit être dans le gestionnaire de code source. Les configs! L ajout d une nouvelle variable de configuration devrait être rattaché à une version Dans la vraie vie, c est complexe de préserver les valeurs dans le SC. Les avoir ailleurs est acceptable.

36 Comment? Tout doit être dans le gestionnaire de code source. Les détails de la BD! Une modification à la BD devrait être rattachée à une version de l application. L automatisation du déploiement devrait inclure la MAJ de la BD.

37 Ensuite? On continue d augmenter la confiance en notre nouvelle version. Plus le problème est détecté tôt, moins il est coûteux à régler. Plus le développeur est bien orienté, plus on sauve du temps

38 Pyramide de tests Gros Moyen Petit

39 Comment on orchestre tout ça? Avec un pipeline de déploiement.

40

41

42

43

44 Principes d un pipeline de déploiement On build l application une seule fois Déploiement de la même façon dans chaque environnement «Smoke-Test» les déploiements On déploie dans une «copy» de la production Chaque changement lance le pipeline Si une partie du pipeline brise, on arrête la ligne

45 Comment gère-t-on les versions entre elles? Exemple : 1 Projet Front-End, 1 projet back-end et plusieurs dépendances externes comme des Web API. 3 Solutions 1 Pipeline pour l entièreté de l application. (Tout est toujours déployé en même temps.) On ne brise pas de contrat entre les différentes parties. (On honore toujours les anciens contrats) Tests de contrats

46 Qu est-ce que le CD? Recap++ Chaque changement est un candidat pour une potentielle MEP Créer un procédé fiable et répétable pour la livraison. Automatiser presque tout. Préserver tout dans le gestionnaire de code source. On construit seulement sur de la qualité. Done veut dire livré Tout le monde est responsable du procédé de livraison

47 Comment on se mesure? Nombre de branches actives Nombre de bugs ouverts Durée entre chaque MEP Durée d une MEP

48 Références

49 Questions?!

50 Communauté Agile de Sherbrooke Merci de votre participation! N hésitez pas à nous faire part de vos commentaires ou suggestions Site web Facebook Agile-de-Sherbrooke /