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

Navega tus respuestas
13

Mi proyecto sufre actualmente de problemas de nombres de entorno. Diferentes personas tienen diferentes suposiciones en cuanto a los entornos que deben nombrarse o lo que 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" (más algunos más que han preguntado otras personas)

No estoy buscando opiniones justas, aunque si hay una que dice que "todo el mundo" tiene que tomarla, 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 el código directamente para realizar una prueba automática
  3. Entorno compartido donde las personas de control de calidad prueban los estándares y la funcionalidad
  4. Entorno compartido donde los solicitantes de proyectos aprueban el código completado y verificado por el control de calidad
  5. Entorno que refleja el entorno final como una comprobación final y para prepararse para la implementación
  6. Ambiente final donde el código está en uso

Sé lo que yo los llamaría, pero ¿hay algún tipo de estándar en esto? Gracias de antemano.

    
pregunta Marcus_33 26.06.2012 - 15:03

3 respuestas

7

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

He trabajado con tan solo un entorno y tantos como 13.

En la secuencia que describe, normalmente los vería nombrados algo así como

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

Mi consejo sería acordar los nombres, propósitos y criterios para entrar y salir de cada producto o proyecto, cuando se dé cuenta de que necesita un séptimo entorno o solo necesita 5 en un caso por algún otro motivo en el futuro. discutir de nuevo con el equipo.

Si tiene miembros del equipo que se están quedando atascados en la semántica de los nombres, siempre puede dejarlos caer y referirse a ellos como prod minus six a prod minus one con un gerente que simplemente se negó a dejar que su personal de control de calidad probara en un entorno que no fue nombrado "QA"

Si busca nombrar a los servidores, generalmente sugiero nombrarlos por la autoridad bajo la cual están. Por lo general, esto va algo como:

  • las máquinas de desarrollo pueden ser manipuladas por los desarrolladores
  • Las máquinas de control de calidad no pueden ser manipuladas por los desarrolladores, pero tampoco son supervisadas por el soporte de producción
  • las máquinas prod son el negocio de soporte técnico

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

    
respondido por el Bill 26.06.2012 - 16:54
2

Supongo que desde 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 ha sido la ruta de los nombres y alias de DNS. La regla es que la primera letra identifica la función general del servidor en el proceso de desarrollo (la zona)

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

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

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

Siguiendo con 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 proporcionar un nuevo servidor auxiliar, pedimos a los equipos de desarrollo que propongan el nombre que prefieran.

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

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

    
respondido por el Burhan Khalid 26.06.2012 - 16:49
1

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

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

    
respondido por el Miyamoto Akira 26.06.2012 - 16:29

Lea otras preguntas en las etiquetas

Configuración de usuario de un script de shell. ¿Mejores prácticas? ¿Por qué se necesita el patrón Repository en NHibernate?