Quel est l'intérêt de la mise en scène?

Je pensais avoir réglé cela, mais après avoir lu la livraison continue (excellent livre), je suis un peu confus. Ils parlent d'avoir des serveurs pour:

• développement
• diverses formes de tests automatisés
• test d'acceptation par l'utilisateur (UAT) - c'est-à-dire s'asseoir avec le client et le lui montrer, et le laisser faire des tests exploratoires. Les testeurs internes pourraient également utiliser cette configuration pour des tests exploratoires.
• mise en scène
• production.

J'avais toujours pensé à la mise en scène comme fournissant la fonction UAT, mais ils semblent avoir la mise en scène comme un niveau distinct. Donc, dans ce schéma, quelle fonction fourniraient les serveurs de transfert?

La mise en scène reviendrait à mettre en place les systèmes de produits complets, mais ne les utiliserait pas encore. Lorsqu'ils entreront en service, ce sera la «production». Vous devez tout mettre en place car il sera utilisé, tester, puis basculer le commutateur.

L'UAT utilise couramment un environnement de «test» qui est significativement différent du matériel / logiciel / configuration qui sera utilisé en production.

Par exemple, là où je travaille, nous demandons aux clients de tout tester dans un environnement VM fonctionnant sur nos serveurs. Lorsque leur système sera mis en service, il fonctionnera sur leur matériel, dans leurs installations, s’intégrant probablement à leurs systèmes existants; cela n'aura absolument rien à voir avec nos serveurs ou notre environnement de test (sauf que le code et certaines configurations ont été copiés à partir de là ...)

Je travaille dans l'équipe de gestion des versions d'une très grande entreprise Internet. Nous utilisons essentiellement le processus que vous avez décrit ci-dessus, et nous avons choisi ce processus exprès. Dans notre méthodologie, la mise en scène sert de mécanisme de branchement pour un niveau final de test en production.

Évidemment, vous voulez faire tous les tests avant de passer à la production, mais dans un environnement vaste et complexe avec beaucoup d'utilisateurs, c'est un objectif très difficile à atteindre. En particulier, il est pratiquement impossible de charger adéquatement un logiciel de test dans QA. Les tests fonctionnels sont beaucoup plus faciles à automatiser que les tests de charge. Lorsque vous avez plusieurs milliers d'utilisateurs sur vos serveurs, les choses échouent de manière étrange et difficile à prévoir.

Voici donc ce que nous faisons:

• Développement
  • comprend une intégration continue et des tests automatisés
• test de version
  • mon groupe analyse la version elle-même
  • examen des journaux d'installation
  • test de restauration
• QA
  • tests d'acceptation des utilisateurs

C'est à ce point que nous passons entre la mise en scène et la production. Nous utilisons un modèle de train pour les versions, avec un nouveau train commençant toutes les quelques semaines. Même les trains numérotés vont aux serveurs intermédiaires (qui sont en production). Les trains impairs ne le font pas.

Entre les trains pairs, les développeurs ont la possibilité de pousser des modifications individuelles sur les serveurs de transfert ( après que ces changements ont été testés par QA bien sûr). Cela leur permet de valider que leur logiciel fonctionne comme prévu dans un environnement de production réel. Ceci est généralement réservé aux composants qui sont considérés comme à risque plus élevé, nous ne poussons pas chaque petite pièce à la mise en scène.

Ensuite, tout le monde comprend que lorsque le prochain train pair commencera, il effacera ce qui se trouve sur les serveurs de transit et les replacera sur la ligne de base du train. Les développeurs s'assurent que leurs modifications sont entrées dans le train, ou décident qu'ils ne sont pas encore prêts pour une utilisation générale, auquel cas ces modifications sont simplement effacées sur les serveurs de transfert.

Pour résumer, la réponse courte (au moins pour nous) est qu'il est impossible de tester complètement des systèmes complexes en AQ. La mise en scène fournit un moyen sûr d'effectuer des tests de production limités.

Sur une note connexe, voici mes diapositives d'une présentation que je viens de donner sur le fonctionnement de notre processus de publication.

L'explication la plus simple du transfert consiste à tester votre processus de déploiement et à tester à l'aide de la source de données réelle. Certains systèmes combinent la mise en scène avec leurs environnements de test, mais pour les systèmes à grande échelle, le processus de déploiement peut être très complexe ou des étapes de test supplémentaires peuvent être nécessaires une fois que vous vous connectez à la source de données en direct / de production. Dans ces cas, un environnement intermédiaire vous permet de tester votre processus de déploiement et de vérifier les bogues de dernière minute en utilisant des données en direct, puis une fois que les choses ont été vérifiées comme fonctionnant, vous pouvez rapidement basculer l'environnement de la scène dans l'environnement de production.

Un exemple de cela serait Windows Azure, qui nécessite 5 à 25 minutes pour déployer une nouvelle version, mais vous pouvez déployer sur un environnement de transfert, effectuer des tests, puis échanger instantanément les environnements de production et de transfert .

Je viens de tomber sur cet article sur les environnements de mise en scène qui dit

Le staging est l'endroit où vous validez les inconnues connues de vos systèmes.

L'article mérite d'être lu en entier.