À quel point l'environnement de diffusion doit-il être égal à l'environnement réel?

StackOverflow https://stackoverflow.com/questions/648855

  •  19-08-2019
  •  | 
  •  

Question

La direction a décidé d’utiliser Windows 2008 64 bits avec IIS7 pour la maintenance de notre site Web principal.

Ils souhaitent que le transfert soit effectué sur un serveur Windows 2003 avec IIS6. [Modifier] Oui, ils prévoient le transfert sur 32 bits [Fin de la modification]

Je veux savoir quels problèmes, au-delà des problèmes de sécurité , que je devrais mettre en avant, suggérant que nous options pour le même serveur dans le stockage intermédiaire et dans l'environnement réel.

J'ai lu d'excellents articles tels que this , mais je veux quelque chose que je puisse dire en quelques points

Il est facile pour un développeur expérimenté de comprendre que la mise en scène et les environnements réels doivent être identiques. Mon problème est que j'essaie de l'expliquer aux cadres supérieurs qui semblent avoir déjà pris leur décision ...

[Modifier] @Luke:

Il s’agit essentiellement d’un site Web qui est mis à jour assez souvent. L’ensemble du site doit être mis en scène, testé, avant son déploiement dans l’environnement réel.

Le site doit rester entre les mains du service marketing (non développeurs) et lui demander de vérifier que le site ne présente pas de problème avant le déploiement.

[Edit ++] Le code est ASP.NET, utilisé dans 3 pages de commande client importantes.

Merci,

Ric

Était-ce utile?

La solution

J'espère que ce n'est pas un serveur de transfert Windows 2003 32 bits que vous utilisez pour tester les fonctionnalités d'un serveur de production Windows 2008 64 bits, ou que vous êtes dans un monde de souffrances.

Le serveur de transfert doit être, dans la mesure du possible, l’équivalent du serveur de production, car vous l’utilisez pour répondre à la question "Ce logiciel fonctionne-t-il dans l’environnement de production?" avant de s’engager à le charger dans l’environnement de production.

Répondant à la question "Ce logiciel fonctionne-t-il sur un serveur presque totalement différent de notre serveur de production?" n’est pas utile et, en réalité, vous ne faites que tester et déboguer le logiciel dans un autre environnement, mais dans un environnement que vous n’utiliserez pas réellement. Cela demande plus de travail et au final, vous ne savez toujours pas si cela fonctionne dans votre environnement de production, ce qui est l’intérêt de disposer d’un serveur de transfert en premier lieu.

Autres conseils

Plus l'environnement de transfert correspond au direct, plus le nombre de problèmes rencontrés dans le test est important. Si vous avez un match faible, comme ce que vous avez ici, cela limite le type de bugs qui pourraient être découverts. Par exemple, supposons qu’il existe une incompatibilité avec 2008 64 bits et certains composants du site? Vous ne le trouverez pas avant que vous soyez allé vivre. Cela pourrait être trop tard.

Vous devriez peut-être leur demander ce qu’ils pensent d’un environnement de rassemblement. Expliquez-leur que l'intérêt d'un environnement de transfert est de reproduire au mieux l'environnement de production. Expliquez que si l'environnement de transfert doit être radicalement différent, vous pourriez aussi bien ne pas l'avoir. Ensuite, si vous ne l'avez pas, votre site de production sera utilisé pour les tests. Dites-leur que ce n'est pas vraiment une grosse affaire, mais que le site va casser quelques fois et qu'il y aura peut-être des fuites majeures de sécurité avant que tout ne soit réparé faute de mise en scène adéquate. Je suis sûr qu'ils comprendront.

La règle générale est que vous ne pouvez valider que les modifications qui utilisent des sous-systèmes communs entre stage et live. Si vous ne faites que valider les modifications de copie HTML et que vous pouvez garantir que seul le HTML est transféré d'étape en phase, cela vous donnera probablement une grande assurance que le site fonctionnera en direct.

Vous avez tellement de différences entre stage et live que vous ne pouvez pas valider les modifications de code ou de configuration IIS. Ce sera "pousser et prier" va vivre.

De préférence, vivre et mettre en scène doivent bien sûr être les mêmes technologies (même boîte?). Mais que mettez-vous en scène ici, technologie ou contenu? Si l'environnement de transfert est principalement destiné au contenu, il est possible que les deux serveurs ne soient pas identiques. Toutefois, si vous utilisez la technologie de la mise en scène, vous rencontrerez certainement des problèmes qui ne fonctionnent pas correctement. Je suppose que si le type avec le portefeuille est prêt à en être responsable, allez-y ...

Expliquez-le à l'entreprise en termes de risque et d'argent.

  • Le risque que votre site rencontre des problèmes lors du déploiement de la production est connu et non négligeable.
  • Le coût de la suppression de votre site en raison d’un problème imprévu est extrêmement élevé.
  • Le coût potentiel du temps nécessaire à votre équipe de support technique et à vos développeurs pour identifier les problèmes chaque fois qu'ils se produisent en production, car votre environnement de stockage intermédiaire ne répond pas à la bonne question (" Mon logiciel fonctionnera-t-il en production? " ) est élevé et exacerbe l'ancien.
  • La nuit tardive et les niveaux de stress élevés que peuvent entraîner des déploiements répétés peuvent conduire à une équipe malheureuse et improductive, ce qui peut entraîner des taux de rotation trop élevés.
  • Le coût de l’atténuation de tout cela par l’achat de matériel est relativement faible et de nombreux ingénieurs réputés le recommandent comme meilleure pratique.
Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top