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

19

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)?

Pierre.Vriens
la source

Réponses:

10

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.

Tensibai
la source
Cette réponse est une variation de ce à quoi je suis habitué (mainframes), où nous faisons ce genre de choses depuis au moins 1,5 décennie déjà (avant la naissance de "DevOps"). Je me demande s'il serait judicieux d'ajouter ma propre réponse ici (pour développer davantage cette réponse, comment nous procédons avec CMN / ZMF pour, par exemple, les "banques"), ou simplement la prendre pour une nouvelle question (auto-répondue). Qu'est-ce que tu penses? Aussi, je suis curieux de savoir ce truc de métaphore, mérite une nouvelle question (en référence à cette réponse)? PS: ça vous dérange si je corrige quelques fautes de frappe?
Pierre.Vriens
Pas de problème pour l'édition :) Je l'ai gardé générique, ce n'est pas très spécifique à une organisation devops à mon humble avis. Encore une fois, DevOps est un changement d'organisation, qui peut aider à mettre en place une meilleure automatisation en partageant les préoccupations ... donc j'appelle cela un sémaphore comme en programmation, je ne pense pas que cela vaille la peine mais c'est à vous de
décider
Ok, édition terminée (comme d'habitude: restauration / amélioration comme bon vous semble). BTW, avez-vous un "s" sur votre clavier?!?!?! A part ça: des trucs à penser ce week-end: voir ma dernière méta-question ... Bon week-end! Temps de jardinage par ici (élagage ...)
Pierre.Vriens
8

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.

Dan Cornilescu
la source
Il y a beaucoup à digérer dans votre réponse (je ne suis pas sûr de l'avoir déjà complètement compris). Mais ce que vous avez écrit sur " exécuter de tels tests en dehors de votre processus de qualification CI / CD ": je m'attendrais à ce que le résultat final de ce qui est produit / livré soit stocké dans vos environnements QA et prod (via CD, automatique ou manuel). Mais cela « me semble » également que CI devrait également fournir sa sortie là-bas, tandis que «l'extérieur» semble être une séparation ou une duplication ou quelque chose, non?
Pierre.Vriens
Les références insideet outsidesont relatives à la boucle de vérification CI. Fondamentalement, je me demande la raison de l'existence de l'environnement QA - la plupart des tests qui y sont effectués devraient être fiables et éventuellement exécutés dans le cadre des vérifications CI, en particulier dans un contexte de déploiement continu - puisque vous souhaitez les exécuter à chaque itération CI (réussie jusqu'à ce point au moins) de toute façon.
Dan Cornilescu
7

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 :)?

Roméo Ninov
la source
ok, ça devrait aider à améliorer la stabilité, merci! Ma question concerne les environnements de "test", donc évidemment la "production" ne doit pas être considérée comme telle. Malgré ceux qui utilisent la "production" pour les tests, vous connaissez le dicton " Le meilleur test est de l'activer en production, et si cela ne fonctionne pas, effectuez simplement un rollback / backout! "?
Pierre.Vriens
@ Pierre.Vriens, "jouer" dans prod IMHO n'est pas sage :) Une telle séparation de l'environnement est intentionnelle. Sur le travail précédent, nous avions 5 environnements différents .... A votre service
Romeo Ninov
1
"Je" suis d'accord qu'un tel jeu n'est pas sage. Cependant, que pouvez-vous faire pour les cowboys (mon «terme» que j'utilise pour de tels juppies) qui continuent de le faire encore et encore, et chaque fois qu'ils obtiennent l'approbation de leurs gestionnaires pour contourner l'activation de la version mensuelle (par exemple) , par encore un autre bugfix (par exemple pour leur bugfix de la veille ... qui a introduit un nouveau bug). Vous pensez que cela ne se produit pas dans le monde réel? BTW: à propos du "gel" dans votre réponse, vous pensez qu'il est logique de poster une question comme "Quels sont les exemples d'implémentations d'un environnement gelé?"
Pierre.Vriens
@ Pierre.Vriens, pour moi, il est parfaitement logique de poster une telle question. Normalement, cela est réglementé par les règles de l'entreprise, mais les devops créent un environnement assez dynamique et cela peut être un vrai défi :)
Romeo Ninov
1
C'est mon approche préférée, de cette façon, cela donne un environnement où les développeurs peuvent immédiatement tester leurs changements dans un environnement intégré, mais gardent l'AQ propre jusqu'à ce que le code soit prêt à être formellement testé
Taegost
3

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.

Adrian
la source
3

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.

hvindin
la source
Points de vue / ajouts intéressants, bien qu'il y ait certaines choses que vous souhaitez peut-être affiner / retravailler: (1) "applications" dans ce contexte, que voulez-vous dire (quelques exemples?) (2) une idée de la façon dont cela pourrait fonctionner (bon vieux) environnements mainframe (3) qu'est-ce qu'un "atténuant" dans ce contexte ici? PS: faites-moi savoir si vous pensez que je devrais créer une nouvelle question pour l'une de ces "choses" (balles).
Pierre.Vriens