Comment implémenter un environnement de test figé?


8

Voici une citation partielle d' une réponse à la question sur " Comment éviter les instabilités continues causées par l'intégration dans les environnements de test? ":

Cet environnement se fige généralement pendant les tests.

Ma question: quels sont les exemples d'implémentations d'un environnement gelé? C'est-à-dire que pouvez-vous faire pour imposer techniquement que personne (sauf si autorisé par un utilisateur autorisé comme un gestionnaire de versions) ne pourra rien changer dans un tel environnement gelé.

Précisions :

  • Je ne parle pas de ce que je pense être appelé "périodes gelées" pendant (par exemple) le traitement de fin d'année dans les banques. Il s'agit de ne pas être autorisé à appliquer (répéter tout) des changements aux environnements de production, afin de réduire le risque d'introduction de nouveaux changements / correctifs susceptibles d'avoir un impact sur le traitement de fin d'année.

  • Supposons que les utilisateurs qui sont autorisés à approuver / appliquer des modifications de toute façon (comme le gestionnaire de versions dans mon exemple), ne le feront que dans des cas exceptionnels. Par exemple, lors d'un test, un problème de gravité élevée est rencontré, pour lequel le report d'un correctif à une prochaine version n'est pas une option (car il risquerait de se produire si la version était activée sans ce correctif).

  • Il pourrait simplement s'agir de suspendre toute mise à jour automatisée pendant la durée du test. Le point est le suivant: éviter que quelqu'un d'autre mette à niveau une application A vers la version Y pendant qu'une autre équipe teste toujours l'application B dans la version X qui repose sur l'application A. Cela pourrait signifier avoir un gardien pour éviter qu'une équipe de test n'exige une mise à jour sur une dépendance sous tester.

Réponses:


3

Ma réponse dans le contexte de la question est un environnement de test très coûteux (comme les mainframes ou les très gros équipements de télécommunications, par exemple) qui devraient être partagés par plusieurs utilisateurs pour plusieurs tests, même simultanément.

Dans de nombreux cas, ces équipements disposent d'un système de gestion de logiciels chargé, entre autres, de contrôler la (dé) installation / mise à niveau / rétrogradation des logiciels, etc. Qui devrait avoir un mécanisme pour bloquer de telles opérations (qui serait, si j'ai bien compris la question, équivalent à geler l'environnement) basé sur des politiques plus ou moins programmables.

Dans ce cas, une politique spécifique pourrait être développée exactement pour prendre en charge le programme de congélation souhaité nécessaire pour l'environnement de test. Idéalement automatisé, acceptant les déclencheurs de gel / dégel des sources externes qui pourraient être les enveloppes d'exécution de test ou les systèmes CI. Et peut-être avec des remplacements déclenchés par l'homme, si cela est jugé nécessaire.

Bien sûr, une telle fonctionnalité du système de gestion de logiciels serait utile lors du test d'autres composants de l'équipement, mais peut-être pas pour les tests du système de gestion de logiciels lui-même.


Cette réponse concerne exactement 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?
Pierre.Vriens

Probablement un autre serait mieux - le mien est principalement une opinion car je n'ai pas fait l'expérience d'un tel environnement directement, je n'en ai discuté que de temps en temps avec des amis qui l'ont fait.
Dan Cornilescu

4

TeamCity dispose d'une fonction de génération de ressources partagées qui vous permet de définir une ressource dont dépendent plusieurs définitions de génération. Les définitions de build peuvent nécessiter un verrou en lecture ou en écriture, vous pouvez également définir si ces verrous sont exclusifs ou autorisent un certain degré de parallélisme.

Si nous faisons les hypothèses suivantes sur un environnement partagé nommé PreProd :

  • Il existe une ressource partagée nommée "PreProd".
  • Toutes les définitions de build, telles que les déploiements, qui apportent des modifications à cet environnement prennent un verrou d'écriture exclusif sur "PreProd".
  • Toutes les définitions de build, telles que les tests non restrictifs, qui effectuent des opérations en lecture seule sur l'environnement prennent un verrou de lecture non exclusif sur "PreProd".
  • TeamCity est le seul processus qui peut faire quoi que ce soit sur PreProd, bien que peut-être via un autre outil.

Par conséquent, les éléments suivants sont vrais:

  • Lorsqu'un déploiement se produit, rien d'autre ne peut utiliser PreProd, ils seront mis en file d'attente.
  • Lorsqu'un test est en cours d'exécution, tout déploiement est mis en file d'attente jusqu'à la fin des tests.

Vous pouvez utiliser un mécanisme similaire avec Jenkins en utilisant le plugin Exclusion . En fait, vous pouvez intégrer cette fonctionnalité dans n'importe quel processus utilisant le verrouillage ou le sémaphore - par exemple Apache ZooKeeper ou HashiCorp Consul .


Bonne description des implémentations «standard» de ce que j'ai mis dans l'idée «garde» :)
Tensibai

merci, des liens à partager / ajouter à TeamCity lui-même, pour en savoir plus?
Pierre.Vriens

1
Absolument, j'ai ajouté des hyperliens vers TeamCity et Jenkins dans la réponse, je peux personnellement recommander le cours TeamCity sur Udemy .
Richard Slater

merci pour la mise à jour supplémentaire! PS: pourquoi ne pas inclure également le lien du cours dans votre réponse, par exemple via un PS à la fin? De cette façon, si un jour un modérateur arrive et commence à supprimer des commentaires, ce n'est pas un risque de se perdre (cela m'arrive beaucoup sur un autre site SE).
Pierre.Vriens

Je suis prudent de publier des liens vers du contenu commercial dans les réponses sur les sites SE en général. Je veux être utile dans la mesure où je recommande ce cours, cependant, car c'est le seul cours que j'ai suivi, c'est vraiment ma propre opinion.
Richard Slater

0

Cela ressemble à un motif anti pour moi. Je crois que tout le monde ou personne ne devrait avoir accès à tous les environnements.

Si les utilisateurs subvertissent le processus, j'examinerais sérieusement le processus pour essayer de m'assurer qu'il ne gêne pas les gens.

La mise en œuvre d'un mécanisme automatisé qui applique un état spécifique est également utile pour encourager les gens à faire les choses correctement. Cela peut être via la gestion des configurations ou la destruction de toute instance immuable si quelqu'un s'y connecte


Veuillez vérifier la 2ème "note" que j'ai ajoutée. Cela vous aide-t-il de reconsidérer votre premier paragraphe? En dehors de cela, je ne comprends pas comment la partie restante de votre réponse répond réellement à la partie "comment" de ma question. Peut-être y a-t-il quelque chose que je ne comprends pas, alors pouvez-vous m'aider à mieux comprendre votre réponse s'il vous plaît? PS: Ne vous inquiétez pas, je note rarement les réponses (si je le fais, je laisse des commentaires ...).
Pierre.Vriens

Vous avez un problème xy meta.stackexchange.com/questions/66377/what-is-the-xy-problem . Je ne réponds pas comment implémenter votre solution Je réponds comment je résoudrais votre problème
Robo

@Robo Je ne suis pas d'accord, la question sur le sens a du sens, sans aucune subversion ou autre. Cela pourrait simplement suspendre toute mise à jour automatisée pendant la durée du test. Vous voyez cela comme une action manuelle, le point est: évitez que quelqu'un d'autre mette à niveau une application A vers la version Y pendant qu'une autre équipe teste encore l'application B dans la version X qui repose sur l'application A. Cela signifie avoir un gardien pour éviter une équipe de test d'exiger une mise à jour sur une dépendance en cours de test.
Tensibai

Cela ne ressort pas clairement de votre question. Dans ce cas, vous avez besoin d'une sorte de verrou.
Robo

Veuillez noter que je viens d'intégrer (la plupart) le commentaire de @Tensibai en guise de clarification supplémentaire (dernière puce). J'espère que "cela" aidera à clarifier ma question. Peut-être que vous (Robo) voulez également revoir votre réponse selon cette clarification supplémentaire? PS: merci Tensibai ...
Pierre.Vriens
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.