Staging environment

Le terme staging environment (en français : environnement de simulation) désigne un environnement serveur permettant de tester des sites web et des applications logicielles dans des conditions les plus proches possibles de la réalité. Un environnement de simulation se compose d’un matériel semblable à la variante de production préparant la version finale (release). Pendant la phase de simulation, on accède déjà à des sections de la base de données et il peut arriver qu’un certain nombre d’utilisateurs disposent d’un accès privilégié afin de tester les fonctions. Il s’agit ici de simuler le comportement d’un système lorsqu’il est testé indépendamment de l’environnement de développement.

Informations générales sur le sujet

La simulation fait partie des tâches inhérentes à la plupart des projets de développement. Un environnement de simulation est une partie intégrante de ce que l’on appelle le processus de déploiement comprenant la mise en service d’applications web et de solutions de logiciels compte tenu de l’infrastructure. On différencie les étapes de travail et de développement et les systèmes et environnements correspondants. Il existe généralement un environnement serveur propre pour chaque étape du développement.

Cela ne doit pas forcément être un serveur physique, au vu des coûts souvent élevés. Pour la simulation, un serveur virtuel est souvent suffisant ; ce dernier est hébergé sur le serveur fournissant également le site web – mais est protégé par une sandbox. Les systèmes de développement et de production doivent être clairement différenciés afin d’éviter d’éventuels conflits dans la pratique ainsi que des erreurs durant la migration des banques de données.

Fonctionnalité

Pour les projets petits à moyens dans le développement web, il est normal de différencier la simulation de développement et la production. Il existe également dans certains cas un environnement test (testing environment), qui se trouve entre le développement et la simulation. Cela est cependant réalisé uniquement pour de très grands projets, les coûts étant extrêmement élevés. Les termes "dev, qa, staging, production" se sont par ailleurs imposés chez les anglophones.

• Dev (Development) : il s’agit de la version de travail (working copy) du logiciel ou de l’application web se trouvant soit sur un serveur sécurisé soit sur un ordinateur local. Les développeurs peuvent procéder à des modifications du code source et télécharger des fonctionnalités individuelles. Étant donné que la version de travail est souvent exploitée avec des compilateurs, des outils de test et de débogage, cette dernière ne fonctionne uniquement qu’au sein de cet environnement. Les développeurs disposent souvent d’une base de données réduite pour vérifier des fonctions en particulier. Pour le développement d’une boutique en ligne, une partie du catalogue de produits peut servir à pouvoir transférer la méta-structure des données comme les champs pour le prix, la disponibilité ou encore différentes variantes de produits. Lorsque plusieurs développeurs travaillent sur des gros projets, ils utilisent souvent un système de contrôle de version comme Git, Mercurial ou Subversion pour synchroniser les modifications et les mises à jour.
• QA (Quality and Assurance) : cet environnement optionnel sert à vérifier si les applications contiennent des bugs ou si des erreurs se retrouvent dans le code, sans que cette étape de travail ait un quelconque impact sur l’environnement de développement. Si une personne est par exemple en train de tester une fonction et qu’un autre procède à des modifications sur cette même fonction, le système ne serait alors plus fonctionnel. C’est pourquoi les deux étapes de travail sont séparées l’une de l’autre. La vérification qualité (QA) sert cependant aussi à assurer la sécurité du système. Des équipes entières sont souvent utilisées, ces dernières reçoivent un accès au système – comme pour un test bêta, seulement sans utilisateurs réels.
• Staging : aussitôt toutes les erreurs rectifiées dans l’application, la copie de travail du code source peut migrer dans l’environnement de simulation. Cette version est le « candidat » pour le lancement de l’application. Généralement, l’environnement de simulation est identique à celui de production, si bien que le matériel et les logiciels ne présentent pas de grandes différences lors de l’utilisation de l’application. Pour finir, cela a aussi pour objectif de vérifier la connectivité au sein de l’ensemble du système : par exemple l’accès à la base de données et l’interaction avec la périphérie. Étant donné que la performance dépend beaucoup de l’environnement, les temps de chargement et autres critères de performance sont aussi examinés lors du staging. Lorsque l’assurance qualité est supprimée – et cela est le cas dans la plupart des projets – les tests se font avec le staging. Dans ce cas-là, le staging est en quelque sorte la répétition générale, avant que l’application migre vers l’environnement de production.
• Production : l’environnement de production est idéalement une copie conforme de l’environnement staging. Dans la pratique, cela n’est certes pas toujours possible, mais le hardware et le software sont censés autant l’un que l’autre être très semblables aux composants utilisés dans le staging. Ceci est la seule manière d’exclure les conflits. À cette étape, plus aucune modification n’est faite par les développeurs car l’ancienne copie de travail du code source se trouve déjà sur le serveur en ligne. Le code source a pu être publié car ce dernier a été largement testé et amélioré au cours des différents environnements.

Signification pour la programmation

Les environnements staging sont utilisés la plupart du temps seulement au niveau de l’entreprise. Plus le nombre de développeurs travaillant sur une application est élevé, plus le risque d’un crash du système et d’une perte des données seront importants, et cela coûte du temps et de l’argent. C’est pourquoi les différentes étapes du développement sont vérifiées de manière individuelle. Pour les projets les plus petits, les systèmes de développement et de production sont isolés afin d’économiser au niveau de la mise à disposition des ressources.

En effet, les systèmes de staging nécessitent un grand nombre de ressources : il est nécessaire d’obtenir le hardware qui se doit d’être similaire au système de production. Le système doit être configuré et implémenté avec les données nécessaires. C’est seulement à ce moment-là qu’il atteint son objectif : simuler le système de production afin de pouvoir tester l’application dans des conditions les plus réelles possible.