¿Estándares de denominación de entorno en el desarrollo de software?

Mi proyecto actualmente sufre problemas de nomenclatura ambiental. Diferentes personas tienen diferentes suposiciones sobre qué entornos deben nombrarse o qué designan los nombres, y está causando confusión al discutirlos. He investigado un poco y no he encontrado ningún estándar por ahí.

Los términos incluyen "Local", "Sand", "Dev", "Test", "User", "QA", "Staging" y "Prod" (además de algunos más sobre los que han preguntado diferentes personas)

No busco solo opiniones, aunque si hay una que "todos" tienen, la tomaré; estoy tratando de encontrar definiciones avanzadas por algún tipo de autoridad, incluso si no es oficial.

Aquí están los entornos que usamos actualmente:

1. Entorno en la PC del desarrollador
2. Entorno compartido donde los desarrolladores cargan directamente el código para autocomprobar
3. Entorno compartido donde las personas de control de calidad prueban los estándares y la funcionalidad
4. Entorno compartido donde los solicitantes del proyecto aprueban el código completado y verificado por QA
5. Entorno que refleja el entorno final como una verificación final y para prepararse para la implementación
6. Entorno final donde el código está en uso

Sé lo que me llamo ellos, pero ¿hay algún tipo de norma sobre esto? Gracias por adelantado.

No solo no hay un estándar fijo, sino que realmente no hay un patrón fijo. Las dependencias entre lo que está construyendo y la escala a la que puede permitirse replicarlo determinarán cómo debe ser esto de un tipo de proyecto a otro.

He trabajado con tan solo un entorno y hasta 13.

En la secuencia que describe, generalmente los vería nombrarlos algo así como

1. local o dev si no usa dev en el siguiente paso
2. dev o integración si esta es la primera implementación después de las fusiones
3. prueba o control de calidad
4. uat o aceptación o QA si no usó QA en el paso 3
5. pre-prod, puesta en escena o rendimiento si es un paso de rendimiento para la aprobación final
6. pinchar

Mi consejo sería acordar los nombres, propósitos y criterios para ingresar y salir de cada producto o proyecto, cuando se dé cuenta de que necesita un 7º entorno o solo necesita 5 en un caso por alguna otra razón en el futuro, vuelva a discutir con el equipo.

Si tiene miembros del equipo que están obsesionados con la semántica de los nombres, siempre puede soltar los nombres y referirse a ellos como prod menos seis a prod menos uno con un gerente que simplemente se negó a dejar que su personal de control de calidad pruebe en un entorno que no fue llamado "QA"

Si desea nombrar los servidores en sí, generalmente sugiero nombrarlos según la autoridad bajo la cual están. Por lo general, esto es algo así como:

• los desarrolladores pueden manipular las máquinas de desarrollo
• Los desarrolladores no pueden manipular las máquinas de control de calidad, pero tampoco son supervisadas por el soporte de producción
• las máquinas de producción son el negocio de soporte de producción

la mayoría de las personas terminan usando ese tipo de nombres como prefijos o sufijos para que tengas una cadena como "devsqllweb" "qasqlweb" "prodsqlweb" o algo así.

Supongo que viniendo de una industria más estructurada y regulada, la opción de nombrar un servidor es un lujo que no tengo. Nuestros servidores se nombran de acuerdo con la política de TI de nuestra empresa, por lo que el nombre de host real de la máquina no es algo que podamos controlar.

Lo que hemos hecho se ha ido por la ruta de los nombres y alias de DNS. La regla es que la primera letra identifica el rol general del servidor en el proceso de desarrollo (la zona)

• p = producción
• d = desarrollo
• s = puesta en escena
• t = prueba

Luego tenemos un nombre máximo de tres letras para identificar el papel de la máquina

• aplicación = aplicación
• db = base de datos
• web = frontend / web
• kas = almacenamiento en caché

Seguido de un número si hay varias máquinas en esa zona. Publicamos esto en el servidor de documentación interno y lo proporcionamos como parte de cualquier documentación nueva para proyectos y durante la etapa de arranque.

Estos son para aquellos servidores que forman parte del proceso de desarrollo. Para las máquinas de soporte tenemos una política más liberal; y cuando tenemos que aprovisionar un nuevo servidor auxiliar, pedimos a los equipos de desarrollo que propongan un nombre que prefieran.

Esto ha llevado a algunos interesantes, mis dos favoritos son cerberus (proxy interno) box y hades (servidor de documentación / intranet)

Estoy seguro de que esta no es una buena práctica, pero esto es lo que usamos y funciona para nosotros.

No hay una definición fija. Hay algunos que son utilizados por la práctica común (que ha enumerado). Si quieres darle a cada entorno el nombre de un personaje en Toy Story, puedes (aunque no lo recomendaré).

Lo que haría sería crear un glosario para la empresa, en el que daríamos los nombres que quisiéramos usar.