Desarrollando en un servidor de producción

Hoy me gritaron por desarrollar una aplicación en un servidor de producción. Cita: " nunca es aceptable desarrollar en un servidor de producción ".

Aquí está la situación.

1. Configuré una instancia de desarrollo: http://example.com:3000
2. La instancia de producción es: http://example.com
3. Completo todo mi trabajo de desarrollo http://example.com:3000y, cuando el cliente está satisfecho con los cambios, los paso a http://example.com.

La aplicación con la que estoy trabajando es una aplicación antigua de Ruby on Rails , y tengo que decir que inicialmente, intenté configurar un entorno de desarrollo local, pero nunca pude hacerlo funcionar. Después de intentarlo por un tiempo, me di por vencido y decidí desarrollarme en el servidor de producción.

De nuevo, ¿soy un idiota? Probablemente sí, pero he estado haciendo desarrollo web durante un par de años y nunca me he encontrado con una situación como esta. ¿Quién tiene razón y por qué?

Solía ​​desarrollar en el servidor de producción. Puede funcionar bien, pero no es aconsejable por al menos dos razones:

1. El código de desarrollo puede causar bucles infinitos, pérdidas de memoria u otros problemas que bloqueen la CPU, consuman toda la memoria o que de otra manera afecten al servidor de una manera que afectará su código de producción.
2. Si necesita realizar cambios en los componentes del entorno del servidor como parte de su trabajo de desarrollo, como la versión de Ruby o MySQL o lo que sea, estará en apuros.

Como han dicho otros, la codificación en el entorno PROD expone a sus usuarios a sus errores. Incluso si ha comenzado una instancia diferente, aún tiene recursos de hardware compartidos y aún puede acceder a archivos de producción y bases de datos. Y como algunos de los comentarios señalan, si su instancia de Dev es pirateada (por ejemplo, porque olvida borrarla y alguien descubre una vulnerabilidad de seguridad masiva en Rails), ahora tiene una máquina de acceso público con su aplicación actuando como puerta de entrada. Lo cual sería ... desafortunado.

Diferentes empresas tienen diferentes respuestas a esto, pero generalmente se puede desglosar así:

• ¿Se produjo un error?
• ¿Cuánto tiempo haría falta para revertir un cambio (I principalmente el trabajo en C ++, así que deshacer una binaria puede tener significativamente más largo que en Rubí, sobre todo cuando se ha "perdido" el viejo binario y tener que volver a compilar)
• Lo que el efecto del cambio (guía aproximada: atornillar los datos almacenados es por lo mucho peor que no almacenamiento o visualización de datos, que a su vez es peor que no muestra la página en absoluto)
• Si te equivocas y sales por la puerta, ¿alguien sabría lo que has hecho?
• ¿Hubo otra opción de implementación que hubiera evitado / minimizado / detectado el error antes del impacto?

Esto te da el cálculo final:

• ¿Cuánto le habría costado al negocio este error completamente evitable?

Esto es ahora cuánto menos vale toda su estructura de gestión para el tipo que toma las decisiones presupuestarias. Por lo tanto, grita.

Si está trabajando en la página interna "Acerca de nosotros" de la compañía y escribe su propio nombre para que sea L. "Dios", Thomas, un vergonzoso problema de apodo; si está trabajando en la aplicación de compras crítica para el negocio, y termina accidentalmente borrando los detalles de la tarjeta de crédito en la página de inicio ... problema de demanda. Entre esos extremos se encuentran todo, desde la carga incorrecta, la productividad paralizante y todas las demás cosas que pueden alejar a los clientes.

La razón para no permitirlo incluso para la página "Acerca de nosotros" es porque la codificación directamente en producción es adictiva . Empiezas haciéndolo solo para los menores, pero con el tiempo, es mucho más rápido no tener que poner a cero el entorno del DEV.

Más allá de eso, el tamaño del negocio puede tener un gran efecto. En un equipo de dos hombres, cuando algo falla, te inclinas sobre tu hombro y dices "Oi, imbécil, vuelve a ponerlo". En una empresa de 300 personas, debe comenzar a preocuparse por si fue incompetencia o malicia, los gerentes pueden ser considerados responsables de cosas sobre las que no tenían control, etc.

Al final del día, si sigues el procedimiento y te equivocas, verifican qué está mal con el procedimiento. Si evita el procedimiento y se equivoca, ahora es su responsabilidad, incluso si la culpa se extiende un poco. Si quieres tirar los dados depende de ti.

Intenté configurar un entorno de desarrollo localmente, pero nunca pude hacerlo funcionar. Después de intentarlo por un tiempo, me di por vencido y decidí desarrollarme en el servidor de producción.

Sí apoyo las declaraciones para EVITAR el desarrollo en un servidor de producción. Es posible que solo esté justificado hacerlo bajo la PISTOLA, si se trata de una corrección de error tipográfico en el archivo de configuración e insistido por su gerente.

WHY NOT?- Porque, es muy arriesgado y pronto convertirse en un hábito más tarde que te atraparía mucho. Porque los errores / fallas fatales en la producción pueden costar que te despidan de tu trabajo.

Permítanme repetirlo nuevamente, aunque si solicitó corregir errores tipográficos en el productionservidor, primero hágalo Staging. o en otras palabras, pruebe sus cambios, pruébelo y vuelva a probarlo antes de ponerlo en producción.

Esto es algo que sucede a menudo en lugares donde la cultura de "hacerlo rápido y sucio " parece ser una norma.

Editar: el desarrollo en el servidor de producción, como un entorno separado tampoco es aceptable . Cualquier problema causado en su trabajo puede simplemente derribar el servidor de producción y afectar el rendimiento de la aplicación de producción . Como ejemplo, recuerdo un caso en el que hubo un agujero de seguridad, cuando mi compañero de trabajo anterior intentó usar el servidor de producción WinServer 2003 para fines de desarrollo.

Esto es realmente un problema de protocolo. En general, esto no es algo que le gustaría hacer. Desea dejar en paz las máquinas de producción. Pueden contener datos confidenciales y no desea comprometer el rendimiento o la estabilidad de los sitios de producción con un código que no esté preparado para la producción.

Dicho esto, hay momentos en que esto se hace comúnmente. Si se encuentra en una posición en la que está bombeando material publicitario de bajo tráfico o sitios simples de CMS, esto probablemente será un problema menor. Pero si está trabajando en algo con datos sensibles o procesos "críticos para el negocio", realmente no debería arriesgarse a tener código de desarrollo en la misma máquina.

Otra razón importante para no desarrollarse directamente en producción es que una instancia de desarrollo generalmente producirá y mostrará errores detallados y seguimientos de pila. Usted no quiere exponer que para el usuario.

Sí, puede registrarlos en lugar de mostrarlos al cliente, pero eso hace que la depuración sea mucho menos divertida de lo que ya es.

Agregado Abordando su problema secundario de tener problemas con su instancia de desarrollo: He tenido un gran éxito al implementar una VM basada en VirtualBox que duplica nuestro entorno de producción (exclusivo del hardware, por supuesto) con un servidor Ubuntu .

Estoy bastante sorprendido de que nadie haya mencionado la razón más importante todavía, por qué está absolutamente prohibido desarrollar en servidores de producción:

¡No te metas con los datos de producción, lo que puede suceder tan fácilmente!

Un pequeño error en un lugar conduce a problemas gigantescos en otros cálculos y luego, al día siguiente, todos los datos son basura y el cliente está enojado. Esto es mucho, mucho peor que un error en la interfaz de usuario o un pequeño bloqueo aquí y allá.

Para la mayoría de las aplicaciones, el valor reside en los datos y no en las rutinas.

Siempre trato de preguntar a otros desarrolladores cuáles son los procedimientos para la empresa en particular. En general sí, siempre debes:

1. Construir localmente.
2. Empújalo a algún tipo de caja que imite la producción tanto como sea posible para ver si funciona bien allí.
3. Posiblemente lo transfiera a un QA o instancia de certificación para pasar al cliente / equipo de QA para revisar los cambios.
4. Empuje a la producción.

Puede usar recetas Capistrano combinadas con GitHub para manejar todo esto por usted. Si tiene que hacer esto a mano cada vez, puede envejecer rápidamente.

Otro problema con el desarrollo en prod es que, a veces, estas cosas se pierden en el control de código fuente y una versión futura puede deshacer su cambio de solución rápida.

Si está en una empresa que cotiza en bolsa en los Estados Unidos, ni siquiera debería tener acceso a productos por razones regulatorias. En general, en ninguna compañía un desarrollador debe tener acceso a productos (por las resonas indicadas en todas las respuestas, así como posibles razones legales), por lo que su gerente también está equivocado al otorgarle los derechos sobre ese servidor.

Las reglas que usan "siempre" o "nunca" generalmente están mal definidas. Habrá casos extremos donde se justificará romper una mejor práctica. Un consejo mucho mejor será "No toque los servidores de producción a menos que tenga muy buenas razones"

En mi carrera, he encontrado solo dos razones para cambiar el código en los servidores de producción:

1. Errores o comportamientos que solo ocurren allí y no son reproducibles en el entorno de desarrollo. Estos son raros, pero pueden ser muy molestos y difíciles de encontrar.

2. Corrección directa de errores críticos que simplemente no puede permitirse esperar para pasar por el proceso de implementación normal si lleva más de unos minutos. Después de esto se ha borrado con la administración. Si tienes suerte, solo deberías tener unos pocos para toda tu carrera.

Es mejor dejar ambos a los desarrolladores senior que conocen los sistemas íntimamente.