Environnement de transfert 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 ), la mise en scène (ou stade ) et la 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 de transfert et de production ?

Pour les petites entreprises (la taille de votre entreprise n’est pas clairement définie), trois environnements (développement, scène, production) sont courants. 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 de la qualité; Cela fournit une version de l'application moins fréquemment modifiée sur laquelle les testeurs peuvent effectuer des contrôles. Cela permet de créer 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 transfert contient la version "suivante" de l'application et est utilisée pour les tests de contrainte finaux et les approbations client / responsable avant la mise en ligne.

production : Il s'agit de la version actuelle de l'application, accessible au client / utilisateur final. Cette version ne change pas de préférence, sauf pendant les versions planifiées.

Je suis un peu surpris qu'un environnement de test ne soit pas présent non plus, car c'est un emplacement de code avant de passer à la mise en scène.

Pour répondre à la question:

Un environnement de scène doit refléter le plus fidèlement possible l'environnement de production.

Il est utilisé pour la vérification des procédures de déploiement. Il permet de s'assurer que, lorsque le code est prêt pour la production, il peut être déployé sans causer de problèmes.

En d’autres termes, le code passe en staging - il est testé et régressé de manière exhaustive pour garantir que le déploiement se déroule comme prévu (et pour régler tout problème s’il ne l’est pas).

L’environnement de la scène est un environnement de préproduction qui reflète la production. Souvent, il peut contenir des données de production, de sorte qu'un groupe de test composé d'utilisateurs réels et de testeurs d'assurance qualité peut confirmer que la base de données / les données pré-publiées se déploieront et fonctionneront correctement dans un environnement de type prod, généralement par le biais de scénarios d'utilisation et de régression tests.

Comme le note @Oded, il est généralement courant de disposer d'un environnement d'assurance qualité utilisé par les testeurs d'assurance qualité pour tester le code.

Mon expérience avec le gouvernement américain / le département de la défense informatique est la suivante:

1. DEVELOPPEMENT / TEST est destiné aux développeurs et aux développeurs d'applications. Ils construisent et testent des applications en dehors des systèmes d'entreprise.
2. Une fois les applications terminées, elles seront déployées dans l'environnement informatique sur le (s) serveur (s) PACKAGING.
3. À partir de ce moment, les applications sont prises en charge par le service informatique, puis migrées vers STAGING (ce qui permet au service informatique de développer / vérifier les consignes d'implémentation, les configurations, etc.). Les tests utilisateur peuvent éventuellement se produire à ce stade pour vérifier que l'application fonctionnera comme prévu dans un système répliquant PRODUCTION.
4. Si tous les plans de test sont terminés et qu’ils sont prêts à fonctionner, l’application passera à PRODUCTION et passera en mode Maintien en service (c.-à-d. Exploitation et maintenance ou F & E).
5. Les 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 existe principalement trois environnements à prendre en compte de manière pratique :

Production : environnement configuré pour héberger la version finale d'un produit destiné aux utilisateurs finaux. Il est optimisé pour la sécurité et la performance. Il est hébergé sur un serveur live. Cela nécessite un soutien alerte et urgent. C'est critique 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 simples aux utilisateurs finaux.

Staging : environnement configuré pour héberger la version candidate de l'application après avoir déclaré le gel du code. Il vise le chef de projet / propriétaire aux côtés de l’équipe de développement pour convenir de la portée de la version candidate. Cela implique une assurance qualité ainsi que l’équipe de développement chargée de la mise au point finale et de 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 dynamique 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 sécurisé sur un serveur public ou 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 : environnement privé configuré par un seul développeur sur sa machine pour vérifier son propre travail au cours d'un cycle de développement, appelé normalement un sprint dans un environnement Scrum. L'environnement de développement est configuré pour afficher les erreurs techniques complètes.