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

18

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?

Hamish Downer
la source
10
Je ne peux pas dire que je suis d'accord avec cette méthodologie. L'UAT doit toujours être effectué sur des spécifications aussi proches que possible du système en direct (c'est-à-dire la mise en scène). Je ne peux pas compter le nombre de fois que nous avons fait l'UAT et que tout le monde s'est plaint de problèmes de vitesse, auxquels nous devons expliquer mille fois que "Le système en direct sera plus rapide". Et puis, lorsque le système en direct N'EST PAS plus rapide, à cause d'un bogue dans le code ou d'une requête SQL, vous devez manger vos propres mots.
Mark Henderson
UAT = Test d'acceptation utilisateur, non?
Martin Thoma

Réponses:

13

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à ...)

Chris S
la source
De plus en plus de tests ont généralement lieu sur le serveur intermédiaire, pas seulement sur UAT - juste avant la mise en production.
jftuga
3
@jftuga, voir la dernière phrase du premier paragraphe ...
Chris S
@Chris S: Si je vous comprends bien, alors il n'y a rien de tel qu'un "serveur intermédiaire", juste un serveur de production hors du pool, qui ne sert pas actuellement aux utilisateurs finaux. Cela a du sens et c'est une méthodologie que je suis en train de suivre, mais je n'appelle pas ces serveurs des "serveurs intermédiaires", juste des serveurs de production (qui ne sont pas dans le pool). Étant donné que partout où j'ai travaillé qui utilise des serveurs de transfert les a comme serveurs distincts, je ne pense pas que votre description d'un serveur de transfert soit l'utilisation standard de ce terme. Une bonne idée, mais pas ce que l'on entend normalement par "serveur de transfert" (d'après mon expérience, en tout cas).
iconoclaste du
1
@Brandon D'après votre expérience, qu'est-ce qu'un "serveur intermédiaire"? Cela peut être une différence régionale, comme «faire rebondir» un serveur.
Chris S
Cela me semble varier selon l'organisation. Je l'ai vu utilisé comme serveur UAT, comme serveur pour les développeurs pour mettre l'application dans un environnement supposé identique à la production, et probablement d'autres choses. (Je pense personnellement que la seule bonne stratégie est d'utiliser un vrai serveur de production pour la mise en scène.) Comme différentes organisations développent leur propre culture, je pense qu'elles développent également leur propre lexique, et donc des mots qui devraient avoir une signification standard dans l'industrie souvent malheureusement pas.
iconoclaste du
17

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.

Phil Hollenback
la source
5

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 .

Greg Bray
la source
0

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.

Hamish Downer
la source