Environnement intermédiaire vs environnement de production
Je travaille pour une entreprise où nous construisons des applications d'entreprise, et nous maintenons trois environnements: développement (ou dev), staging (ou stage) et production (ou prod).
La signification de dev est intuitive: c'est l'environnement utilisé lors du développement de l'application.
Quelle est la différence entre les environnements staging et production?
Pour les petites entreprises (la taille du vôtre n'est pas claire), trois environnements (développement, stade, production) sont communs. Les grandes entreprises auront souvent un environnement d'assurance qualité entre le développement et l'étape.
Ceux-ci se décomposent normalement comme suit:
dev: Copie de code de travail. Les modifications apportées par les développeurs sont déployées ici afin que l'intégration et les fonctionnalités puissent être testées. Cet environnement est rapidement mis à jour et contient la version la plus récente de l'application.
qa: (Toutes les entreprises ne l'auront pas). Environnement pour l'assurance qualité; cela fournit une version moins fréquemment modifiée de l'application sur laquelle les testeurs peuvent effectuer des vérifications. Cela permet de générer des rapports sur une révision commune afin que les développeurs sachent si des problèmes particuliers détectés par les testeurs ont déjà été corrigés dans le code de développement.
staging: Il s'agit de la version candidate, et cet environnement est normalement un miroir de l'environnement de production. La zone de transit contient la "prochaine" version de l'application et est utilisée pour les tests de résistance finaux et les approbations des clients/gestionnaires avant la mise en ligne.
production: Il s'agit de la version actuelle de l'application, accessible aux clients/utilisateurs finaux. De préférence, cette version ne change pas, sauf pendant les versions planifiées.
Je suis un peu surpris qu'un environnement de test ne soit pas également présent, comme un emplacement pour le code avant d'être promu en staging.
Pour répondre à la question:
Un environnement scénique doit refléter l'environnement de production aussi fidèlement que possible.
Il est utilisé pour la vérification des procédures de déploiement - en s'assurant que lorsque le code est prêt pour la production, il peut être déployé sans causer de problèmes.
Autrement dit, le code passe à la mise en scène - il est entièrement testé et régressé pour s'assurer que le déploiement s'est déroulé comme prévu (et pour résoudre tout problème s'il ne l'a pas fait).
L'environnement scénique est un environnement préprod qui reflète la production. Souvent, il peut avoir des données de production afin qu'un groupe de test composé d'utilisateurs réels et de testeurs d'assurance qualité puisse confirmer que la base de code/les données pré-publiées se déploieront et fonctionneront correctement dans un environnement de type prod, généralement via des cas d'utilisation scriptés et une régression tests.
En tant que notes @Oded, il est généralement courant d'avoir un environnement QA que les testeurs QA utilisent pour tester le code.
Mon expérience avec le gouvernement américain/Department of Defence IT est que:
- DEVELOPMENT/TEST est destiné aux développeurs et aux développeurs d'applications. Ils créent et testent des applications loin des systèmes d'entreprise.
- Une fois les applications terminées, elles seront déployées dans l'environnement informatique dans le ou les serveurs PACKAGING.
- À partir de là, les applications sont prises en charge par l'informatique, migrées vers STAGING (qui permet à l'informatique de développer/vérifier les directives d'implémentation, les configurations, etc.). Les tests utilisateur peuvent se produire à ce stade dans une certaine mesure pour vérifier que l'application fonctionnera comme prévu dans un système qui réplique PRODUCTION.
- Si tous les plans de test sont terminés et qu'ils sont prêts à être utilisés, l'application sera déplacée en PRODUCTION et passera en mode de maintien en puissance (c'est-à-dire opérations et maintenance ou O&M).
- De nouvelles mises à jour des développeurs seront également déployées dans PACKAGING et le processus se poursuit.
En tant que développeur web, il y a principalement trois environnements à considérer pratiquement :
Production: l'environnement configuré pour héberger la version finale d'un produit ciblant les utilisateurs finaux. Il est optimisé pour la sécurité et les performances. Il est hébergé sur un serveur en direct. Elle nécessite un soutien alerté et urgent. C'est essentiel pour les données. Par conséquent, ses données sont sauvegardées régulièrement. Cela implique également la gestion des risques et la reprise après sinistre. L'environnement de production est configuré pour afficher des erreurs conviviales pour les utilisateurs finaux.
Staging: L'environnement configuré pour héberger la version candidate de l'application après avoir déclaré un gel de code. Il cible le chef de projet/propriétaire aux côtés de l'équipe de développement pour convenir de la portée du candidat à la version. Cela implique une assurance qualité et aussi l'équipe de développement pour faire les derniers correctifs et l'ameublement final avant la mise en production. La meilleure pratique consiste à imiter l'environnement de production en utilisant les dernières données disponibles à partir d'une base de données en direct copiée à partir de l'environnement de production. Normalement, l'environnement de transfert n'est accessible que par l'équipe interne et les parties prenantes.Par conséquent, il est soit sécurisé sur un serveur public, soit publié sur un environnement intranet si toutes les parties prenantes peuvent accéder à un réseau local. L'environnement de transfert est configuré pour afficher des erreurs techniques moyennes ou complètes.
Développement: L'environnement privé configuré par un seul développeur sur sa machine pour vérifier son propre travail pendant un cycle de développement, normalement, appelé un sprint dans un environnement Scrum. L'environnement de développement est configuré pour afficher toutes les erreurs techniques.