Dans quelle mesure les environnements de PreProd et Prod devraient-ils être similaires?

Je viens récemment de travailler sur un projet et lors de la sortie, nous avons réalisé que cela ne fonctionnait pas en Production. Cela fonctionne dans tous les autres environnements, mais comme nous avons une équipe de publication distincte et que nous ne pouvons pas configurer les serveurs et les environnements nous-mêmes, nous n'avons aucune visibilité sur la configuration.

Nous soupçonnons que Prod dispose de certaines autorisations utilisateur dans son compte ou dans les paramètres IIS qui sont différents, nous travaillons donc bien maintenant.

Je pense donc que tout cela a été une expérience d'apprentissage pour moi et je ne veux pas que la même chose se répète. Je voudrais demander, dans quelle mesure ces environnements devraient-ils être différents? J'ai toujours pensé que PreProd devrait être une copie identique à l'environnement Prod en utilisant une copie de la même base de données, en utilisant une copie du même compte utilisateur, devrait être installé sur les mêmes serveurs, etc.

Mais jusqu'où dois-je aller? Si le site Web est orienté vers l'extérieur, PreProd doit-il être orienté vers l'extérieur? Que faire si le site Web contient des composants qui ne nécessitent pas de compte d'utilisateur ou de mot de passe pour naviguer? Est-il toujours acceptable de l'exposer au monde extérieur?

Vous devriez certainement tester dans un environnement identique à vos serveurs de production dans la mesure du possible. Si vous ne le faites pas, vous ne testez pas ce que vos clients utiliseront. Si rien d'autre, vous avez besoin d'un tel environnement pour tester les rapports de bogues.

Évidemment, il y aura des choses que vous ne voudrez pas identiques - les liens avec les systèmes de paiement viennent à l'esprit, mais ceux-ci devraient être moqués comme s'ils étaient la vraie chose . Il y a aussi des choses que vous ne pouvez pas reproduire - l'échelle du système.

Vous voudrez peut-être tester via une URL externe - encore une fois, vous testez ce que vos utilisateurs verront. Le test via une URL externe utilisera également le réseau d'une manière différente de l'utilisation interne du système. Les autorisations (par exemple) joueront un rôle, tout comme la bande passante disponible, les pare-feu, etc. Tous les utilisateurs seront confrontés, mais vous les ignorerez si vous accédez directement au système.

Je ne vois pas de problème avec les composants qui ne nécessitent pas de compte et de mot de passe. S'il n'a pas besoin d'un mot de passe, il n'est pas vital / sensible, s'il est sensible, alors pourquoi n'a-t-il pas de mot de passe?

Je pense que la meilleure pratique pour cela est l'approche Blue Green Deployment, inventée par Jez Humble et David Farley dans leur livre Continuous Delivery et décrite par Martin Fowler dans son article de blog Blue Green Deployment .

La prémisse est très simple. Du post de Martin Fowler:

L'approche de déploiement bleu-vert ... [garantit] que vous disposez de deux environnements de production, aussi identiques que possible. À tout moment, l'un d'eux, disons bleu pour l'exemple, est en direct. Lorsque vous préparez une nouvelle version de votre logiciel, vous effectuez votre dernière étape de test dans l'environnement vert. Une fois que le logiciel fonctionne dans l'environnement vert, vous changez de routeur pour que toutes les demandes entrantes soient dirigées vers l'environnement vert - la bleue est maintenant inactive.

Le déploiement bleu-vert vous offre également un moyen rapide de revenir en arrière - en cas de problème, vous ramenez le routeur dans votre environnement bleu.

Cette approche résoudrait votre problème de ne pas avoir des environnements de pré-production et de production identiques, ainsi que l'optimisation de votre stratégie de déploiement.

Notre environnement de pré-production final est tout simplement l'un des serveurs en direct retirés de l'équilibreur de charge. Nous déployons notre build de préproduction (qui est fondamentalement identique à la build live, à l'exception des chaînes de connexion à la base de données et de quelques autres modifications de configuration) et testons cela. Si cela se passe bien, nous déployons le code en direct, et enfin, si cela se révèle correct, nous renvoyons le serveur à l'équilibreur de charge et déployons le build de production sur les serveurs restants un par un.

Ils doivent être aussi similaires que possible, afin que vous puissiez identifier les problèmes à tout moment dans le système, à l'exception possible d'une incapacité à évoluer. Dans la mesure du possible, la seule différence entre votre environnement de production et l'environnement de pré-production / mise en scène / test serait la taille - je m'attendrais à ce qu'un environnement de production se compose de beaucoup plus de machines dans un environnement à grande échelle. Vous devez même refléter les dédicaces des machines que vous avez, telles que les serveurs de base de données, les serveurs Web, etc.

Cependant, une réplication exacte peut ne pas être possible avec votre budget actuel. Plus il est proche, plus les tests seront efficaces et moins les problèmes se poseront lors d'une poussée vers la production.

Je prends une position différente de celle de ChrisF si cet environnement doit être accessible au public. Je dis que ça ne devrait pas l'être. Je choisirais de courir sur une copie des bases de données réelles, ou au moins une copie d'un sous-ensemble des bases de données réelles et d'un environnement orienté vers l'intérieur. De cette façon, vous pouvez tester des données réelles et réalistes et ne pas vous inquiéter des failles de sécurité conduisant à une fuite. Vous pouvez, bien sûr, aseptiser les données, mais cela pourrait supprimer certaines "données sales" de l'environnement qui pourraient conduire à la découverte d'un défaut dans un système en direct.

Partout où j'ai travaillé dans les banques, les télécommunications, etc., la pré-production était une copie directe de la production, sauf que la base de données datait d'une semaine environ. C'était un processus massif de maintien des données sur la pré-production, mais il était considéré comme essentiel pour les entreprises pour lesquelles je travaillais qui mettaient en œuvre la pré-production.

Dans la section bancaire de l'UA, le gouvernement inflige des amendes aux banques pour défaillance de service. Il n'est pas rare d'entendre parler d'une équipe de développement / test renvoyée pour un incident. La pré-production n'est pas pour chaque entreprise ou processus de développement mais est essentielle pour certains.