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

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.

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.

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.

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.