En résumé #
Tout le contenu du livre tourne autour des “Trois voies”, dont il est notamment question dans le livre The Phoenix Project, à savoir:
- Flow, qui accélère la livraison d’un travail réalisé, de l’équipe de développement, vers les opérateurs, jusqu’à une mise à disposition aux utilisateurs finaux
- Feedback, afin d’améliorer la qualité, la fiabilité et la sécurité en général, et qui permet ainsi de créer des systèmes sains, tout en garantissant des améliorations et optimalisations continues, grâce à la résolution (ou en tout cas, la recherche et la compréhension) de chaque problème dès qu’il se pose.
- Continual Learning and Experimentation, qui prône une culture de confiance et une approche scientifique des améliorations organisationnelles, tout en proposant de les intégrer au travail quotidien.
Le livre va également plus loin, en analysant des incidents & évènements qui se sont déroulés dans des grosses sociétés (un petit crash chez Amazon, la gestion des incidents chez Etsy, …) pour rebondir et présenter ce qui a permis à la société de s’en sortir, un peu à la manière de Release It!. Pour aller plus loin, et sans non plus proposer des solutions clés-en-main, les idées sont souvent (très) bonnes à prendre, peuvent être suivies plus ou moins les yeux fermés et devraient permettre d’arriver à une forme de synergie entre les développeurs, les opérateurs (systèmes) et la sécurité.
Donc, sans aller jusqu’à “modifier la ligne 137 de votre fichier main.c”, on y trouve beaucoup, beaucoup de pistes de réflexions et de choses à modifier/mettre en place pour améliorer, non seulement la qualité, mais également le confort de travail.
Quelques définitions #
Continuous Delivery
[…] Jez Humble and David Farley extended the concept of continuous build, test and integration to continuous delivery, which defined the role of a “deployment pipeline” to ensure that code and infrastructure are always in a deployable state, and that all code checked in to trunk can be safely deployed into production
(Introduction, page 5).
Value Stream
The same principles and patterns that enable the fast flow of work in physical processed are equally applicable to technology work (and, for that matter, for all knowledge work). In DevOps, we typically define our technology value stream as the process required to convert a business hypothesis into a technology-enabled that delivers value to the customer.
[…]
Because value is created only when our services are running into production, we must ensure that we are not only delivering fast flow, but that our deployments can also be performed without causing chaos and siruptions such as service outages, service impairments, or security or compliance failures
(Introduction, page 8)
Conway’s Law
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
– Melvin E. Conway
Imposter syndrome
The imposter syndrome is a term coined by psychologists to informally describe people who are unable to internalize their accomplishments. Wikipedia states that “despite external evidence of their competence, those exhibiting the syndrome remain convinced that they are fraud and do not deserve the success they have achieved. Proof of success is dimissed as luck, timing, or as a result of deceiving others into thinking they are more intelligent and competent than they belive themselves to be.
– Part III - The practices of Flow (page 124)
Réalisation d’une tâche
At the end of each development interval, we must have integrated , tested, working, and potentially shippable code, demonstrated in a production-like environment, created from trunk using a one-click process, and validated with automated tests.
Principes #
Flow #
En l’état, dans beaucoup de boites, le flux de travail ressemble beaucoup à ceci:
[…] daily work becomes dominated by the priority du jour, often with requests for urgent work coming in through every communication mechanism possible, including ticketing systems, outage calls, emails, phone calls, cat rooms and management escalations.
Il y a deux aspects (ou rôles) impactés: les responsables, qui ont besoin de visualiser les tâches bloquées ou qui prennent du temps, et les exécutants, qui doivent gérer les interruptions quotidiennes.
Une des solutions consiste à limiter les tâches à un plafond (trois sont proposées), pour éviter que les tâches en cours ne s’accumulent. Si nécessaire, il faut aussi que les personnes se libèrent ou se rencontrent pour éviter qu’elles ne démarrent autre chose ou n’attendent que les autres ressources soient disponibles. De cette manière, nous pouvons nous assurer d’un flux continu (ininterrompu ?) entre la déclaration d’une tâche et sa complétion. En même temps, cette continuité de flux est difficile à atteindre, notamment à cause d’une (mauvaise ou difficile) communication: définition des tâches, spécifications, coordination, prioritisation, planification, gestion de conflits, tests et vérifications. Chacune de ces étapes nécessite l’utilisation de systèmes de tickets, d’écrire des spécifications fonctionnelles ou techniques, d’organiser des réunions, d’envoyer des emails ou des appels téléphoniques. Et en plus, le temps à la mise en route de ces tâches est tellement complexe, qu’une élévation est constamment nécessaire pour que le travail soit exécuté endéans des limites temporelles.
To help us see where work is flowing well and where work is queued or stalled, we need to make our work as visible as possible. One of the methods of doing this is using visual work boards (Kanban or sprint plannings)
(Chapitre 2, page 16)
En bref, il est archi-compliqué d’arriver à fluidifier un flux de tâches. Toute ces étapes constituent des déchets [^1] qui peuvent s’apparenter à l’une des catégories suivantes:
- Un travail partiellement terminé inclut n’importe quel tâche qui n’aurait pas encore été terminée (des documents de spécifications ou une revue de code à réaliser) ou une tâche en attente de complétion (attendre qu’un QA soit disponible). Chaque travail partiellement terminé devient obsolète et perd de sa valeur à mesure que le temps passe.
- Les processus supplémentaires (extra processes) regroupent toute tâche complémentaire qui doit être réalisée, mais qui n’ajoute aucune valeur à ce que le client attend. Cela peut inclure la rédaction de documentation qui ne servira plus à rien, des processus de revue ou d’approbation qui n’ajoutent aucune valeur au résultat. Ces processus supplémentaires demandent des efforts et prolongent le temps nécessaire à la complétion d’une tâche.
- Le basculement de tâches, quand des personnes sont assignées à plusieurs projets, ce qui leur demande de changer constamment de contexte et de gérer des interdépendances.
- L’attente, qui reprend simplement les délais de disponibilité de ressources nécessaires
- Les mouvement, qui nécessite pour une personne, de se déplacer pour communiquer et obtenir un résultat. Une des difficultés intervient quand deux personnes qui doivent communiquer régulièrement ne sont pas colocalisées. Le mouvement couvre aussi le transfert de responsabilité pour une même tâche ou travail à réaliser.
- Les défectuosités, qui regroupent toutes les informations/produits/composants incorrects, manquants ou flous. Au plus le temps s’écoule entre la création et la détection d’une défectuosité, au plus elle sera difficile à corriger.
- Le travail non standard manuel qui doit être accompli par une tierce personne, comme par exemple toute dépendance liée à un environnement. Chaque tâche pouvant être automatisée doit l’être. Idéallement, chaque dépendance à un autre équipe (Opérations ou Infra) devrait automatisable, se trouver en libre-service et être disponible à la demande.
- L’héroïsme ou une forme de crunch, qui va placer une équipe sous une très forte pression durant une période de temps théoriquement courte, mais qui va en pratique s’éterniser: problèmes en production, réveils à 2h du mat’, charge de travail administrative en lien avec chaque release, …
Améliorer le flux est essentiel pour obtenir améliorer la qualité du travail et la rapidité avec laquelle une valeur supplémentaire peut être mise à disposition.
Cela peut être réalisé en rendant le travail transparent, en limitant les tâches en cours, en réduisant la quantité de sous-tâches à réaliser et le nombre de changement d’interlocuteurs. Cela nécessite également de continuellement identifier et évaluer les contraintes, et d’éliminer les difficultés et épreuves du travail au quotidien.
Feedback #
Le deuxième principe consiste à activer une forme de retour réciproque et constant d’informations de la droite vers la gauche, c’est-à-dire qu’au lieu de réaliser une tâche ou une étape et de se déresponsabiliser de son résultat, nous nous attendrons à un retour rapide d’informations.
Une des raisons est qu’au vu de la complexité de certains systèmes, en connaître ou en expliquer tous les rouages est impossible pour une seule et même personne. Une deuxième raison, toujours en lien avec les systèmes complexes, est que la réalisation de deux choses identiques ne donne pas systématiquement le même résultat.
Obtenir un feedback permet notamment de modifier la direction choisie: au plus vite ce feedback peut être réalisé, au plus il est facile de modifier certains choix ou décisions, et d’ainsi limiter l’impact complet. Un exemple notable concerne les développements type Waterfall, où le feedback n’était parfois obtenu que plusieurs mois après le développement d’une fonctionnalité (et généralement beaucoup trop tard).
Le retour d’informations peut être amélioré grâce aux propositions suivantes:
- Mise en place d’une télémétrie omniprésente, afin de vérifier que chaque composant du système tourne correctement, mais également pour mesurer que les objectifs sont atteints.
- Organisation d’un essaimage lorsqu’un problème est rencontré: plutôt que de laisser le problème sur le côté et le planifier pour plus tard, toutes les ressources possibles sont mobilisées afin de corriger les incidents dès qu’ils sont détectés. Ceci autorise donc un problème local à perturber une chaine de production, mais évite en parallèle que celui-ci ne rayonne, voire n’aggrave, les tâches ultérieures.
Au plus ces processus d’introspection sont rapprochés de la source (de création), au plus la qualité globale augmente.
Chaque personne devrait ainsi chercher et résoudre les problèmes qu’elle trouve son domaine d’expertise. Pour aller dans ce sens, la mise en place de processus de type peer review permet un gain en qualité et en confiance, dans la mesure où chaque tâche revue par une personne appartenant à un même domaine d’expertise augmente la qualité perçue et la confiance des délivrables. Indirectement, cela permet aussi une forme d’auto-formation, une élévation des compétences et un accompagnement des personnes ayant moins de connaissances.
En réalisant tout ceci, nous rendons chacun responsable de l’ensemble de son propre travail; la sécurité informatique par exemple, est de la responsabilité de tous et pas uniquement d’un département ou d’une équipe en particulier.
Continual Learning and Experimentation #
Un des premiers points d’améliorations continue concerne la compréhension et l’enregistrement des incidents passés, afin de pouvoir aider à une résolution (rapide) d’incidents similaires, en se basant sur les contremesures qui ont été appliquées pour y remédier. [^2] Il est important que chaque action soit enregistrée et mise à disposition de manière transparente.
L’objectif est de produire un post-mortem détaillé, mais qui ne rejette la faute sur personne en particulier, sans quoi les intervenants seront enclins à mentir et à se sentir observés. Ce rencensement des incidents et leur mise à disposition améliore également la connaissance générale et la capacité à résoudre rapidement des problèmes semblables à quelque chose qui se serait déjà produit. Ces mécanismes permettent ainsi de convertir une expertise individuelle en artefacts utilisables partout dans le reste de l’organisation.
Ensuite, Mike Rother (auteur de Lean IT) remarque qu’en l’absence d’améliorations, les processus se dégradent, notamment à cause du chaos ambiant et de l’entropie. Plus important que le travail quotidien: l’amélioration du travail quotidien.
En pratique #
Flow #
Le point principal pour obtenir une fluidité dans la réalisation des tâches, consiste à viser une livraison en continu, en:
- Création de fondations d’un pipeline de déploiment visant à une automatisation complète
- Automatisation de tests fiables et rapides
- Conformisation aux principes d’intégration continue
- Architecture des solutions pour qu’elles présentent le moins de risques possibles.
Un pipeline de déploiement se crée dès que les informations et déclarations pertinentes sont auto-contenues - c’est-à-dire, lorsqu’une application est capable de décrire elle-même l’infrastructure ou les composants dont elle a besoin pour se mettre en place de façon autonome. [^3]
Un des prérequis concerne également la création d’un Single Repository of Truth, c’est-à-dire une forme de garant de la vérité, qui peut être accomplie au travers d’un dépôt unique contenant tout le code source lié à un domaine d’activités, afin de pouvoir toujours restaurer l’état d’une application à partir d’une seule et même source, indépendamment de son contexte d’exécution. Il est également question de ce point au niveau de la méthodologie des 12 facteurs. Ce dépôt unique facilite également la communication pour toute personne qui travaille dans ce domaine d’activités - que ce soit les équipes de développement, la QA, InfoSec ou les Opérations.
Cette méthode oriente et facilite également la reconstruction plutôt que la réparation, où il est demandé aux intervenants de traiter les serveurs comme du bétail plutôt que comme des animaux de compagnie [^4] On évitera ainsi de nommer ses petits serveurs avec des noms affecteux, en les traitant différement les uns des autres: l’objectif est que deux serveurs démarrés avec des mêmes paramètres soient interchangeables, et puissent être détruits ou reconstruits si besoin en est. Il est question ici de immutable infrastructure, où un changement (manuel) sur un environnement de production n’est plus autorisé. La seule possibilité pour qu’un changement soit réalisé est de repasser par chaque étape du pipeline, et que l’environnement de production soit reconstruit avec les nouveaux paramètres, après que tous les tests et vérifications aient été effectués (automatiquement, cela va sans dire). De cette manière, aucun écart n’est autorisé en production. [^6]
Un dernier point consiste à réaliser des itérations très courtes et à modifier sa propre de définition de “réalisé”: une tâche est terminée lorsqu’elle est en production et pas uniquement lorsqu’elle a été prouvée comme fonctionnant correctement à un endroit du code. Une proposition de définition plus complète est celle-ci:
Les tests doivent donc couvrir le code - ou, en tout cas, les principaux points d’entrée -, ce qui fera partie des métriques collectées. Si une portion de code passe ces tests, elle sera automatiquement fusionnée dans le tronc commun du dépôt de versions. Il est nécessaire ici de disposer:
- D’un pipeline d’intégration continue vérifiant un ensemble de tests automatisés compréhensibles et fiables, qui valident que nous nous trouvons dans un état autorisant une mise à disposition,
- D’une culture qui “arrête l’ensemble de la chaîne de production” dès qu’un test de validation échoue,
- De développeurs qui travaillent selon des itérations courtes. Au plus une branche du code existe depuis longtemps, au plus il sera difficile de s’y raccrocher. Une branche doit ainsi avoir une existence relativement courte, afin de rendre cette tâche de réconciliation la moins pénible possible.
Feedback #
In short, slow and periodic feedback kills. – Part III - The Principles of Flow (page 130)
La récupération de métriques augmente la confiance que l’on peut avoir dans la solution. L’analyse de ces métriques garantit un juste retour d’informations, sous réserve qu’elles soient exploitées correctement. La première étape consiste à agréger ces données dans un dépôt centralisé, tandis que la seconde étape exigera une structuration correcte des données envoyées.
- La Collecte des données doit récupérer des données des couches métiers, applicatives et d’environnement. Ces données couvrent les évènements, les journaux et les métriques - indépendamment de leur source - le pourcentage d’utilisation du processeur, la mémoire utilisée, les disques systèmes, l’utilisation du réseau, …
- Métier: Le nombre de ventes réalisées, le nombre de nouveaux utilisateurs, les résultats de tests A/B, …
- Application: Le délai de réalisation d’une transaction, le temps de réponse par utilisateur, …
- Infrastructure: Le trafic du serveur Web, le taux d’occupation du CPU, …
- Côté client: Les erreurs applicatives, les transactions côté utilisateur, …
- Pipeline de déploiement: Statuts des builds, temps de mise à disposition d’une fonctionnalité, fréquence des déploiements, statuts des environnements, …
- Le choix de l’outil d’agrégation doit permettre de collecter, enregistrer, visualiser, alerter, détecter des anomalies et appliquer des transformations statistiques. [^5]
As Adrian Cockcroft pointed out, “Monitoring is so important that our monitoring systems need to be more available and scalable than the systems being monitored. – Part IV - The Technical Practice of Feedback - Create Telemetry to enable seeing and solving problems (page 200)
Par exemple, si un serveur Nginx arrête de répondre aux requêtes, il serait possible de corréler cet incident avec d’autres métriques: augmentation du temps de réponse (Application), mémoire disponible en baisse sur le serveur (Infrastructure), temps nécessaire à la réalisation d’une transaction sur la base de données (Infrastructure également). [^7]
Histoire de schématiser, toute équipe se retrouve à un moment où un autre dans la situation suivante: personne ne veut appuyer sur le gros bouton rouge issu de l’automatisation de la chaîne de production et qui dit “Déploiement”. Et pour cause: une fois que nous aurons trouvé une joyeuse victime qui osera braver le danger, il y aura systématiquement des imprévus, des petits détails qui auront été oubliés sur le côté de la route, et qui feront lâchement planter les environnements. Et puisque nous n’aurons pas (encore) de télémétrie, le seul moment où nous comprendrons qu’il y a un problème, sera quand un utilisateur viendra se plaindre.
Un dernier point d’amélioration concerne la création de peer-reviews ou code-reviews. L’objectif est de trouver les erreurs en demandant l’avis de collègues directs ou de personnes plus expérimentées. La revue de code améliore la qualité des modifications apportées, ce qui crée également des améliorations au niveau des échanges, compétences et du nivellement de l’équipe par le haut. Ces code-reviews doivent cependant être limitées au strict nécessaire:
As Giray Özil tweeted, “Ask a programmer to review ten lines of code, he’ll find ten issues. Ask him to do five hundred lines, and he’ll say it looks good. – Part IV - Create revie and coordination processes to increase quality of our current work (page 256)
Continual Learning and Experimentation #
En 2008, l’intégralité de Netflix tournait sur une stack J2EE. A partir de 2009, ils ont commencé à réorganiser leur architecture vers une infrastructure cloud-native, destinée à tourner exclusivement sur AWS, et pour survivre en cas d’incident majeur.
Un de leurs objectifs était de s’assurer que les services continuent à tourner, même si toute une zone de disponibilité d’Amazon venait à tomber, ce qui est arrivé en 2013. Leur architecture était suffisamment découplée que pour résister à cet incident: chaque composant étant développé pour tomber rapidement (fail fast), sans entraîner tout le système avec lui. De manière très élégante, en cas de soucis et si le pourcentage d’utilisation des CPU explosait, les utilisateurs se voyaient proposer du contenu statique mis en cache, plutôt que des listes de propositions personnalisées.
This is an example demonstrating that proactively focusing on resilience often means that a firm can handle events that may cause crises for most organizations in a manner that is routine and mundane. Specific architectural patterns that they implemented included fail fasts (settings aggressive timeouts such that failing components don’t make the entire system crawl to a halt), fallbacks (designing each feature to degrade or fall back to a lower quality representation), and feature removal (removing non-critical features when they run slowly from any given page to prevent them from impacting the member experience). Another astonishing example of the resilience that the netflix team created beyond preserving business continuity during the AWS outage, was that they went over six hours into the AWS outage before declaring a Sev 1 incident, assuming that AWS service would eventually be restored (i.e., “AWS will come back… it usually does, right ?”). Only after six hours into the outage did they activate any business continuity procedures. – Part V, Enable and Inject Learning into Daily Work (page 282)
En cas d’incidents, la culture de l’entreprise doit mener à la rédaction d’un post mortem et ne rien reprocher à personne. La question à se poser, si la faute revient à quelqu’un en particulier, n’est pas de savoir ce qu’on va faire de son corps après l’avoir pendu et brûlé, mais plutôt “Pourquoi est-ce que cette action avait du sens quand elle a été réalisée ?”.
Au même titre qu’il existe des stories pour les équipes de développement, il devrait exister des ops-stories qui représentent les activités de support, et qui pourraient être réutilisées dans différents projets. De cette manière, les tâches répétées sont exposées au même titre que les autres tâches à réaliser en vue de l’achèvement d’une fonctionnalité. Ceci permet une meilleure planification et l’obtention de résultats plus précis.
After all, how are we ever going to see the next innovation that helps us win if we’re not exploring and testing at the edges ? – Part V, chapitre 20, page 297
Intégration de la Sécurité de l’Information #
Plutôt que de réfléchir à intégrer la sécurité dans nos applications uniquement à la fin des processus, l’objectif est de les intégrer au plus tôt dans les flux d’activités, de la même manière que ce dont nous avons discuté pour les étapes de Flow et Feedback. Cette manière de travailler permet également de fournir plus facilement des preuves de bon fonctionnement aux auditeurs, évaluateurs, ou n’importe qui d’autres dans l’institution. Pour y arriver, il faut:
- Intégrer la sécurité comme une tâche dans le travail quotidien
- Intégrer des contrôles préventifs directement au niveau du pipeline et du dépôt de sources [^9]
Nick Galbreath, who headed up Information Security at Etsy for many years, describes how they treated security issues, “We put all security issues into JIRA, which all engineers use in their daily work, and they were either ‘P1’ or ‘P2’, meaning that they had to be fixed immediately or by the end of the week, even if the issue is only an internally-facing application.
Furthermore, he states “Any time we had a security issue, we would conduct a post-mortem, because it would result in better educating our engineers on how to prevent it from happening again in the future, as well as a fantastic mechanism for transferring security knowledge to our engineering team. Part VI, Chapitre 22, page 315
Au niveau du dépôt de sources, il convient d’y ajouter:
- Les librairies standards, leur utilisation et leur configuration (2FA, …)
- Comment gérer les injections SQL, le cross-site-scripting, …
- Comment gérer les secrets dans les applications: comment gérer les mots de passe, les journaux de logs
- Les paquets à utiliser et à compiler (NTP pour synchroniser les horloges, les paramètres d’OpenSSL, …), les configurations d’Nginx/Apache, …
L’objectif final est d’utiliser les mêmes méthodes de travail pour le développement, que pour les équipes d’opérations, que pour la sécurité de l’information, en poussant jusqu’à l’intégration de la télémétrie à chaque niveau de la chaîne de production, mais aussi en prouvant aux développeurs (en début de chaîne) qu’ils sont constamment sous attaque informatique, afin de les sensibiliser.
Gestion du changement #
Il existe différents types de risques associés à différents types de changement, et chacun de ces changements doivent être gérés différement. Dans ITIL, ceux-ci sont répartis en trois catégories:
- Changement standard, qui est un changement présentant peu de risque, et qui suit des processus bien établis.
- Changement normal, qui nécessite une revue ou une approbation par une autorité d’autorisation.
- Changement urgent, qui doit être mis en production immédiatement.
Dans tous les cas, ces changements doivent être mis en relation avec les outils de planification (JIRA, Rally, LeanKit, …), afin de spécifier un préimètre et des risques précis et qui nécessitera le moins de travail de remise en contexte par la personne qui réalisera l’approbation.
Kazen blitz #
Dr. Spears explains “… blitzes often take this form: a group is gathered to focus intently on a process with problems. The blitz lasts a few days, the objective is process improvement, and the means are the concentrated use of people from outside the process to advice those normally inside the process. Spears observes that the output of the improvement blitz team will often be a new approach to solving a problem, such as new layouts of equipment, new means of conveying material and information, a more organized workspace, or standardized work. They may also leave behind a to-do list of changes to be made down the road. – Part V - Chapitre 21 - page 300
Un autre objectif consiste à poursuivre la dette technique, en vue de l’annihiler.
Notes #
Structure des journaux #
La structure des niveaux de journaux est essentielle.
When deciding whether a message should be ERROR or WARN, imagine being woken up at 4 a.m. Low printer toner is not an ERROR. – Dan North, former ToughtWorks consultant
- DEBUG: Il s’agit des informations qui concernent tout ce qui peut se passer durant l’exécution de l’application. Généralement, ce niveau est désactivé pour une application qui passe en production, sauf s’il est nécessaire d’isoler un comportement en particulier, auquel cas il suffit de le réactiver temporairement.
- INFO: Enregistre les actions pilotées par un utilisateur - Démarrage de la transaction de paiement, …
- WARN: Regroupe les informations qui pourraient potentiellement devenir des erreurs.
- ERROR: Indique les informations internes - Erreur lors de l’appel d’une API, erreur interne, …
- FATAL (ou EXCEPTION): … généralement suivie d’une terminaison du programme ;-) - Bind raté d’un socket, etc.
Quelques considérations sur les tests #
Tests are part of the system – Robert C. Martin, Clean Architecture
Les tests unitaires ciblent typiquement une seule fonction, classe ou méthode, de manière isolée, en fournissant au développeur l’assurance que son code réalise ce qu’il en attend. Pour plusieurs raisons (et notamment en raison de performances), les tests unitaires utilisent souvent des données stubbées - pour éviter d’appeler le “vrai” service.
The aim of a unit test is to show that a single part of the application does what programmer intends it to.
Les tests d’acceptance vérifient que l’application fonctionne comme convenu, mais à un plus haut niveau (fonctionnement correct d’une API, validation d’une chaîne d’actions effectuées par un humain, …).
The objective of acceptance tests is to prove that our application does what the customer meant it to.
Les tests d’intégration vérifient que l’application coopère correctement avec les systèmes périphériques.
Martin Fowler observes that, in general, “a ten minute build [and test process] is perfectly within reason… [We first] do the compilation and run tests that are more localized unit tests with the database completely stubbed out. Such tests can run very fast, keeping within the ten minutes guideline. However any bugs that involve larger scale intercations, particularly those involving the real database, won’t be found. The second stage build runs a different suite of tests [acceptance tests] that do hit the real database and involve more end-to-end behavior. This suite may take a couple of hours to run.
De manière plus générale, si nous nous rendons compte que les tests sont trop compliqués à écrire ou nous coûtent trop de temps, c’est sans doute que l’architecture de la solution n’est pas adaptée et que les composants sont couplés les uns aux autres. Dans ces cas, il sera nécessaire de refactoriser le code, afin que chaque module puisse être testé indépendamment des autres.
Au final, le plus important est de toujours corréler les phases de tests indépendantes du reste du travail (de développement, ici), en l’automatisant au plus près de sa source de création
[^1] > […] the commonly used definition [of waste in the value stream] in Lean is “the use of any material or resource beyond what te customer requires and is willing to pay for.
[^2] Etsy a ainsi créé l’outil Morgue (maintenant archivé), afin d’épingler plus précisément chaque incident sur un calendrier.
[^3] On parle ici de Vagrant, d’ images VMware, de Puppet, Chef, Ansible, Debian preseed, OpenStack, Azure ou Docker.
Il y a d’autres types de tests, mais que nous pourrions plutôt caractériser comme des tests de ciblage: est-ce que telle fonctionnalité sera plus appréciée, que doit-on construire, quel sera le retour sur investissement, … ? Au niveau des méthodes, il est ainsi possible de recourir à des dévelopements oriéntés “hypothèses” [^8] ou des tests de type A/B Testing.
[^4] Cattle, not pets.
[^5] Par exemple: Nagios, Zappix, LogStash, Datadog ou Riemann. Mais voir aussi du côté de StatsD, Grafana et Graphite.
[^6] Comme ces outils allouent ou demandent des ressources de manière dynamique, il convient de maintenir la CMDB (ou tout autre méthode équivalente) à jour de manière dynamique également. Ceci peut être réalisé au travers d’outils comme ZooKeeper, Etcd ou Consul.
[^7] Oculus (également archivé), OpsWeekly ou Skyline (archivé!)
[^8] Hypothesis-Driven Development
[^9] Gauntlt, Code Climate, Brakeman, Dependabot ou OWASP.