Pratiques de déploiement sécurisées

Parfois, une version ne correspond pas aux attentes. Malgré l’utilisation des meilleures pratiques et la transmission de toutes les portes de qualité, il existe parfois des problèmes qui entraînent un déploiement de production provoquant des problèmes imprévus pour les utilisateurs. Pour réduire et atténuer l’impact de ces problèmes, les équipes DevOps sont encouragées à adopter une stratégie d’exposition progressive qui équilibre l’exposition d’une version donnée avec ses performances éprouvées. Comme une version se prouve en production, elle devient disponible pour des niveaux d’audience plus larges jusqu’à ce que tout le monde l’utilise. Teams peut utiliser des pratiques de déploiement sécurisées afin d’optimiser la qualité et la vitesse des versions en production.

Contrôler l’exposition aux clients

Les équipes DevOps peuvent utiliser différentes pratiques pour contrôler l’exposition des mises à jour aux clients. Historiquement, les tests A/B ont été un choix populaire pour les équipes qui cherchent à voir comment différentes versions d’un service ou d’une interface utilisateur s’exécutent par rapport aux objectifs cibles. Les tests A/B sont également relativement faciles à utiliser, car les modifications sont généralement mineures et comparent souvent uniquement les différentes versions au bord du client d’un service.

Déploiement sécurisé via des niveaux

À mesure que les plateformes augmentent, l’échelle de l’infrastructure et les besoins de l’audience ont tendance à croître également. Cela crée une demande pour un modèle de déploiement qui équilibre les risques associés à un nouveau déploiement avec les avantages des mises à jour qu’il promet. L’idée générale est qu’une version donnée ne doit être exposée qu’à un petit groupe d’utilisateurs avec la tolérance la plus élevée pour le risque. Ensuite, si la version fonctionne comme prévu, elle peut être exposée à un groupe plus large d’utilisateurs. S’il n’y a aucun problème, le processus peut continuer par des groupes plus larges d’utilisateurs ou de niveaux jusqu’à ce que tout le monde utilise la nouvelle version. Avec des plateformes de livraison continue modernes telles que GitHub Actions et Azure Pipelines, la création d’un processus de déploiement avec des niveaux est accessible aux équipes DevOps de toute taille.

Indicateurs de fonctionnalités

Certaines fonctionnalités doivent parfois être déployées dans le cadre d’une version, mais pas initialement exposées aux utilisateurs. Dans ce cas, les indicateurs de fonctionnalité fournissent une solution dans laquelle les fonctionnalités peuvent être activées via des modifications de configuration basées sur l’environnement, le niveau ou tout autre déploiement spécifique.

Adhésion de l’utilisateur

Comme pour les indicateurs de fonctionnalité, l’opt-in utilisateur permet de limiter l’exposition. Dans ce modèle, une fonctionnalité donnée est activée dans la version, mais elle n’est pas activée pour un utilisateur, sauf si elle le souhaite spécifiquement. La décision de tolérance aux risques est déchargée aux utilisateurs afin qu’ils puissent décider de la rapidité avec laquelle ils veulent adopter certaines mises à jour.

Plusieurs pratiques sont couramment employées simultanément. Par exemple, une équipe peut avoir une fonctionnalité expérimentale destinée à un cas d’usage très spécifique. Étant donné qu’il est risqué, ils le déploieront sur le premier niveau pour que les utilisateurs internes puissent essayer. Toutefois, même si les fonctionnalités se trouvent dans le code, une personne doit définir l’indicateur de fonctionnalité pour un déploiement spécifique au sein du niveau afin que la fonctionnalité soit exposée via l’interface utilisateur. Même ensuite, l’indicateur de fonctionnalité peut uniquement exposer l’option permettant à un utilisateur de choisir d’utiliser la nouvelle fonctionnalité. Toute personne qui n’est pas dans le niveau, sur ce déploiement ou qui n’a pas choisi d’entrée ne sera pas exposée à la fonctionnalité. Bien qu’il s’agisse d’un exemple assezcontratif, il sert à illustrer la flexibilité et la pratique de l’exposition progressive.

Les équipes de problèmes courants font face dès le début

À mesure que les équipes se déplacent vers une pratique DevOps plus Agile, elles peuvent rencontrer des problèmes cohérents avec d’autres personnes qui ont migré hors des livraisons monolithiques traditionnelles. Les équipes utilisées pour déployer une fois toutes les quelques mois ont un état d’esprit qui met en mémoire tampon pour la stabilisation. Ils s’attendent à ce que chaque déploiement introduise un changement important dans son service et qu’il y aura des problèmes imprévus.

Les charges utiles sont trop volumineuses

Les services déployés tous les quelques mois sont généralement remplis de nombreuses modifications. Cela augmente la probabilité qu’il y ait des problèmes immédiats et rend également difficile la résolution de ces problèmes, car il y a tellement de nouvelles choses. En passant à des livraisons plus fréquentes, les différences entre ce qui est déployé deviennent plus petites, ce qui permet un test plus ciblé et un débogage plus facile.

Aucune isolation de service

Les systèmes monolithiques sont traditionnellement mis à l’échelle en effectuant un nivellement du matériel sur lequel ils sont déployés. Toutefois, lorsqu’un problème se produit avec l’instance, cela entraîne des problèmes pour tout le monde. Une solution simple consiste à ajouter plusieurs instances afin que vous puissiez équilibrer la charge des utilisateurs. Toutefois, cela peut nécessiter des considérations architecturales importantes, car de nombreux systèmes hérités ne sont pas générés pour être multi-instances. De plus, il peut être nécessaire d’allouer des ressources en double importantes pour les fonctionnalités qui peuvent être mieux consolidées ailleurs.

À mesure que de nouvelles fonctionnalités sont ajoutées, découvrez si une architecture de microservices peut vous aider à exploiter et à mettre à l’échelle grâce à une meilleure isolation des services.

Les étapes manuelles entraînent des erreurs

Lorsqu’une équipe ne déploie que quelques fois par an, l’automatisation des livraisons peut ne pas avoir la valeur de l’investissement. Par conséquent, de nombreux processus de déploiement sont gérés manuellement. Cela nécessite un temps et un effort considérables, et est susceptible d’une erreur humaine. Il suffit d’automatiser les tâches de génération et de déploiement les plus courantes pour réduire les erreurs perdues et non appliquées.

Teams peut également utiliser l’infrastructure en tant que code pour mieux contrôler les environnements de déploiement. Cela supprime la nécessité de demander à l’équipe des opérations d’apporter des modifications manuelles à mesure que de nouvelles fonctionnalités ou dépendances sont introduites dans différents environnements de déploiement.

Seules les opérations peuvent effectuer des déploiements

Certaines organisations ont des stratégies qui nécessitent que tous les déploiements soient lancés et gérés par le personnel des opérations. Bien qu’il y ait eu de bonnes raisons pour cela dans le passé, un processus Agile DevOps bénéficie considérablement lorsque l’équipe de développement peut lancer et contrôler les déploiements. Les plateformes de livraison continue modernes offrent un contrôle précis sur les utilisateurs qui peuvent lancer les déploiements et qui peuvent accéder aux journaux d’état et à d’autres informations de diagnostic, en s’assurant que les bonnes personnes disposent des informations appropriées le plus rapidement possible.

Les déploiements incorrects continuent et ne peuvent pas être restaurés

Parfois, un déploiement est incorrect et les équipes doivent y remédier. Toutefois, lorsque les processus sont manuels et que l’accès aux informations est lent et limité, il peut être difficile de revenir à un déploiement de travail précédent. Heureusement, il existe différents outils et pratiques pour atténuer le risque d’échec des déploiements.

Principes fondamentaux

Les équipes qui cherchent à adopter des pratiques de déploiement sécurisées doivent définir certains principes fondamentaux pour soutenir l’effort.

Être cohérent

Les mêmes outils utilisés pour le déploiement en production doivent être utilisés dans les environnements de développement et de test. S’il existe des problèmes, tels que ceux qui proviennent souvent de nouvelles versions de dépendances ou d’outils, ils doivent être interceptés bien avant la publication du code en production.

S’occuper des signaux de qualité

Trop d’équipes tombent dans le piège commun de ne pas vraiment s’occuper des signaux de qualité. Au fil du temps, ils peuvent constater qu’ils écrivent des tests ou prennent des tâches de qualité simplement pour changer un avertissement jaune à une approbation verte. Les signaux de qualité sont vraiment importants car ils représentent l’impulsion d’un projet. Les signaux de qualité utilisés pour approuver les déploiements doivent être suivis constamment tous les jours.

Les déploiements doivent nécessiter aucun temps d’arrêt

Même s’il n’est pas essentiel que chaque service soit toujours disponible, les équipes doivent aborder leurs phases de livraison et d’opération DevOps avec l’état d’esprit qu’elles peuvent et doivent déployer de nouvelles versions sans avoir à les retirer à tout moment. Les outils d’infrastructure et de pipeline modernes sont suffisamment avancés maintenant, où il est possible pour pratiquement toute équipe de cibler 100% temps d’activité.

Les déploiements doivent se produire pendant les heures de travail

Si une équipe travaille avec l’état d’esprit que les déploiements nécessitent aucun temps d’arrêt, cela n’a pas vraiment d’importance lorsqu’un déploiement est poussé. En outre, il devient avantageux de pousser les déploiements pendant les heures de travail, en particulier au début de la journée et au début de la semaine. Si quelque chose ne va pas, il doit être suivi suffisamment tôt pour contrôler le rayon d’explosion. De plus, tout le monde travaillera déjà et se concentrera sur l’obtention des problèmes résolus.

Déploiement basé sur des niveaux

Les équipes avec des pratiques de publication DevOps matures sont en mesure de prendre en charge le déploiement basé sur les niveaux. Dans ce modèle, de nouvelles fonctionnalités sont d’abord déployées auprès des clients prêts à accepter le plus de risques. À mesure que le déploiement est prouvé, l’audience s’étend pour inclure davantage d’utilisateurs jusqu’à ce que tout le monde l’utilise.

Exemple de modèle de niveau

Un modèle de déploiement de niveau classique est conçu pour trouver des problèmes dès que possible grâce à la segmentation minutieuse des utilisateurs et de l’infrastructure. L’exemple suivant montre comment les niveaux sont utilisés par une équipe principale chez Microsoft.

Autoriser le temps de cuisson

Le terme bake time fait référence à la durée pendant laquelle un déploiement est autorisé à s’exécuter avant de passer au niveau suivant. Certains problèmes peuvent prendre des heures ou plus longtemps pour commencer à présenter des symptômes, de sorte que la mise en production doit être utilisée pour une durée appropriée avant qu’elle soit considérée comme prête.

En général, un jour de 24 heures doit être suffisant pour que la plupart des scénarios exposent des bogues latents. Toutefois, cette période doit inclure une période de pointe d’utilisation, nécessitant une journée d’affaires complète, pour les services qui pointent pendant les heures de bureau.

Accélérer les correctifs logiciels

Un incident de site en direct (LSI) se produit lorsqu’un bogue a un impact sérieux en production. Les LSIs nécessitent la création d’un correctif logiciel, qui est une mise à jour hors bande conçue pour résoudre un problème à priorité élevée.

Si un bogue est Sev 0, le type de bogue le plus grave, le correctif logiciel peut être déployé directement sur l’unité d’échelle affectée aussi rapidement que possible. Même s’il est essentiel que le correctif ne rende pas les choses pires, les bogues de cette gravité sont considérés comme tellement perturbants qu’ils doivent être résolus immédiatement.

Les bogues évalués sev 1 doivent être déployés via le niveau 0, mais peuvent ensuite être déployés sur les unités d’échelle affectées dès qu’ils sont approuvés.

Les correctifs logiciels pour les bogues avec une gravité inférieure doivent être déployés via tous les niveaux comme prévu.

Points clés à prendre

Chaque équipe souhaite fournir des mises à jour rapidement et à la plus haute qualité possible. Avec les bonnes pratiques, la livraison peut être une partie productive et indolore du cycle DevOps.

• Déployez souvent.
• Restez vert tout au long du sprint.
• Utilisez des outils de déploiement cohérents dans le développement, le test et la production.
• Utilisez une plateforme de livraison continue qui autorise l’automatisation et l’autorisation.
• Suivez les pratiques de déploiement sécurisées.

Étapes suivantes

Découvrez comment les indicateurs de fonctionnalité permettent de contrôler l’exposition des nouvelles fonctionnalités aux utilisateurs.