Comment éviter les instabilités continues causées par l'intégration dans les environnements de test?

Supposons que vous utilisez des processus d'intégration continue qui mettent fréquemment à jour certains environnements cibles, de sorte que chaque fois qu'il y a des changements, "vous" pouvez tester vos changements immédiatement. Cela fait partie des objectifs de CI, non?

Mais supposez également que d'autres personnes participent à votre cycle de test, par exemple des gestionnaires ou des clients. Il est logique d'impliquer d'autres personnes dans la révision (rupture?) De vos changements à venir, non?

Mais si vous continuez à apporter des changements dans l'environnement dans lequel ces autres personnes essaient sérieusement de les tester, plusieurs problèmes peuvent survenir, tels que:

• they peut perdre son temps à signaler des problèmes qui, au moment où ils enregistrent le rapport (en profondeur), ils ne peuvent même plus reproduire le problème eux-mêmes (par exemple, parce que vous avez également rencontré par hasard le même problème et que vous l'avez déjà résolu dans leur environnement).
• you peut ne pas être en mesure de reproduire les problèmes qu'ils ont signalés, car les environnements dans lesquels ils ont rencontré un problème ne sont plus identiques (vous (!!!) avez peut-être superposé leur environnement).

Alors, que pouvez-vous faire (comment configurer les choses?) Pour éviter de telles situations (frustrantes)?

Je vais donner mon expérience sur celui-ci, principalement parce qu'il montre pourquoi certaines réponses ne sont pas toujours applicables.

Un peu de contexte pour commencer:

• Nous avons 7 environnements pour héberger environ 80 applications, la plupart d'entre elles dépendent les unes des autres via des services Web ou des tables partagées sur db2-iSeries.
• Pour le meilleur ou pour le pire, les iSeries sont notre système de référence DB.
• Ce dernier point invalide toute idée d'amener l'application avec ses dépendances dans un environnement isolé, car mettre en place un AS400 pour chacun coûterait trop cher et nous n'aurions pas le matériel pour l'exécuter de toute façon.

Ce que nous faisons n'est pas une livraison continue entièrement automatisée, nous avons un calendrier de versions pour mettre en place un lot cohérent d'applications pour les opérations générales. En plus de cela, chaque équipe de test peut déclencher une version dans l'un des environnements Q / A de l'application qu'elle teste et peut verrouiller une version d'application pour éviter qu'une autre demande d'équipe ne casse ses tests.

Les dépendances des applications sont vérifiées avant la publication, de sorte que le système ne publiera pas quelque chose si les autres applications ne peuvent pas être mises à jour ou ne correspondent pas à ses dépendances nécessaires. L'idée principale est d'autoriser les mises à jour quand cela n'affectera personne, si aucun test n'est prévu, cela devrait provenir de l'environnement précédent (et nous visons à supprimer les versions planifiées dans les 5 premiers environnements à moyen terme, nous avons maintenant validé ce système de méthode «à la demande»).

La version courte est d'avoir un système de «sémaphore» autour des applications dans l'environnement, une équipe devrait être capable de verrouiller son application cible avec ses dépendances (et dépendances transitives) pour le temps des tests manuels.
L'implémentation de ce sémaphore dépend fortement de votre système d'automatisation, donc je ne m'étendrai pas là-dessus.

Bien sûr, le moyen le plus simple est, comme d'autres l'ont mentionné, de créer un nouvel environnement pour une application avec toutes ses dépendances pour éviter le sémaphore décrit ci-dessus.

On dirait que vous parlez d'un environnement de test qui est constamment réutilisé sans être réinitialisé de manière fiable pour chaque exécution de test. Cela rend un tel test peu fiable. Similaire, du point de vue de la fiabilité, avec des tests manuels, si vous le souhaitez.

À mon humble avis, vous ne devriez pas utiliser de tels tests dans vos objectifs de qualification CI / CD car cela invalidera efficacement votre processus de qualification (au moins dans ce domaine). Dire que le logiciel réussit le test X sans exécuter réellement le test X pour chaque version logicielle livrée ou sans avoir la certitude que le passrésultat obtenu n'est pas accidentel (en raison de faux positifs) érodera le niveau de confiance de vos tests. Les faux négatifs ne nuisent pas à la crédibilité, mais ils sont également indésirables en raison du «bruit» inutile qu'ils créent.

C'est bien d'exécuter de tels tests en dehors de votre processus de qualification CI / CD. Mais vous traitez un résultat ayant échoué dans de tels tests, tout comme un bogue trouvé par le client: vous devez reproduire le problème de manière fiable pour pouvoir développer un correctif et confirmer que le correctif fonctionne. Et vous ne pouvez pas vraiment le faire si les tests ne sont pas fiables.

Si vous prévoyez de résoudre le problème, idéalement, vous devez d'abord développer un scénario de test fiable et automatisé pour reproduire le problème. Que vous utiliseriez pour développer un correctif et confirmer son efficacité (le résultat du test devrait passer de FAIL à PASS). Vous pouvez (devriez?) Également placer ce testcase dans votre processus de qualification CI / CD pour éviter toute réapparition future, si vous le souhaitez - pour augmenter le niveau de qualité global de votre version logicielle.

L'approche habituelle consiste à créer différents environnements:

DEV - c'est l'endroit où l'équipe de développement gâche les choses. Voici créer tous les réglages des modifications, déployer une nouvelle version, etc. Voici l'endroit où CI est pleinement intégré.

PREPROD / QA - c'est l'endroit où "jouer" l'équipe QA / test / validation fait des tests. Cet environnement se fige généralement pendant les tests. L'intégration de CI à cet environnement ne vise qu'à fournir une nouvelle version du produit, des configurations, etc.

PRODUCTION - faut-il expliquer :)?

Si vous faites du CI / CD, cela implique qu'il y a des tests automatisés (CI) avant le déploiement (CD). Si vous rencontrez de nombreux problèmes dans votre environnement de test, cela signifie qu'ils ne sont pas détectés par les tests exécutés avant le déploiement; cela indique que les tests automatisés sont insuffisants. Si les développeurs rencontrent des problèmes où des défauts apparaissent dans le ou les environnements de test, ils doivent améliorer leurs suites de tests automatisés afin d'éviter cela. Cela améliorera également la qualité et la fiabilité dans l'ensemble, tout au long de la production.

Pour compléter la réponse de Romeo Ninov, en interne dans un environnement, vous devez essayer de séparer les applications autant que possible. C'est en partie pourquoi docker a eu autant de succès pour dev / test. Cela vous fait presque croire que vous ne partagez pas du tout un environnement.

L'autre option est d'avoir des serveurs très clairement définis sur lesquels s'exécutent les applications, qui sont séparés du reste de l'infrastructure qui constitue votre environnement. C'est à dire. Toutes les machines de gestion ou d'activation de l'environnement sont hébergées sur des serveurs séparés et à longue durée de vie. Ensuite, vous connectez de nouveaux serveurs de courte durée basés sur une image connue pour tester une application et, si des modifications sont apportées à l'image de base, vous devez appliquer ces modifications partout pour chaque nouveau composant. Ce qui signifie tester les changements par rapport à tout.

Si une équipe appdev demande un changement qui casse l'application de quelqu'un d'autre, alors pas de chance, elle doit créer en interne un atténuant dans son code et garder ses exigences spécifiques distinctes de celles des environnements.