Normalmente, instalamos VS.NET en nuestro servidor de producción, para solucionar problemas fácilmente con nuestro producto, si es necesario.¿Es seguro y aceptable instalar VS.NET en su servidor de producción?
¿Es esta una buena o mala idea?
La depuración y el desarrollo deben realizarse en un entorno "seguro", algo que no es crítico para la misión. Por ejemplo, debe tener un servidor de desarrollo y/o QA que use para el desarrollo y la depuración.
EDIT: Su servidor de QA debe reflejar su servidor de producción, para que pueda depurar en un entorno similar, si no idéntico, a su entorno de producción.
Ambos. Una de las ventajas es que a veces puede hacer que diagnosticar problemas sea más fácil. Una de las desventajas es que a veces la instalación puede romper una aplicación web que funciona. Solo lo haría si tuviera que hacerlo.
Editar: otra desventaja potencial de esto ocurre cuando un compañero de trabajo decide depurar un proceso en vivo en el servidor de producción, detiene la aplicación en un punto de interrupción y luego se va a la cama sin darse cuenta de que ha dejado la aplicación no disponible. Sí, esto me ha pasado a mí.
Depende de cómo lo está usando. La mayoría del trabajo pesado para el que está diseñado no debería ser necesario en un servidor de producción. Normalmente instalo Notepad ++ en el servidor de producción para editar xml, archivos de configuración, etc. Diría que si quieres instalar VS, adelante.
Creo que está hablando de usarlo para la depuración. Notepad ++ no es muy bueno en eso. – MusiGenesis
La manera recomendada es tener un espejo del servidor de producción para fines de prueba/depuración. Para mantener el espejo actual, debe instalar todas las actualizaciones de la aplicación en ambos servidores al mismo tiempo y hacer una copia de seguridad/restaurar la base de datos de producción en el mirror cada noche o bajo demanda.
Todavía hay algunos inconvenientes como el error que solo ocurre bajo una carga pesada. En este caso, necesita algún tipo de registro para rastrear errores. También es posible que necesite comprar una licencia adicional de componentes de terceros para instalarla en el espejo de producción.
Nunca haría nada directamente en el servidor de producción que requiera Visual Studio. Es demasiado arriesgado realizar un cambio en la producción que no vuelva a la base del código y, por lo tanto, al control de la versión. Eventualmente, terminará reintroduciendo un error que pensó que había resuelto porque solo lo cambió en el servidor de producción. Ocasionalmente, actualizaré los archivos mark up o XML en el servidor de producción, pero solo después de haber realizado el cambio en el desarrollo y haberlo probado en el cuadro QA, y solo cuando no haya un código real involucrado.
Por supuesto, depende del producto y de lo que está depurando. En términos generales, debe intentar evitarlo, pero hay casos en los que no se puede duplicar exactamente un escenario en un servidor de prueba y podría ser útil adjuntar un depurador a un proceso en ejecución para reducir rápidamente un problema. es decir, si está ejecutando un servidor MMORPG, y hay un error intermitente que ocurre bajo ciertas condiciones de carga, puede pasar semanas o meses tratando de resolverlo desde archivos de registro y/o conexiones simuladas en un servidor de prueba, o puede adjuntar un depurador mientras el problema está ocurriendo en tiempo real en el servidor de producción, y resuélvelo en una hora.
Tiendo a tratar esto como un caso excepcional sin embargo, y hacer la mayor depuración del servidor de producción como sea posible y razonable.
No creo que sea una buena idea.Su código debe tener suficiente registro para que, si hay un problema en la producción, puede volver atrás de los registros y determinar qué sucedió, corregirlo en un entorno de desarrollo y luego probarlo en un entorno de preparación/prueba antes de pasar a producción.
En el lugar donde trabajo, los desarrolladores no tienen permitido el acceso a ningún entorno de producción, que es manejado por los equipos de servidor/red, pero eso se debe a que es un gran negocio. Para las empresas más pequeñas, los desarrolladores tendrán acceso, pero eso no significa que deba usarlo para la depuración.
Eche un vistazo a la serie Production Debugging de Sasha Goldshtein en su blog. Él tiene algunos tutoriales geniales y screencasts sobre lo que se puede hacer para depurar sin Visual Studio.
Realmente depende de si acepta el riesgo de que la instalación trae consigo:
También debe preguntarse qué es lo más difícil con la depuración de la cuestión sin VS en el servidor:
Eso definitivamente no es aceptable. En primer lugar, para la depuración siempre puede usar las herramientas de depuración para windows/windbg. También es compatible con la depuración de .NET (SOS/son of strike) y con una hoja de trucos no es tan difícil de usar. Windbg puede ejecutarse desde un dispositivo USB sin instalación.
En segundo lugar, y la causa más importante: cada vez que instala cualquiera de las versiones más recientes de VS, registra su depurador para el modo interactivo **: aparece un cuadro de mensaje cuando se produce una excepción. Necesita editar manualmente el registro para volver al comportamiento predeterminado después de la instalación, y nadie lo recuerda.
No lo hagas. Hay mejores formas de diagnosticar problemas.
Woah ... ¿qué es esto? :) ¿Cómo evito que eso suceda, nunca he visto eso, y tengo VS.NET instalado en producción ahora. – Jason
En general, no se considera una "Mejor práctica" para instalar Visual Studio en servidores de producción. Esto puede introducir riesgos de seguridad, pero una gran preocupación que tengo es el rendimiento. Visual Studio utiliza una gran cantidad de recursos y ejecutar su depuración allí puede afectar significativamente la perforación de las aplicaciones de producción.
Creo que el "si no es idéntico" es fundamental, aquí. Los errores que ocurren en un solo servidor no son infrecuentes en mi mundo, por razones que están fundamentalmente fuera de mi control. Si mis elecciones utilizan VS o si deseo poder reproducir el error en el servidor de QA, me voy con VS. – MusiGenesis
Pero VS no es su único depurador. Vea algunas de las respuestas de otras personas sobre alternativas para tener Visual Studio en el servidor. –
Aún puede depurar código que se ejecuta en un servidor de producción sin instalar Visual Studio en el servidor. Consulte el Depurador remoto (http://msdn.microsoft.com/en-us/library/bt727f1t.aspx) –