À en croire les nombreux professionnels qui sont encore réticents à passer au DevOps, celui-ci imposerait de tirer un trait sur tout ce qui a été bâti par le passé pour repartir de zéro, ainsi que d’automatiser le processus de déploiement des logiciels et d’évolution des infrastructures. La perception commune est que les développeurs, testeurs et équipes d’exploitation évoluant dans des DSI classiques exercent chacun un rôle différent, n’ont ni les mêmes responsabilités, ni les mêmes missions, ni la même culture et travaillent en tant qu’entités distinctes dans des domaines fonctionnels séparés.

De ce fait, les organisations tendent souvent à rencontrer des difficultés lors du déploiement du concept, à fortiori sur les systèmes préexistants. L’un des défis que les entreprises, surtout les grandes, ont le plus de mal à relever, est d’améliorer la communication et la collaboration entre leur service informatique et leurs équipes métier. La philosophie DevOps réside essentiellement dans le changement de la culture IT dans le but de délivrer rapidement des services informatiques en s’appuyant sur des pratiques agiles et simplifiées au maximum, tout en mettant l’accent sur l’humain et la culture.

DevOps, pour quoi faire ?

Les services informatiques qui adoptent les pratiques du DevOps le font pour accélérer les montées de versions fréquentes dans le développement de logiciels, ce qui réduit le délai de commercialisation des nouveaux produits et services et améliore in fine l’expérience client. Pour ce faire, DevOps met un terme au cloisonnement des équipes – de développement, de test et d’exploitation – aussi courant qu’inadapté à l’évolution des besoins des entreprises d’aujourd'hui. En outre, il permet d’accélérer le déploiement des technologies digitales.

Les défis de l’adoption du DevOps

Les organisations qui n’ont jamais connu que l’ère du cloud – les fameuses digital natives – tendent à adopter le DevOps dès leur création, celui-ci s’inscrivant plus naturellement que chez les autres dans leur culture d’entreprise. A contrario, la mise en place de DevOps provoque plus de réticences chez les entreprises établies, ce qui s’explique par les difficultés qu’elle implique :

• Processus classiques d’exploitation : gestion des incidents de production, des pannes récurrentes et des réparations urgentes.
• Environnement de test : chaque environnement (test, développement, pré-production/simulation et production) étant unique, les équipes d’exploitation (Ops) sont contraintes de se concentrer sur les problèmes affectant l’environnement de production au détriment de l’amélioration de l’infrastructure.
• Tests classiques : des milliers de scénarios de tests de non régression interdépendants, exécutés à travers l’interface utilisateur de l’application durant plusieurs jours, ce qui rallonge les cycles de tests.. Pour peu que la stratégie de gestion des données de tests ne soit pas clairement définie et que les dépendances aval/amont se fassent sans techniques de virtualisation des services, l’exécution des tests prendra du retard.
• Développement classique : l’ajout de code en dernière minute et la correction tardive des anomalies provoquent l’allongement des cycles. Les retards pris sur le planning sont souvent dus à l’absence de procédures automatiques pour la vérification des versions et pour le déploiement.

Au fil du temps, une dette technique colossale s’accumule dans ces disciplines informatiques (1) et les équipes peinent souvent à travailler de concert. La solution consiste donc à introduire les pratiques du DevOps en procédant par petites touches, étape par étape.

Le test en continu comme fil conducteur

Le test en continu (TC) constitue une première étape et un socle indispensable à la mise en place du DevOps. Le TC est un mécanisme de rétroaction continu qui pilote le déploiement du logiciel tout au long du cycle de développement, où le feedback systématique, à chaque point de passage, active automatiquement le processus suivant dans la chaine de production si tous les voyants sont aux verts. Si le feedback est négatif, le processus est immédiatement arrêté et des mesures correctives sont appliquées.

La mise en place d’un écosystème de TC s’articule autour des étapes suivantes :

• Élaborer un ensemble de tests automatisés, sur le même principe que le code source d’une application, dans le référentiel de gestion des versions, plutôt que de sauvegarder les scripts de tests automatisés dans des outils de gestion de tests ou des dossiers partagés, ce que font bon nombre d’équipes en charge de l’exécution de tests.
• Intégrer la solution d’automatisation à l’outil de déploiement des versions pour permettre la centralisation de l’exécution et du reporting.
• Structurer la solution d’automatisation des tests en plusieurs couches pour accélérer la rétroaction à chaque point de contrôle. La plupart du temps, ces tests prennent la forme de :
  • Sanity test : un test automatisé qui s’assure de la disponibilité des services après un déploiement.
  • Smoke Test : la plus importante des suites de tests automatisés, qui vérifie que les fonctionnalités du système sont opérationnelles et qu’aucun défaut bloquant n’entrave leur fonctionnement.
  • Tests de non régression : le but est de réduire autant que possible le délai de détection des anomalies en exécutant en parallèle des tests automatisés à l’aide de plusieurs machines.
  • Non régression intelligente : au-delà d’un certain délai d’exécution de l’ensemble des tests de non régression, le TC perd de son efficacité car les cycles sont plus longs. Dans un tel cas de figure, des tests de non régression complets peuvent être exécutés la nuit ou en l’espace d’un week-end, selon l’alignement avec la fréquence des versions.
  • Simplifier les tests automatisés et les tests de migration existants pour utiliser davantage les outils open-source, comme Selenium, pour  renforcer l’efficacité de la mise en œuvre de DevOps
  • Construire une infrastructure « Cloud » pour tirer le meilleur parti des ressources disponibles et effectuer des tests de charge à la demande sans gaspiller ni le temps ni les ressources.

Adopter une approche intelligente pour l’automatisation des tests

Au sein des organisations qui ont adopté le DevOps, l’automatisation des tests prime toujours sur leur exécution manuelle. Cependant, l’automatisation des tests  doit souvent faire face aux obstacles suivants :

• Au fil du temps, les tests élaborés à partir d’outils commerciaux s’exécutent plus lentement.
• L’automatisation est réalisée avec des outils différents pour l’interface utilisateur, les APIs, la couverture mobile, etc.
• L’influence des équipes métier sur la définition des tests de non régression pousse souvent les équipes à développer des tests longs et coûteux.

Les composants d’une solution complète de non régression (Smoke tests, Sanity test et tests de non régression) doivent être conçus pour accélérer l’exécution de tests pendant les jours ouvrés, en appliquant des principes tels que :

• Un périmètre dynamique de non régression pour chaque version reposant sur le type de modifications apportées au code, avec la génération automatique de notes de versions alimentant la suite de non régression.
• Un framework d’automatisation des tests intelligent capable d’activer ou de désactiver les scénarios de test en fonction des modifications apportées aux applications.
• Un référentiel centralisé assurant la traçabilité entre les cas de test et les fichiers de code.
• Une approche fondée sur l’analyse des risques, avec un niveau de risque proche de zéro.

L’intégration de tests non-fonctionnels aux tests continus

Le principe de base des tests en continu est d’effectuer, le plus en amont possible, des tests à chaque fois qu’un changement est apporté à l’application. Cependant, si le dispositif de TC fait l’impasse sur les tests non-fonctionnels, comme les tests de performances et de sécurité, l’équipe ne résout qu’une partie de l’équation. Tous les problèmes de cette nature découverts tardivement peuvent réduire à néant les gains de productivité obtenus grâce au TC d’un point de vue fonctionnel et même compromettre le calendrier des versions.

L’intégration des tests non-fonctionnels dans le processus de TC n’est pas sans poser quelques difficultés, notamment pour les tests de charge, comme :

• L’indisponibilité de serveurs dédiés pour générer la charge utilisateur désirée.
• Les contraintes de capacité qui empêchent de dimensionner correctement l’environnement de TC pour supporter le poids des tests de charge.
• L’utilisation à la demande d’outils de surveillance et de diagnostic pour l’identification des goulots d’étranglement.

Les outils comme Apache JMeter s’imposent de plus en plus comme des solutions de choix pour la conduite de tests de performances dans les environnements DevOps.

Et après ?

L’idée que les services informatiques classiques ne peuvent adopter les méthodes du DevOps sans jeter à la poubelle tout ce qu’elles ont patiemment construit au fil des années relève du mythe. Les équipes dédiées aux tests jouent un rôle décisif par leur capacité à faciliter la transition vers le DevOps en mettant sur pied une infrastructure de TC et en créant une boucle de rétroaction en amont. Une fois la mise en place du TC réussie, le DevOps peut étendre son champ d’action au développement et à l’exploitation pour automatiser le déploiement des versions, l’analyse de la couverture du code, la supervision de la production et le provisioning d’environnement à la demande, de sorte à permettre l’établissement d’un cycle complet de TC et de développement continu (DC).

Plus que tout autre mouvement de ce type, DevOps repose sur l’investissement de sa communauté de techniciens informatiques passionnés de technologies. Le mouvement a aussi su s’imposer dans d’autres pans du secteur, qui profitent directement des dernières avancées de l’informatique en matière de produits et de services.