Comment implémenter un environnement de test figé?

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.

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.

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 .

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