"Guide pratique DevOps" - Notes de lecture (4)

<-Suite de l'article précédent->

Partie 3, première étape : pratique de la technologie des flux

L'objectif de la partie III est de créer les pratiques techniques et l'architecture nécessaires pour permettre un flux constant et rapide du travail de développement vers les opérations sans perturber les environnements de production ni perturber le service client. Cela signifie réduire le risque de déploiement et de publication des modifications en production. Ceci est réalisé grâce à un ensemble de pratiques techniques appelées livraison continue .

11. Appliquer et pratiquer l'intégration continue

Le rôle principal des branches dans les systèmes de contrôle de version est de permettre aux développeurs de travailler en parallèle sur différents composants du système logiciel, tout en empêchant le code soumis par les développeurs d'affecter la stabilité du tronc (parfois également appelé master ou mainline). , ou introduire des erreurs.

Cependant, plus un développeur travaille seul sur sa propre branche, plus il devient difficile de fusionner les modifications dans le tronc. En fait, lorsque le nombre de branches et le nombre de modifications sur chaque branche augmentent en même temps, la difficulté de fusion augmente fortement.

Les problèmes d'intégration peuvent entraîner de nombreuses retouches, notamment la nécessité de résoudre des modifications contradictoires via des fusions manuelles et la collaboration de plusieurs développeurs pour résoudre les problèmes de fusion qui entraînent l'échec des tests automatisés ou manuels. Parce que dans le modèle de développement traditionnel, le travail d'intégration de code a généralement lieu à la fin du projet, donc lorsque le travail d'intégration prend trop de temps, nous devons réduire les coûts afin de publier à temps.

Cela conduit à un autre cercle vicieux : comme la fusion de code est si douloureuse, les gens fusionnent simplement moins souvent, ce qui rend les fusions futures encore plus douloureuses. L'intégration continue vise à résoudre ce problème en intégrant la fusion dans le travail quotidien.

11.1 Développement de petits lots et fusion de grands lots

Chaque fois qu'une modification de code soumise au système de contrôle de version entraîne l'échec du pipeline de déploiement, nous travaillons ensemble pour résoudre le problème et nous efforçons de restaurer le pipeline de déploiement à un état vert le plus rapidement possible. Cependant, si les développeurs travaillent sur leurs propres branches (également appelées « branches de fonctionnalités ») pendant de longues périodes et ne fusionnent du code qu'occasionnellement dans le tronc, alors chaque fusion qu'ils effectuent introduira un grand nombre de modifications dans le tronc, ce qui peut entraîner de sérieux problèmes.Le problème.

Bien qu’il existe de nombreux types de stratégies de branchement, elles peuvent être divisées en deux catégories :

• Productivité personnelle accrue : chacun travaille sur sa propre branche. Tout le monde travaille de manière indépendante et ne peut pas interférer avec les autres ; cependant, la fusion de codes serait un cauchemar. La collaboration deviendra très difficile et chacun devra fusionner le code avec soin pour compléter même les plus petites parties du système.
• Améliorez la productivité des équipes : tout le monde travaille dans le même domaine. Il n'y a pas de branches, juste un long tronc ininterrompu ; il n'y a pas de règles, le processus de soumission de code est donc simple. Cependant, n’importe quel commit peut détruire l’ensemble du projet et provoquer son interruption.

Ward Cunningham a développé le premier système wiki au monde et a inventé le terme « dette technique ». En décrivant la dette technique, il a déclaré que si la base de code ne peut pas être refactorisée de manière proactive, elle deviendra lentement difficile à modifier et à maintenir, et le taux d'ajout de nouvelles fonctionnalités ralentira également. L'objectif principal de l'intégration continue et des pratiques de développement basées sur le tronc est de résoudre ces problèmes, améliorant ainsi la productivité de l'équipe sur la base de l'amélioration de la productivité individuelle.

11.2 Appliquer des pratiques de développement basées sur le tronc

La solution au problème de la fusion groupée consiste à appliquer des pratiques d'intégration continue et de développement basées sur le tronc afin que chaque développeur valide le code dans le tronc au moins une fois par jour. Cela peut réduire le nombre de validations de code dans la charge de travail quotidienne de l'équipe de développement. Plus les développeurs s'engagent fréquemment, plus chaque validation est petite et plus ils sont proches de l'état de flux idéal en une seule pièce.

La soumission fréquente du code au backbone signifie que tous les tests automatisés peuvent être effectués sur l'ensemble du système logiciel, et lorsqu'un problème survient dans une certaine partie de l'application ou de l'interface, des informations d'alerte peuvent être reçues en temps opportun. Les problèmes de fusion étant découverts rapidement, ils peuvent également être résolus rapidement.

Nous pouvons même configurer notre pipeline de déploiement pour refuser d'accepter toute validation (telle que des modifications de code ou des modifications d'environnement) qui font sortir le système d'un état déployable. Cette approche est appelée soumission fermée , c'est-à-dire que le pipeline de déploiement doit confirmer que les modifications soumises peuvent être fusionnées et construites avec succès normalement, et que tous les tests automatisés ont réussi avant d'être fusionnés dans le tronc. Si un test échoue, les développeurs en sont informés afin qu'ils puissent résoudre le problème eux-mêmes sans affecter les autres acteurs de la chaîne de valeur.

Après avoir appliqué ces pratiques, nous réviserons la définition de « terminé » (le texte en gras est un nouveau contenu) : « À la fin de chaque cycle d'itération, le code fonctionnel et livrable a été intégré et testé dans un environnement de type production ; Le code est créé sur le tronc via un processus en un clic et a passé avec succès les tests automatisés. »

11.3 Résumé

Le développement basé sur le tronc est probablement la pratique la plus controversée de ce livre. De nombreux ingénieurs pensent que cela ne fonctionnera pas et préfèrent travailler sur leurs propres branches sans avoir à collaborer avec d'autres développeurs. Cependant, le rapport State of DevOps 2015 de Puppet Labs montre que le développement basé sur le tronc peut conduire à une productivité plus élevée, une meilleure stabilité, une satisfaction professionnelle encore plus élevée et des taux d'épuisement professionnel inférieurs.

S'il est difficile de convaincre les développeurs au début, une fois qu'ils ont pris conscience des avantages significatifs, c'est un changement complet. Les pratiques d'intégration continue ouvrent la voie à la prochaine étape vers des processus de déploiement automatisés à faible risque.

12. Versions automatisées et à faible risque

Ce chapitre vise à permettre à l'équipe d'exploitation et de maintenance ou à l'équipe de développement de déployer fréquemment et facilement en réduisant les frictions liées au déploiement de l'environnement de production. Nous y parvenons en faisant évoluer le pipeline de déploiement.

Au lieu de simplement intégrer continuellement le code dans un environnement de type production, nous serons en mesure d'automatiser les tests et la vérification à la demande (c'est-à-dire une publication en un clic) ou automatiquement (c'est-à-dire un déploiement automatisé directement après une construction et des tests réussis). Toute version du processus est mis en production.

12.1 Processus de déploiement automatisé

Après avoir entièrement documenté le processus de déploiement actuel, l'étape suivante consiste à simplifier et automatiser autant que possible les étapes manuelles, par exemple :

• Regroupez le code dans un format facile à déployer ;
• Créez des images ou des conteneurs de machines virtuelles préconfigurés ;
• Automatiser le déploiement et la configuration du middleware ;
• Copiez le package d'installation ou les fichiers sur le serveur de production ;
• Redémarrez le serveur, l'application ou le service ;
• Générer des fichiers de configuration basés sur des modèles ;
• S'assurer que le système fonctionne correctement et est correctement configuré en effectuant des tests de fumée automatisés ;
• Exécuter divers programmes de tests ;
• Scriptez et automatisez les efforts de migration de bases de données.

La plupart des outils dotés de capacités d'intégration et de test continues ont également la capacité d'étendre le pipeline de déploiement. Ces outils peuvent publier la version vérifiée en production, généralement après l'exécution des tests d'acceptation de production (ces outils incluent le plug-in Jenkins Build Pipeline, GoCD et Snap CI de ThoughtWorks, Microsoft Visual Studio Team Services et Pivotal Concourse).

Le pipeline de déploiement présente les exigences suivantes :

• Gérez le déploiement dans tous les environnements de la même manière : en utilisant le même mécanisme de déploiement pour tous les environnements (par exemple, développement, test et production), vous pouvez augmenter le taux de réussite du déploiement dans l'environnement de production, car il a été déployé avec succès dans le pipeline. fois.
• Effectuez des tests de fumée sur le déploiement : pendant le processus de déploiement, vous devez tester si tous les systèmes dépendants (tels que les bases de données, les bus de messages et les services externes) sont accessibles normalement et voir si le système fonctionne correctement via un seul test. Si l'un des tests ci-dessus échoue, le déploiement échoue.
• Maintenir la cohérence de l'environnement : les étapes ci-dessus créent un processus de création d'environnement en une seule étape, de sorte que l'environnement de développement, l'environnement de test et l'environnement de production disposent d'un mécanisme de création commun. Il est nécessaire de veiller en permanence à ce que ces environnements soient construits de manière cohérente

12.1.1 Déploiement en libre-service de l'automatisation des applications

Pour mieux faciliter le travail, il doit exister un processus de publication de code qui peut être exécuté par les développeurs ou le personnel d'exploitation et, idéalement, ne devrait nécessiter aucune opération manuelle ni transfert de travail. Les étapes de ce processus sont les suivantes.

• Build : le pipeline de déploiement doit être basé sur un système de contrôle de version pour créer des packages pouvant être déployés dans n'importe quel environnement, y compris la production.
• Tests : n'importe qui devrait pouvoir exécuter n'importe quelle suite de tests automatisés sur son poste de travail ou son système de test.
• Déploiement : n'importe qui devrait pouvoir déployer ces packages dans n'importe quel environnement auquel il a accès en exécutant un script (validé dans le système de contrôle de version).

Les pratiques ci-dessus vous aideront à exécuter le déploiement avec succès, peu importe qui le fait.

12.1.2 Intégration du déploiement de code dans le pipeline de déploiement

Si le processus de déploiement du code est automatisé, il peut faire partie du pipeline de déploiement. Par conséquent, le déploiement automatisé doit avoir les fonctionnalités suivantes :

• S'assurer que les progiciels construits pendant la phase d'intégration continue peuvent être déployés dans l'environnement de production ;
• Indiquez clairement l'état de préparation de votre environnement de production en un coup d'œil ;
• Établir un mécanisme de publication en un clic et en libre-service pour tout code pouvant être déployé en production ;
• Enregistrez automatiquement le contenu pertinent requis pour l'audit et la gestion de la conformité, y compris sur quelle machine la commande a été exécutée, quelle commande a été exécutée, qui l'a autorisée et quel a été le résultat ;
• Vérifiez que le système fonctionne correctement grâce à des tests de fumée et que la chaîne de connexion à la base de données et les autres configurations sont correctes ;
• Fournir un feedback rapide aux développeurs afin qu'ils puissent comprendre les résultats du déploiement le plus rapidement possible (par exemple si le déploiement a réussi, si l'application peut s'exécuter normalement dans l'environnement de production, etc.)

Notre objectif est de déployer rapidement : pas d'heures d'attente pour savoir si le déploiement a réussi ou de passer des heures à corriger le code. Grâce aux technologies de conteneurs telles que Docker, des déploiements d'applications très complexes peuvent être réalisés en quelques secondes ou minutes.

En créant les fonctionnalités ci-dessus, un déploiement de code en un clic peut être réalisé et les modifications du code et de l'environnement peuvent être publiées rapidement et en toute sécurité dans l'environnement de production via le pipeline de déploiement.

12.2 Découpler le déploiement et la version

Dans la pratique, les gens utilisent souvent les mots « déployer » et « libérer » de manière interchangeable. Cependant, il s’agit en réalité d’actions différentes et d’objectifs très différents.

• Le déploiement fait référence à l'installation d'une version spécifiée d'un logiciel dans un environnement spécifique (par exemple, le déploiement de code dans un environnement de test d'intégration ou un environnement de production). Plus précisément, un déploiement peut être lié ou non à la sortie d'une fonctionnalité.
• La publication fait référence à la mise à disposition d'une fonctionnalité (ou d'un ensemble de fonctionnalités) à tous les clients ou à un sous-ensemble de clients (par exemple, l'ouverture d'une fonctionnalité à 5 % de la clientèle). Le code et l'architecture de l'environnement doivent être tels que les versions de fonctionnalités ne nécessitent pas de modifications du code de l'application.

Autrement dit, si l’on confond déploiement et release, il devient difficile de définir qui est responsable des résultats. Le découplage de ces deux activités augmente la capacité des développeurs et du personnel d'exploitation à déployer rapidement et fréquemment, tout en tenant le propriétaire du produit responsable du succès des versions (c'est-à-dire en s'assurant que le temps passé à créer et à publier des fonctionnalités est précieux).

Si le cycle de déploiement est trop long, cela limite la capacité de publier fréquemment de nouvelles fonctionnalités sur le marché. Cependant, s’il peut être déployé à la demande, le moment où proposer de nouvelles fonctionnalités aux clients devient une décision commerciale et commerciale, et non une décision technique. Il existe deux modes de publication couramment utilisés :

• Modèle de version basé sur l'environnement : déployez le système dans deux environnements ou plus, mais un seul environnement gère réellement le trafic client (par exemple, en configurant un équilibreur de charge pour commuter le trafic). Déployez le nouveau code dans un environnement hors production, puis basculez le trafic de production vers cet environnement. Ce modèle est très puissant car il nécessite généralement peu ou pas de modifications dans l'application. Ce modèle comprend le déploiement bleu-vert, la libération des canaris et le système immunitaire en essaim . Nous discuterons de ces modèles plus tard.
• Modèle de version basé sur l'application : modifiez l'application pour publier ou ouvrir de manière sélective les fonctionnalités de l'application via des modifications de configuration mineures. Par exemple, vous pouvez ouvrir progressivement de nouvelles fonctionnalités via des changements de fonctionnalités - d'abord à l'équipe de développement, puis à tous les employés internes, puis à 1 % des clients ; ou après avoir confirmé que les fonctionnalités sont entièrement conformes à la conception, les publier directement à tous. clients. Il s'agit de la technologie dite du démarrage noir : déployez toutes les fonctionnalités dans l'environnement de production et testez-les avec le trafic de l'environnement de production avant de les publier. Par exemple, dans les semaines précédant la sortie, testez les nouvelles fonctionnalités avec le trafic de production afin que tout problème soit découvert et résolu avant la sortie officielle.

12.2.1 Modèle de version basé sur l'environnement

Le découplage du déploiement et de la publication changera radicalement notre façon de travailler. Nous n'avons plus besoin de déployer au milieu de la nuit ou le week-end pour réduire un éventuel impact négatif sur les clients. Au lieu de cela, nous pouvons déployer pendant les heures normales de bureau. Le personnel d’exploitation et de maintenance peut enfin quitter son travail normalement comme tout le monde.

Modèle de version basé sur l'environnement, qui ne nécessite aucune modification du code de l'application. Nous utilisons plusieurs environnements pour le déploiement, mais un seul environnement gère réellement le trafic client. Cette approche peut réduire considérablement le risque de versions de production et raccourcir le temps de déploiement.

1. Mode de déploiement bleu-vert
   Le déploiement bleu-vert est le plus simple des 3 modes. Dans ce mode, nous avons deux environnements de production : l'environnement bleu et l'environnement vert. À tout moment, un seul de ces environnements gère le trafic client. Dans la figure 12-5, c'est l'environnement vert qui gère le trafic client.
   
   Lorsque vous publiez une nouvelle version d'un service, déployez-la d'abord dans un environnement hors ligne afin que les tests puissent être effectués sans affecter l'expérience utilisateur. Après vous être assuré que tout est normal, basculez le trafic client vers l'environnement bleu et utilisez cette méthode pour livrer la nouvelle version. Après cela, l’environnement bleu devient l’environnement de production et l’environnement vert devient l’environnement de pré-production. Le retour en arrière peut également être obtenu en redirigeant le trafic client vers l’environnement vert.

   Le modèle de déploiement bleu-vert est relativement simple et très facile à mettre en œuvre dans les systèmes existants. Il présente de nombreux avantages, tels que permettre aux équipes d'effectuer des déploiements pendant les heures normales de bureau et de mettre en œuvre facilement des changements de version (comme la modification des configurations de routage ou des liens symboliques) pendant les heures creuses. À eux seuls, ces éléments peuvent apporter une amélioration considérable à la situation de travail de l’équipe de déploiement.

2. Gestion des modifications de la base de données
   Des problèmes peuvent survenir lorsque deux versions d'une application s'appuient sur la même base de données. Si l'opération de déploiement nécessite de modifier le schéma de la base de données, ou d'ajouter, de modifier ou de supprimer des tables ou des colonnes, la base de données ne pourra pas prendre en charge les deux versions de l'application en même temps. Généralement, ce problème est résolu par les deux méthodes suivantes.

   • Créez deux bases de données (c'est-à-dire une base de données bleue et une base de données verte) : chaque version de l'application - bleue (ancienne version) et verte (nouvelle version) - possède sa propre base de données. Lors de la publication, définissez la base de données bleue en mode lecture seule, puis effectuez une sauvegarde, restaurez vers la base de données verte et enfin basculez le trafic vers l'environnement vert. Le problème avec ce modèle est que si vous devez revenir à la version bleue, vous devez d'abord migrer manuellement les données de transaction de la base de données verte vers la base de données bleue, sinon les données risquent d'être perdues.
   • Découpler les modifications de la base de données des modifications de l'application : Contrairement à une base de données qui prend en charge deux versions, la publication des modifications de la base de données et la publication des modifications de l'application sont découplées en effectuant les deux opérations suivantes : Premièrement, seules les modifications incrémentielles sont apportées à la base de données, ne modifiez pas les objets de base de données existants ; deuxièmement, la logique de l'application ne fait aucune hypothèse sur la version de la base de données dans l'environnement de production. Ceci est très différent de la façon dont nous envisageons toujours les bases de données, et cela évite la génération de données en double.

3. Mode de libération Canary et mode de libération du système immunitaire en cluster.Le
   mode de déploiement bleu-vert est relativement simple à mettre en œuvre et peut améliorer considérablement la sécurité de la version logicielle. Il existe des variantes qui peuvent encore améliorer la sécurité et réduire le temps de déploiement grâce à l'automatisation, mais qui peuvent en même temps introduire de la complexité.

   Le terme « lâcher de canaris » vient de la tradition selon laquelle les mineurs de charbon amenaient des canaris en cage dans les mines. Les mineurs utilisent des canaris pour connaître les concentrations de monoxyde de carbone dans les mines. Si la concentration de monoxyde de carbone devient trop élevée, le canari s'empoisonne, faisant savoir aux mineurs qu'ils doivent évacuer immédiatement.

   Dans un modèle de version Canary , nous surveillons le fonctionnement du logiciel dans chaque environnement. Si quelque chose ne va pas, revenez en arrière ; sinon, déployez vers l’environnement suivant.
   

   • Groupe A1 : Serveurs de production au service des employés internes uniquement.
   • Groupe A2 : serveurs de production qui ne servent qu'un petit ensemble de clients et sont déployés (soit automatiquement, soit manuellement) une fois que le logiciel répond à certains critères d'acceptation.
   • Groupe A3 : Les serveurs d'environnement de production restants, le logiciel sera déployé après avoir atteint certains critères d'acceptation dans le groupe A2.

   Le modèle de version Cluster Immune System étend le modèle de version Canary en reliant le système de surveillance de l'environnement de production au processus de publication (20%), annule automatiquement le code. Cette protection présente deux avantages évidents : premièrement, elle évite les défauts difficiles à détecter via des tests automatisés, tels que les modifications de page qui rendent certains éléments clés de la page invisibles (comme les modifications du code CSS) ; deuxièmement, elle réduit le temps de dépannage et de résolution. changements Temps requis pour provoquer des problèmes de dégradation des performances.

12.2.2 Le modèle de publication basé sur les applications est plus sécurisé

La section précédente a présenté le modèle de publication basé sur l'environnement. Il présente le découplage du déploiement et de la version en utilisant plusieurs environnements et en basculant le trafic entre eux. Ceci est tout à fait possible au niveau des infrastructures

Cette section présentera le modèle de publication basé sur les applications, qui utilise du code pour proposer de nouvelles fonctionnalités aux clients de manière plus flexible et sécurisée (les fonctionnalités sont généralement publiées une par une). Le modèle de publication basé sur l'application étant implémenté dans le code de l'application, il nécessite la participation de l'équipe de développement.

1. Implémentation des commutateurs de fonctionnalités
   Le modèle de publication basé sur les applications est principalement implémenté via des commutateurs de fonctionnalités. Le mécanisme de changement de fonctionnalités nous permet d'activer et de désactiver de manière sélective des fonctionnalités sans déployer de code de production. Les commutateurs de fonctionnalités vous permettent d'ouvrir les fonctionnalités de votre application à certains utilisateurs, tels que les employés internes et certains groupes de clients.

   Le mécanisme d'implémentation des commutateurs de fonctionnalités consiste généralement à utiliser des instructions conditionnelles pour encapsuler la logique de l'application ou les éléments de l'interface utilisateur, et à activer ou désactiver une fonctionnalité en fonction des informations de configuration enregistrées quelque part. Les informations de configuration peuvent être stockées à l'aide de simples fichiers de configuration d'application (tels que des fichiers de configuration au format JSON ou XML), ou elles peuvent être configurées via un catalogue de services, ou même un service Web spécialement conçu pour gérer les commutateurs de fonctionnalités.

   Les commutateurs caractéristiques présentent également les avantages suivants :

   • Restaurer facilement
   • Soulager la pression sur les performances
   • Améliorer la résilience avec une architecture orientée services
   • Les commutateurs de fonctionnalités dissocient le déploiement de code des versions de fonctionnalités

2. Implémentation d'un démarrage noir
   L'effet du changement de fonctionnalité est de déployer la fonctionnalité dans l'environnement de production mais de la rendre temporairement indisponible. Il permet des techniques de démarrage noir : déployer toutes les fonctionnalités en production, puis effectuer des tests sur les fonctionnalités qui ne sont pas visibles pour les clients. Pour les modifications à grande échelle ou à haut risque, le processus de blackboot dure souvent plusieurs semaines, ce qui permet de tester en toute sécurité avec des charges de travail de type production avant la sortie officielle.

   Disons que nous utilisons des techniques de blackboot pour publier une nouvelle fonctionnalité potentiellement risquée, telle qu'une nouvelle fonctionnalité de recherche, un processus de création de compte ou une requête de base de données. Une fois que tout le code est déployé en production, désactivez la nouvelle fonctionnalité, puis appelez la nouvelle fonction en modifiant le code de session utilisateur sans afficher les résultats de l'appel à l'utilisateur et en enregistrant ou en supprimant uniquement les résultats des tests.

   De cette façon, nous n'avons plus besoin d'attendre un lancement à grande échelle pour vérifier la satisfaction des clients à l'égard du produit. Au lieu de cela, au moment où nous annonçons un lancement majeur, nous avons terminé la validation de nos hypothèses commerciales et mené d'innombrables expériences de perfectionnement avec de vrais clients qui ont contribué à améliorer l'adéquation entre le produit et les besoins des clients.

12.3 Enquête sur les pratiques de livraison continue et de déploiement continu

Les nouvelles définitions de la livraison continue et du déploiement continu sont les suivantes

• La livraison continue signifie que tous les développeurs travaillent sur le tronc par petits lots, ou sur des branches de fonctionnalités de courte durée, et fusionnent régulièrement dans le tronc, tout en gardant toujours le tronc libérable et capable d'effectuer des tâches normales sur le tronc. demande pendant les heures de travail. Les développeurs reçoivent des commentaires rapides lorsqu'ils introduisent des erreurs de régression, notamment des bogues, des problèmes de performances, des problèmes de sécurité, des problèmes d'utilisabilité, etc. Des problèmes comme ceux-ci sont résolus dès qu’ils sont découverts, gardant ainsi le backbone prêt pour le déploiement. La livraison continue peut publier automatiquement le code vérifié dans le propre référentiel de l'entreprise.
• Le déploiement continu signifie que, sur la base d'une livraison continue, les développeurs ou le personnel d'exploitation et de maintenance déploient régulièrement des builds de haute qualité dans l'environnement de production en libre-service. Cela signifie généralement que tout le monde déploie dans l'environnement de production au moins une fois par jour. ou même à chaque fois qu'un développeur Lorsqu'une personne soumet une modification de code, un déploiement automatisé est déclenché.

La livraison continue est une condition préalable au déploiement continu, tout comme l'intégration continue est une condition préalable à la livraison continue. Le déploiement continu est plus adapté à la fourniture de services Web en ligne, tandis que la livraison continue convient à presque tous les scénarios de déploiement et de publication à faible risque qui nécessitent qualité, rapidité de livraison et prévisibilité des résultats, y compris les systèmes embarqués, les produits commerciaux disponibles dans le commerce, et application mobile.

12.4 Résumé

La sortie et le déploiement ne doivent pas nécessairement être des tâches à haut risque et dans des situations élevées, et ils ne nécessitent pas non plus des dizaines, voire des centaines d'ingénieurs travaillant des heures supplémentaires pour les réaliser. Au lieu de cela, ils peuvent faire partie de votre routine quotidienne. L'intégration de la version et du déploiement dans le travail quotidien peut réduire le temps de déploiement de plusieurs mois à quelques minutes, permettant ainsi aux organisations d'apporter rapidement de la valeur aux clients tout en évitant les incidents inattendus et les interruptions de service. De plus, la coopération étroite entre les développeurs et le personnel d'exploitation et de maintenance peut rendre le travail d'exploitation et de maintenance plus humain.

13. Architecture pour réduire le risque de publication

Ce chapitre présente des mesures qui peuvent inverser le cercle vicieux décrit ci-dessus, passe en revue certains archétypes architecturaux majeurs, explore les fonctionnalités architecturales qui peuvent aider à améliorer la productivité du développement, la testabilité, la déployabilité et la sécurité, ainsi que les stratégies de migration d'architecture associées pour migrer en toute sécurité tout existant. une architecture qui répond mieux aux objectifs organisationnels

13.1 Architecture qui améliore la productivité, la testabilité et la sécurité

Les architectures étroitement couplées réduisent non seulement la productivité, mais ont également un impact sur la capacité à apporter des modifications en toute sécurité. En revanche, une architecture faiblement couplée avec des interfaces clairement définies optimise les dépendances entre les modules, améliore la productivité et la sécurité, et permet aux petites équipes productives de « double pizza » d'effectuer de petits changements en toute sécurité et de manière indépendante. Étant donné que chaque service dispose d'une API bien définie, il est plus facile à tester et les conditions des accords de niveau de service entre les équipes sont plus faciles à déterminer.

Google Cloud Datastor est le plus grand service NoSQL au monde, mais son équipe d'assistance ne compte qu'environ 8 personnes, principalement parce qu'il repose sur des couches de services de base fiables. L'architecture orientée services permet aux petites équipes de travailler sur des tâches de développement plus petites et plus simples, et chaque équipe peut se déployer de manière indépendante, rapide et sécurisée.

13.2 Prototype d'architecture : architecture monolithique et microservices

L’architecture monolithique n’est pas mauvaise en soi. En fait, dans les premières étapes du cycle de vie du produit, l’architecture monolithique constitue souvent le meilleur choix.

Une architecture monolithique adaptée à une startup (par exemple, lorsqu'une nouvelle fonctionnalité doit être rapidement prototypée ou que les objectifs stratégiques de l'entreprise peuvent changer de manière significative) est complètement différente de l'architecture utilisée par une entreprise avec des centaines d'équipes de développement, dont chacune Teams doit être capable de fournir de manière indépendante de la valeur aux clients. En adoptant une architecture évolutive qui s'adapte à son temps, vous pouvez vous assurer que les besoins actuels de votre organisation sont satisfaits.

13.3 Faire évoluer l'architecture d'entreprise en toute sécurité

Si vous pensez que l’architecture existante est trop étroitement couplée, vous pouvez en toute sécurité découpler certaines fonctionnalités par-dessus. De cette manière, les équipes de développement responsables de ces fonctionnalités peuvent développer, tester et déployer de manière indépendante et sécurisée, tout en réduisant l'entropie architecturale.

Comme mentionné précédemment, le modèle d'application Strangler implique d'encapsuler les fonctions existantes avec des API et d'implémenter de nouvelles fonctions selon la nouvelle architecture, en appelant l'ancien système uniquement lorsque cela est nécessaire. Dans le modèle d'application Strangler, tous les services sont accessibles via des API versionnées, également appelées services versionnés ou services immuables.

Les API versionnées permettent de modifier les services sans affecter les appelants, ce qui réduit le couplage du système. Si les paramètres doivent être modifiés, créez une nouvelle version de l'API et migrez les équipes qui dépendent du service vers la nouvelle version. Si nous permettons à de nouvelles applications d'être étroitement couplées à n'importe quel autre service (par exemple en se connectant directement à la base de données d'un autre service), nous ne parviendrons pas à atteindre l'objectif de réarchitecture

En dissociant continuellement les fonctionnalités du système étroitement couplé existant, le travail est progressivement déplacé vers un écosystème sécurisé et dynamique, ce qui augmente considérablement la productivité des développeurs tandis que les fonctionnalités des applications existantes diminuent progressivement. Lorsque toutes les fonctions métier seront migrées vers la nouvelle architecture, les anciennes applications pourraient même disparaître complètement.

Strangler applique ce terme. Cela a été inspiré par les plantes étrangleurs de rotin indigènes avec lesquelles il voyageait en Australie. Il écrit : « Leurs graines tombent sur la cime du figuier, puis les vignes poussent progressivement le long du tronc et finissent par s'enraciner dans le sol. Au fil des années, les vignes forment des formes merveilleuses et belles, mais en même temps elles s'étranglent. leurs arbres hôtes."

En créant une application Strangler, vous évitez de dupliquer des fonctionnalités existantes avec une nouvelle architecture ou une nouvelle technologie. Les caractéristiques du système existant rendent le processus métier trop complexe, il n'est donc pas conseillé de copier le processus existant (en étudiant les utilisateurs, il est souvent possible de repenser le processus métier et d'utiliser des processus plus simples pour atteindre les objectifs commerciaux).

Comme pour toute transformation, nous devons nous efforcer d’obtenir des résultats rapides et continuer à créer de la valeur par itérations. L'analyse préliminaire permet d'identifier les plus petites avancées afin que la nouvelle architecture puisse nous aider efficacement à atteindre nos objectifs commerciaux.

13.4 Résumé

Dans une large mesure, l'architecture sur laquelle repose un service détermine la manière dont le code est testé et déployé. Cela a été vérifié dans le rapport 2015 sur l'état du DevOps de Puppet Labs. Le rapport montre que l'architecture est le principal facteur affectant la productivité des ingénieurs et détermine si les changements peuvent être mis en œuvre rapidement et en toute sécurité.

Parce que nous sommes souvent contraints par des objectifs organisationnels poursuivant des orientations divergentes et des architectures héritées de longue date, l’évolution architecturale doit être menée en toute sécurité. Les cas présentés dans ce chapitre décrivent des technologies telles que le modèle d'application Strangler, qui peuvent nous aider à promouvoir progressivement une transformation architecturale pour suivre l'évolution des besoins organisationnels.