Automic, désormais acquis par CA Technologies En savoir plus >
 

L’art du retour-arrière : définition et fonctionnement du retour-arrière

Episode un : le retour-arrière est-il vraiment possible ? Montrez-moi !

French - Pierre-Boris Bonafous
Pierre-Boris Bonafous, April 13, 2017 11:45 am
Blog > Continuous Delivery | DevOps > L’art du retour-arrière : définition et fonctionnement du retour-arrière

L’objectif de cette série de blogs est de vous aider à définir vos processus de retour-arrière sur vos déploiements applicatifs. Nous examinerons le statut du retour-arrière à l’heure actuelle et nous décrirons les différentes stratégies à adopter, leurs avantages et leurs inconvénients, en fonction de vos composants, applications, déploiements et dépendances.

Je ne vous ferai pas patienter jusqu’au dernier épisode pour révéler la conclusion : oui, il est possible de concevoir un bon processus de retour-arrière. Mais il vous faudra peut-être procéder à quelques changements d’envergure dans votre architecture actuelle pour atteindre cet objectif.

Lorsque la fonctionnalité de retour-arrière est abordée chez un client, lors d’une démonstration produit d’Automic Release Automation, nous observons deux types de réaction :

La première : « Le retour-arrière est automatisé – Cela veut bien dire que l’utilisateur n’a rien à définir ? »

La deuxième va bien au-delà : « Bien sûr que le retour-arrière est automatisé. Mais comment ça marche ? Par magie ? »

Fonctionnement

Au risque de vous surprendre, les outils de Release Automation ne sont pas aussi magiques que vous le pensez. Un retour-arrière n’a rien à voir avec l’intelligence artificielle ou le super naturel : vous devez le définir.

Ce que l’outil de Release Automation peut faire, c’est de décider quelle étape ou quel traitement doit être exécuté en cas d’erreur, en fonction d’un test ou du dernier code d’erreur généré.  Toutefois, les étapes ou les traitements eux-mêmes doivent être définis, comme ils le sont dans tout autre processus de déploiement.  

Cependant, un traitement de retour-arrière doit supporter un certain nombre de comportements spécifiques, différents de ceux d’un simple processus de déploiement. Par exemple, l’utilisateur doit préserver l’inventaire et envoyer un signal d’erreur au traitement père. La mauvaise nouvelle, c’est que les retour-arrières auto-générés ne sont pas encore possibles, et lorsqu’ils le sont, il y a des chances qu’ils soient très limités, et ne correspondent sans doute pas à des besoins individuels et personnalisés.

En introduction, j’aborderai dans ce premier blog les deux stratégies principales : 

  • Retour-arrière – c.à.d. retour arrière dans le temps

  • Retour-avant – comment résoudre ou contourner les problèmes

Le second peut vous paraitre invraisemblable, car en théorie, seul le retour-arrière permet de revenir à l’état initial, n’est-ce pas ? Mais voici comment cela fonctionne : 

  • Pouvez-vous vous permettre de perdre des données ?

  • L’état antérieur était-il vraiment idéal ?

Avantages et inconvénients du retour-arrière

Le retour-arrière, par définition, implique de revenir à l’état initial. Les déploiements de restauration et Blue-Green tombent tous les deux dans cette catégorie. Si cela peut vous paraître simple lorsqu’il s’agit d’un seul composant, imaginez le casse-tête que cela représente pour un système complexe. Un retour-arrière réussi doit l’être pour tous les composants de votre déploiement, sans quoi le résultat sera incohérent et peut-être pire qu’un déploiement en échec.

Réussir un déploiement ou un retour-arrière applicatif n’est pas simple, et l y a deux raisons essentielles à cela :

  • Un instantané de tous les composants doit être réalisé simultanément, pour disposer d’une seule sauvegarde à l’instant T (prenez, par exemple, les photos de mariage : tout le monde doit regarder l’objectif, arrêter de bouger et sourire au même moment. Les gens mariés me comprendront !)

  • L’opération de retour-arrière doit être rapide.

Bien entendu, le risque d’échec du retour-arrière est équivalent à celui d’un déploiement, c’est à dire à la multiplication du risque d’échec de chaque composant. Il est plus sécurisé de déployer souvent en petits volumes que de déployer à grande échelle une fois par an.

Les avantages du retour-arrière sont :

  • Retour à un état connu

  • Ne pas être sanctionné en cas d’erreur !

Cependant, il existe tout de même quelques inconvénients :

  • Perte de données : la sévérité (de la perte de données) doit être équilibrée par le délai d’exécution de l’installation corrompue. Lorsque l’échec est immédiat et évident (par exemple lorsqu’un traitement ne démarre pas), ce n’est pas un problème en soi, car il n’y a pas d’autre choix que de restaurer le système. Mais lorsque le problème n’est pas détecté immédiatement, ou, dans le cas de systèmes Haute Disponibilité, c’est plus compliqué. En fonction de votre activité, vous devez décider d’un délai d’exécution minimum pour lequel un retour arrière mérite d’être envisagé. Passé ce délai, le retour-avant devrait s’appliquer.

  • Echec du retour-arrière : en cas d’échec, vous perdez l’intégralité des données. Tout ce qu’il vous reste, c’est une vieille plateforme qui ne fonctionne plus. Vous êtes dans l’obscurité totale mais vous devez continuer à avancer. Vous n’avez plus qu’à espérer qu’il y ait un génie à proximité, pour vous tirer d’affaire.

Retour-avant

Le retour-avant consiste à essayer d’agir sur les nouveaux déploiements pour les faire fonctionner. Les déploiements de Hotfix, Canary Release et les changements de conditions tombent dans cette catégorie.

D’une part, le retour-avant n’est pas toujours possible lorsqu’un incident majeur se produit. Par exemple, lorsqu’il n’y a aucun moyen d’identifier pourquoi un système ne démarre pas. Mais ne pas choisir d’aller de l’avant revient à céder à la pression. C’est le même état d’esprit que : « je ne sais pas combien de temps cela prendra pour résoudre le problème, mais je sais que mon système sera à nouveau en ligne d’ici une demi-heure si je décide de faire un retour-arrière maintenant.

D’autre part, le retour-avant est la seule option viable lorsqu’un problème est détecté après l’approbation du déploiement, c’est à dire passé le délai minimum acceptable pour envisager un retour-arrière. Cela concerne souvent des fonctionnalités critiques qui ne marchent pas, ou des données corrompues.

Conclusion

Vous pouvez envisager une stratégie de retour-arrière si vous estimez que la perte de données est acceptable. Mais vous ne pouvez pas envisager une stratégie de retour-avant sans un retour-arrière. Vos outils d’automatisation et votre plateforme doivent pouvoir soutenir les deux stratégies et exécuter la bonne en fonction de la détection du problème.

Au prochain épisode

Nous examinerons les différents types de composants et les stratégies applicables à chacun, sans oublier les prérequis nécessaires. Enfin, nous nous pencherons sur les différents niveaux d’agrégation de composants. Restez à l’écoute !

Key Requirements for Practical DevOps Using Application Release Automation

Continuous Delivery
DevOps
Back to the blog
French - Pierre-Boris Bonafous

Pierre-Boris Bonafous

Pierre est spécialiste en DevOps et automatisation chez Automic.  Fort d’une expérience de 15 ans dans l’industrie, il a accompagné des sociétés telles qu’Orange, BNPP, Renault, Schlumberger, Valeo, et acquis une expertise dans les domaines de DevOps, la gestion de cycles de vie applicatifs et du Release Management.