¿Sería malo tener las cosas configuradas para que MySite.com esté en producción y test.MySite.com es prueba? Ambos corriendo de la misma máquina. El sitio no recibe mucho tráfico.¿Es malo tener sus entornos de prueba y producción en la misma máquina?
ACTUALIZACIÓN
Estoy hablando de una aplicación Web ASP.NET que se ejecuta en un servidor Windows.
Sí, es una mala idea.
Supongamos que su código de prueba tiene un error que consume toda la memoria/cpu/espacio en disco? Entonces su sitio de producción se cae.
Tenga máquinas separadas para producción y prueba, y use DNS para señalar las URL a cada una.
Editar (más puntos):
Si los sitios comparten una máquina, que comparten una dirección IP, por lo que cuando se utiliza una dirección IP para acceder a un sitio, que no se sabe si está en producción o prueba.
Al compartir la misma máquina, la implementación puede ser complicada, debe tener especial cuidado de no implementar código no probado en la producción (más fácil de hacer, ya que ambos viven en la misma máquina).
Las consideraciones de seguridad para la producción y la prueba deben ser independientes; este tipo de configuración lo hace más difícil.
Buen punto. ¿Tienes más? Estoy tratando de preparar una lista de peligros potenciales para mi jefe. –
Es una mala idea. Cuando tiene una nueva característica no probada, puede matar el sitio de producción.
¿Es un problema el cumplimiento de cualquier tipo de norma? En general, desea que los desarrolladores tengan un gran acceso a los entornos de prueba para que puedan resolver los problemas. Sin embargo, no siempre es una buena idea (o incluso permitida) para los desarrolladores tener el mismo nivel de acceso a los sistemas de producción.
No por el momento, pero eso es algo que trato de cambiar. Ahora mismo es gratis para todos. Dev box directamente a la producción. ¿Qué tipo de estándares hay para que cumplamos? –
@Abe Miessler: Hay todo tipo de estándares poco conocidos para diferentes industrias, así como algunas grandes. Por ejemplo, si alguna vez toma información de tarjeta de crédito, entonces el cumplimiento de PCI se vuelve muy importante. – David
Sería muy difícil probar si las actualizaciones del entorno (nueva versión de php/perl/python/apache/kernel/whatever) con prueba y producción en la misma máquina.
Excelente punto. En realidad nos encontramos con esto en este momento ... –
En teoría, sí. Al desarrollar, hay muchas cosas que podrían salir mal, como se mencionó en @Oded. Al tener un servidor web dedicado ejecutando su sitio principal, usted evita la complejidad de tener bases de datos duplicadas, hosts virtuales, etc. Sin embargo, ciertamente puede hacer que test.mysite.com esté disponible públicamente.
Como cliente, muchas veces, lo primero que hago es visitar el sitio web de una empresa. Si el sitio es inaccesible, incluso brevemente, parece poco profesional y pierdo interés rápidamente. ¡No quiere perder negocios porque era demasiado barato para comprar una computadora adicional!
Edit: Veo por sus comentarios anteriores que este es de hecho un servidor de negocios. Respuesta actualizada
Como su pregunta no es específica de la plataforma, intentaré responder de forma general. También me referiré solo a la parte de la "misma máquina" de su pregunta, ya que el "nombre de dominio" debería ser muy fácil de cambiar ... si se han tomado todas las precauciones comunes.
Lo que realmente necesita es aislar los entornos. Dependiendo de la tecnología utilizada, eso puede significar "máquinas separadas" o no.
Como ejemplo, muchos bancos pequeños y medianos en el mundo ejecutan sus sistemas críticos en un mainframe. No es inusual que una de esas bestias cueste (periféricos y todo) seis figuras. Algunos de ellos optaron por tener máquinas separadas y más pequeñas para el desarrollo y las pruebas, mientras que otros ejecutan cientos de entornos (a veces como máquinas virtuales) en la misma máquina. El detalle complicado es que el hardware y SO del mainframe proporcionan un aislamiento real y consistente entre esos entornos, asignando discos, CPU, canales de comunicación, credenciales, bibliotecas, módulos de sistema operativo, bases de datos, etc., basados en una política estricta que puede ser tan granular como quieras
El problema con muchas otras plataformas es que encontrar la forma de aislar los entornos depende de usted, mientras que en una plataforma de dinosaurios se proporciona por la gracia de HAL.
HTH!
"Bueno, mal, soy el tipo con la pistola". - Ceniza
Malo es realmente una gama. Puede ser en cualquier lugar entre la sustitución de las placas base con el poder enchufado y las manos mojadas, o el uso de nombres de variables excesivamente cortos. Lo que realmente quieres saber es cuáles son las compensaciones. Obviamente, conoce algunos de los beneficios o no estaría pensando en utilizar el servidor de producción para las pruebas.
El gran problema es que el código de prueba se ejecuta en un entorno compartido con producción. Si no hay un entorno limitado (límites de proceso, límites de memoria, límites de disco, sistema de archivos chroot, etc.), corre el riesgo de afectar al servidor de producción, algo va mal en las pruebas. Puede accidentalmente duplicarse a sí mismo al consumir todo un recurso en particular. Puede eliminar accidentalmente el sitio de producción. Alguien puede pensar que está bien hacer una prueba de carga. Si está bien con tomar esos riesgos, entonces puede continuar y ejecutar su aplicación de prueba en el servidor de producción.
BTW: Es malo.
Pregunta para el equipo de desarrollo detrás de Stack Overflow! :) –
De una empresa en esta situación, mi amigo Max dijo una vez, "El problema no era que no tenían un sistema de prueba, ¡lo que no tenía era un sistema de * producción *!" –
+1 Voy a robar esa cita. –