Normes de dénomination de l'environnement dans le développement de logiciels?


15

Mon projet souffre actuellement de problèmes de dénomination de l'environnement. Différentes personnes ont des hypothèses différentes quant aux environnements à nommer ou à la désignation des noms, et cela crée de la confusion lors de leur discussion. J'ai fait un peu de recherche et je n'ai trouvé aucune norme.

Les termes incluent "Local", "Sand", "Dev", "Test", "User", "QA", "Staging" et "Prod" (plus quelques autres que différentes personnes ont demandé)

Je ne cherche pas seulement des opinions, mais s'il y en a une que "tout le monde" a, je la prendrai - j'essaie de trouver des définitions avancées par une sorte d'autorité, même si ce n'est pas officiel.

Voici les environnements que nous utilisons actuellement:

  1. Environnement sur le PC du développeur
  2. Environnement partagé où les développeurs téléchargent directement le code pour l'auto-test
  3. Environnement partagé où les normes et les fonctionnalités sont testées par les gens de l'AQ
  4. Environnement partagé où le code rempli et vérifié par l'AQ est approuvé par les demandeurs de projet
  5. Environnement qui reflète l'environnement final en tant que vérification finale et pour préparer le déploiement
  6. Environnement final où le code est utilisé

Je sais comment je les appellerais, mais existe-t-il une sorte de norme à ce sujet? Merci d'avance.


Merci. Je n'étais pas au courant de cette SE. Je savais qu'il n'appartenait pas à ServerFault ou SuperUser, mais je n'avais jamais entendu parler de programmers.se auparavant.

Je l'ai signalé pour un déménagement, donc idéalement, il devrait trouver son chemin vers le bon site.
Ricardo Altamirano

Selon la portée du projet, vous pouvez avoir moins ou plus d'environnements.
Yusubov

Réponses:


11

Non seulement il n'y a pas de norme fixe, mais il n'y a vraiment pas de modèle fixe. Les dépendances entre ce que vous construisez et l'échelle à laquelle vous pouvez vous permettre de le reproduire vont dicter à quoi cela doit ressembler d'un type de projet à un autre.

J'ai travaillé avec aussi peu qu'un environnement et jusqu'à 13.

Dans la séquence que vous décrivez, je les voyais généralement nommés quelque chose comme

  1. local ou dev si vous n'utilisez pas dev à l'étape suivante
  2. dev ou intégration si c'est le premier déploiement après les fusions
  3. test ou QA
  4. uat ou acceptation ou QA si vous n'avez pas utilisé QA à l'étape 3
  5. pré-prod, mise en scène ou performance s'il s'agit d'une étape de performance pour l'approbation finale
  6. prod

Mon conseil serait de convenir des noms, des objectifs et des critères pour entrer et quitter chacun pour chaque produit ou par projet, puis lorsque vous réalisez que vous avez besoin d'un 7e environnement ou que vous n'en avez besoin que de 5 dans un cas pour une autre raison à l'avenir, discutez à nouveau avec l'équipe.

Si vous avez des membres de l'équipe qui sont accrochés à la sémantique des noms, vous pouvez toujours laisser tomber les noms et les désigner comme prod moins six à prod moins un avec un gestionnaire qui a simplement refusé de laisser son personnel QA tester sur un environnement qui n'a pas été nommé "QA"

Si vous cherchez à nommer les serveurs eux-mêmes, je suggère généralement de les nommer en fonction de l'autorité sous laquelle ils se trouvent. Habituellement, cela va quelque chose comme:

  • les machines de développement peuvent être manipulées par les développeurs
  • Les machines d'assurance qualité ne peuvent pas être manipulées par les développeurs mais ne sont pas non plus surveillées par le support de production
  • les machines prod sont le métier de prod support

la plupart des gens finissent par utiliser ces sortes de noms comme préfixes ou suffixes pour que vous ayez une chaîne comme "devsqllweb" "qasqlweb" "prodsqlweb" ou quelque chose comme ça.


Vous dites essentiellement la conclusion à laquelle je suis arrivé. J'espérais qu'il y avait une sorte de norme pour que je puisse résoudre la situation sans fixer des normes essentiellement arbitraires. Mon problème réside dans le fait que notre structure d'environnement "principale" a moins d'environnements que ce projet sur lequel je travaille (donc je ne peux pas simplement refléter ce que nous utilisons normalement) - et mon projet a beaucoup de consultants de divers endroits, ce qui signifie non on a les mêmes normes. Je vais laisser cette question ouverte pendant quelques heures de plus pour voir si quelqu'un d'autre va sonner, mais c'est la réponse que j'avais peur.
Marcus_33

J'ai vu des normes pour cela. Ce sont des types de normes qui sont soit des opinions, soit très spécifiques à une certaine situation, malheureusement.
Bill

2

Je suppose que venant d'une industrie plus structurée et réglementée, l'option de nommer un serveur est un luxe que je n'ai pas. Nos serveurs sont nommés conformément à la politique informatique de notre entreprise - le nom d'hôte réel de la machine n'est donc pas quelque chose que nous pouvons contrôler.

Ce que nous avons fait, c'est la route des noms et des alias DNS. La règle est que la première lettre identifie le rôle général du serveur dans le processus de développement (la zone)

  • p = production
  • d = développement
  • s = mise en scène
  • t = test

Ensuite, nous avons un nom de trois lettres maximum pour identifier le rôle de la machine

  • app = application
  • db = base de données
  • web = frontend / web
  • kas = mise en cache

Suivi d'un chiffre s'il y a plusieurs machines dans cette zone. Nous le publions sur le serveur de documentation interne et le fournissons dans le cadre de toute nouvelle documentation pour les projets et pendant la phase d'amorçage.

Ce sont pour les serveurs qui font partie du processus de développement. Pour les machines de support, nous avons une politique plus libérale; et lorsque nous devons approvisionner un nouveau serveur auxiliaire, nous demandons aux équipes de développement de trouver un nom qu’elles préfèrent.

Cela a conduit à quelques intéressantes, mes deux préférées sont la boîte et les hades cerberus (proxy interne) (serveur de documentation / intranet)

Je suis sûr que ce n'est pas une bonne pratique, mais c'est ce que nous utilisons et cela fonctionne pour nous.


1

Il n'y a pas de définition fixe. Il y en a quelques-uns qui sont utilisés par la pratique courante (que vous avez énumérés). Si vous voulez donner à chaque environnement le nom d'un personnage dans Toy Story, vous pouvez (ne le recommanderez pas, cependant).

Ce que je ferais, c'est créer un glossaire pour l'entreprise, dans lequel nous donnerions les noms que nous voudrions utiliser.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.