DevOpsDays Montréal 2019 - Plusieurs changements ont eu lieu chez Croesus dans les trois dernières années. Cette étude de cas couvrent l’agilisation complet de notre compagnie et une rétrospective sur notre culture et nos pratiques DevOps. Quels ont été nos critères de succès et qu’avons-nous appris?

1. VERSION FR : Pour usage public
Étude de cas:
Agile et DevOps chez Croesus
Par Martin Deslongchamps, Croesus Finansoft

2. VERSION FR : Pour usage public
Mon nom est Martin Deslongchamps.
Je suis spécialiste en architecture DevOps, Product Owner, formateur et
contributeur dans l’équipe Continuous Everything chez Croesus!
Croesus // Future Of Code // SES // CAE // École Polytechnique (Génie Logiciel)
Bienvenue !
2

3. DevOpsDaysMontreal2019
Croesus est une entreprise de fintech
qui offre des solutions conviviales de
gestion de patrimoine.
Fondée en
1987
Siège social à Laval, et des bureaux à
Toronto
31 années en affaires
Société fermée

4. VERSION FR : Pour usage public
Agenda
4
1. DevOps chez Croesus
2. Union des gens et des processus
a. La loi de Conway et notre transformation agile
b. Les trois voies du DevOps
3. Les produits et outils utilisés
4. Nos réalisations

5. VERSION FR : Pour usage public5
DevOps chez Croesus
Quelle définition avons-nous adoptée?

6. VERSION FR : Pour usage public6
DevOps est l'union des gens, des processus et des
produits permettant la livraison continue de valeur
ajoutée pour nos clients.
- Microsoft

7. VERSION FR : Pour usage public
Loi de Conway
Transformation agile
7
Union des gens et des processus

8. VERSION FR : Pour usage public8
Loi de Conway
Les organisations qui conçoivent des systèmes...
sont contraintes de produire des designs qui sont
des copies de la structure de communication de leur
organisation.
- Wikipedia

9. VERSION FR : Pour usage public
Conway chez Croesus… avant 2019
9
1. Produits
2. Développement
3. Assurance Qualité
4. Opérations (IT)
Quatre grands départements travaillant en waterfall
De bons résultats malgré ce mode d’opération...
● Certification de plus de 90 versions par année
● Capable de livrer une version dans un environnement client dans la journée
● Communication à améliorer entre départements (existence des murs de la confusion)
La question qui reste: est-ce qu’on peut aller plus vite?

10. VERSION FR : Pour usage public
Pourquoi changer pour un modèle agile?
10
1. Travailler sur ce qui amène de la valeur à nos clients en premier
a. Liste maître
b. Avoir un meilleur contrôle de la priorisation du travail
c. Weighted Shortest Job First (WSJF)
2. Rendre le travail visible et transparent
a. Trouver nos goulots d’étranglements en les faisants ressortir
b. Améliorer et uniformiser nos processus
3. Travailler dans un modèle empirique permettant d’avoir du
feedback en tout temps
4. Augmenter la cadence de livraison (Incrément)

11. VERSION FR : Pour usage public
2019… Agile
11
● Décision prise par le Président
● Embauche d’un VP spécialisé dans ce type
de transformation
● Approche “Agnostique Agile”
● Rôles clairs ont été établis
○ BPM, TPM, BPO, TPO, SM, TL…
● Abolition des départements
● Responsabilités des produits développés
mieux définis
● Outil commun de communication (JIRA)
Réorganisation complète en équipe produit
https://agnosticagile.org/

12. VERSION FR : Pour usage public
Le défi culturel
12
● Nouvelle façon de travailler: Scrum
● Changement d’outil de communication
● Nouveaux rôles
● Communication inter-équipe différente
● Respect des responsabilités de chaque équipe
● Interdépendance de certaines équipes
● Communication entre les rôles
● Résistance au changement
● Prioriser les épics de la compagnie (>1200 épics)
Ne jamais sous-estimer les changements d’habitudes...

13. VERSION FR : Pour usage public
Les critères de succès
13
● Initiative prise par le Président
● Réclamée et demandée par les employés
● Ouverture des gestionnaires
● Adoption générale par les employés
● Prêt à investir dans la formation des employés
○ Nouveaux rôles
○ Nouveaux outils
○ Nouveaux processus
● Respect, courage, confiance, ouverture d’esprit et le focus
Ce qui nous a permis d’y croire...

14. VERSION FR : Pour usage public
Les avantages immédiats
14
● Plus de plaisir!
● Transfert de connaissance
● Responsabilités et ownership clairement établis
○ Établissement des lignes de travail claires
○ Diminution des outils internes orphelins
● Échelles de maturité ciblant les pratiques de l’Agile et du DevOps
● Visibilité et transparence du travail
● Favoriser l’autonomie et l’innovation au sein des équipes:
○ Expression des demandes en tant que besoin
○ Auto-organisation de l’équipe pour remplir le besoin
Un changement agile important!

15. VERSION FR : Pour usage public
Agile, agile… et DevOps?
15

16. VERSION FR : Pour usage public16
Les trois Voies du DevOps (The Three Ways)

17. VERSION FR : Pour usage public
DevOps: Les 3 Voies
17
Les trois Voies du DevOps:
1. Le principe de Flow
2. Le principe de Feedback
3. Le principe d’expérimentation
continue et d’apprentissage constant

18. VERSION FR : Pour usage public
Amélioration de notre maîtrise du Flow?
18
● Value Stream Mapping:
○ De la colle!
● Utiliser les pratiques de CI/CD
● Versions évolutives
● Augmentation de la fréquence de livraison
○ Pour réduire le nombre de changements livrés en production
● Changements de pratiques à l’interne
● Création du déploiement d’environnement en une étape
Comment faire pour aller plus vite?

19. VERSION FR : Pour usage public
Amélioration de notre maîtrise du Flow?
19
● Se donner la capacité de répondre aux besoins de notre business
● Réduction du nombre d’outils de communication (Lean)
● Déploiements plus sécuritaires et plus fiables
● Diminution du context switching
● Responsabilités mieux définies
● Visibilité et transparence:
○ Couplage entre certains produits
○ Équipes sur-utilisées ou sous-utilisées
● Amélioration de nos pratiques
○ Guidelines, code reviews, TDD, CI/CD...
Les répercussions...

20. VERSION FR : Pour usage public
Amélioration de notre maîtrise du
Feedback?
20
● Pipelines et intégration continue
● Implémentation de la pyramide de test
○ TDD
○ Refactoring et Mocking
● Autonomie des équipes:
○ Sprint reviews et rétrospectives
○ Prise en charge de leurs processus
○ Shift Left!
● Métriques DevOps? Prochainement!
Transparence-Inspection-Adaptation de nos produits!

21. VERSION FR : Pour usage public
Et la troisième Voie?
21
● Apprentissage:
○ Augmentation de la cadence de déploiement
○ Feature Flag management
○ Expérimentation lors des UAT
● % évolution dans les sprints
● Formations
● Ouverture vers les conférences
Expérimentation en continue et apprentissage constant
Cette dimension viendra avec l’augmentation de la maturité de nos équipes et avec la
maîtrise de la première et de la deuxième Voie du DevOps.

22. VERSION FR : Pour usage public22
Containers
Livraison continue
Gestion du code
Les produits et outils utilisés

23. VERSION FR : Pour usage public23
https://www.redhat.com/en/blog/history-containers
[...]
Early Days
The year 2000 was a busy one in the world of computing. 15 years ago, Bill Gates stood aside for Steve Balmer at Microsoft. The
NASDAQ Composite stock market index peaked at 5132.52, the beginning of the end for the dot-com boom. The patent on the
RSA cryptographic algorithm ended and the last Multics (Multiplexed Information and Computing Service) got turned off. And
jails, an early implementation of container technology, was added to FreeBSD.
In 2001, container technology made it to the Linux side of the house. Jacques Gélinas created the VServer project, which
according to the 0.0 version’s change log allowed “running several general purpose Linux server on a single box with a high
degree of Independence and security.”
The Linux-VServer solution was the first effort on Linux to “separate the user-space environment into distinct units (Virtual
Private Servers) in such a way that each VPS looks and feels like a real server to the processes contained within.” And though
the Linux-VServer project lacked process migration and clustering, its real weakness was that it required a patched kernel,
imposing an additional overhead on distributors and system administrators (or is it a feature?). [...]

24. VERSION FR : Pour usage public24
Les containers chez Croesus
● VServer: ancêtre de Docker
● VServer est toujours utilisé fortement chez Croesus
● Outillage pour gérer les VServers et leurs images
● Expérimentation avec VServer s’exécutant dans Docker
● Transition de VServer vers Docker et éventuellement Kubernetes
● Utilisation de Kubernetes et Rancher à l’interne pour:
○ la centralisation des logs
○ la gestion des clusters
● Création d’une interface entre la plateforme et les applications déployées
VServer, Docker et Kubernetes

25. VERSION FR : Pour usage public
Intégration et livraison continue
Qu’utilisons-nous pour déployer?
25
● Microsoft Team Foundation Server 2018.3 avec agents Linux
● Pipelines configurés en déploiement continu pour les tests
● Utilisation des approbations sur les environnements importants
● Création d’un pipeline principale pour le monolithe
● Utilisation de VeraCode dans les pipelines
● Analyse statique de code lors du push
● Utilisation fréquente de Docker pour builder

26. VERSION FR : Pour usage public
Gestion du code
TFVC et Git
26
● Utilisation croissante de Git
● Création de guidelines pour les tests
● Infrastructure as code pour les installations clients
● Système de branchement pour toute la compagnie
● Plan de transition vers Git
● Utilisation des Pull Requests et des politiques de branches:
○ Revue de code obligatoire
○ Contribue à une meilleure collaboration entre équipe
○ Avoir une branche principale en santé

27. VERSION FR : Pour usage public27
Nos réalisations...

28. VERSION FR : Pour usage public28
Augmentation de la qualité
Version évolutives
● Travail sur plusieurs années
● Périodes de stabilisation
● Fusion des branches de
codes propres à chaque
client
● Un seule code base!
● Diminution du nombre de
bugs

29. VERSION FR : Pour usage public29
● Déploiements automatisés pour plusieurs clients
○ Stabilité du déploiement
○ Meilleur taux de succès lors des demandes rapides de déploiements
● Équipes multidisciplinaires
● Abolition des départements
● Amélioration de nos pratiques
● 25+ équipes DevOps
Qu’avons-nous réalisé côté DevOps?

30. VERSION FR : Pour usage public
Qu’avons-nous réalisé côté Agile?
30
● Agilisation de l’ensemble de la compagnie (Disciplined Agile Enterprise)
● Priorisation de tous les épics de la compagnie
● Diminution drastique des changements de contexte
● Augmentation de la transparence du travail à faire
● Augmentation du nombre d’employés plus heureux au travail

31. VERSION FR : Pour usage public
J’espère vous revoir!
Où serons-nous rendu dans nos révolutions l’an prochain?
31
● Intégration du cloud?
● Équipes DevOps capable de déployer avec les mêmes outils que la production?
● De nouvelles échelles de maturité?
● Quelle sera la répercussion sur les clients d’avoir des équipes agiles plus matures?
● Intégration de Kubernetes à notre plateforme de déploiement?
● Améliorations des métriques et du monitoring?
Bref, on pourrait se revoir l’an prochain… À vous de voir!

32. VERSION FR : Pour usage public
Continuons la discussion!
32
@martindeslongchamps
Meetup Kubernetes Montréal
Meetup MCDC Montréal
Mon blog personnel
(https://thefutureofcode.com/)

33. VERSION FR : Pour usage public33
MERCI
Mes contributeurs:
● Guillaume Girard
● Patrick Chassé
● Benoît Caron
● Pascal Racine
● Daniel Cusson
● Bérénice Junca

34. VERSION FR : Pour usage public34
Questions