DevOoops : les pièges du déploiement
Pour une entreprise souhaitant accélérer les tests automatisés de développement logiciel et écourter les cycles de feedback, une méthode efficace consiste à effectuer une exécution de l'intégration et de la livraison continues (CI/CD) en parallèle.
En revanche, il est important de s’assurer que le déploiement bénéficie d’un traitement particulier et qu’il n’est pas effectué en parallèle. Une configuration de ce type entraînerait la mise à jour du code pendant l’exécution des tests. Les codes “feedback” ne seraient alors pas pris en compte, et l’automatisation des tests en amont du déploiement n’aurait plus d’intérêt.
Ce scénario revient souvent lorsqu’il est question de DevOoops. Nos collaborateurs mentionnent effectivement ce risque de faux-pas dans la mise en pratique d’une approche « everything as code ».
Le plus souvent, il s’agit de problèmes liés à l’application du processus « pipeline as code ».
Pour assurer son succès, les équipes doivent associer une approche orientée qualité aux tests automatisés, et ce tout au long du cycle de livraison continue. L’équipe DevOps doit appliquer ses processus de test et de gestion de la qualité aussi bien aux configurations de l’environnement qu’à son « infrastructure as code ».
Il est important de traiter les pipelines de livraison continue comme des applications. Les équipes en charge du développement doivent activement rechercher et systématiquement éliminer les dysfonctionnements et erreurs au sein de leur code. Une mauvaise gestion de la création et du développement de pipelines de livraison continue complexes impacterait les coûts et augmenterait les risques.
Ainsi, en l’absence d'une vérification adéquate des tests effectués sur le code, il est possible qu’une application soit publiée sans qu'elle n'ait été testée. Par ailleurs, si elle n'est pas soumise à des contrôles de sécurité, le risque de publier des données de pré-production n’est pas éliminé.
Au-delà des risques inhérents au code non testé, il est aussi important de prêter une attention particulière aux pipelines de livraison continue non testés ou non gérés. Si les contrôles de sécurité ne sont pas respectés, les équipes doivent prendre en considération les conséquences pour leurs développeurs, leur entreprise et leurs clients.
Voici une liste de procédures à suivre scrupuleusement lors de la publication de pipelines de livraison continue :
· Build : il est nécessaire de travailler de manière chronologique, en commençant par la définition et le codage du pipeline de livraison continue et en suivant le déroulé de construction des applications et des outils de développement : dev, test et déploiement. S’il est difficile de créer une solution d'automatisation complète et idéale du premier coup, suivre ce déroulé permet aux équipes de visualiser le cycle de vie de l’outil.
· Gestion : il s’agit ici de définir le pipeline de livraison continue par le biais d’une approche « everything as code» ou « pipeline as code ». Pour en tirer profit, l’entreprise doit gérer le développement de son pipeline de livraison continue de la même manière qu’elle le fait pour le code applicatif, en suivant les bonnes pratiques en matière de développement logiciel. L’équipe doit ainsi stocker le code source de son pipeline de livraison continue dans un gestionnaire de version et exploiter les technologies propres à chaque langage. Cela permet de contrôler la syntaxe. (Si l’entreprise utilise du code Groovy ou basé sur Jenkins, certaines versions de Lint peuvent prendre en charge ces fonctions.)
· Création d'environnements de simulation : les équipes DevOps doivent créer des environnements de simulation ou tester les pipelines afin de valider leur processus de livraison continue. Pour vérifier leur bon fonctionnement, ces pipelines doivent être confrontés aux outils que l’entreprise utilise, avec un code de référence représentatif des applications servies par le pipeline, mais s’arrêtés avant la mise en la production.
Cette approche permet de simuler de manière itérative les modifications apportées au code applicatif et d'effectuer les premières analyses et vérifications en vue de l’intégration du pipeline de livraison dans le système de configuration logiciel (SCM). Il est recommandé d’effectuer une première validation, puis de vérifier les opérations attendues dans un environnement de simulation avant de déployer le code du pipeline comme base pour la production d'applications essentielles à l'entreprise.
Il est ainsi primordial de garantir un contrôle du code applicatif et des environnements avant leur déploiement. Les équipes DevOps se doivent de créer des pipelines de livraison continue de façon à ce que les tests parallèles soient gérés comme une étape de validation avant la transmission vers l'environnement de production.
Le système créé doit permettre que les modifications ne soient pas déployées automatiquement même si elles ont dûment été testées et validées.
Un déploiement ne doit être effectué que si tous les processus d'un pipeline ont été respectés, et lorsque l'ensemble des tests, des validations, des contrôles et des approbations ont été effectués.