Desarrollando en un servidor de producción

35

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é?

luk3thomas
fuente
46
La única réplica válida sería "tener un servidor de producción que no se pueda reproducir en el desarrollo no es aceptable, nunca".
Blrfl
49
Para mí, el verdadero problema aquí es que tiene un sistema de producción en el que no tiene idea de qué está funcionando o cómo está configurado. ¿Qué haría si su máquina de producción fallara, perdiendo todos sus datos? Si no puede configurar un entorno de desarrollo adecuado ahora, ¿qué hará cuando esa sea su única opción?
Greg Hewgill el
@GregHewgill, sí, ese es un buen punto
luk3thomas el
25
Greg tiene razón, si no tiene suficiente información sobre la aplicación para reproducir el entorno en una máquina de desarrollo, entonces no solo no debe desarrollar y probar en la máquina de producción, ni siquiera se le debe permitir el acceso para implementar en esa máquina. Claramente estabas equivocado, pero le habría gritado a tu jefe por darte acceso en primer lugar antes de que entendieras completamente lo que estabas haciendo.
maple_shaft
3
Si no puede configurar el entorno de desarrollo local, no debería desarrollarlo nunca.
Jas

Respuestas:

58

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.
Jacob Terry
fuente
1
Sí, ese es un buen punto. Cuanto más lo pienso, ustedes son totalmente correctos.
luk3thomas
66
Hay un tercer problema: la seguridad. ¿Qué sucede si alguien escanea el servidor de producción y descubre su aplicación (de desarrollo) y, como resultado, compromete la aplicación de producción? Nuevamente, si bien este no es un escenario probable, eso es más o menos lo que todos dicen después de que un servidor o sistema se ha visto comprometido.
Marco
El infame problema del bucle infinito ...
Mansuro
3
@Marco En realidad, eso es muy probable si el servidor es de acceso público. Los servidores de desarrollo suelen tener muy mala seguridad (porque las comodidades como los depuradores y los seguimientos de pila son responsabilidades cuando se trata de seguridad). Si un atacante puede escalar privilegios explotando el servidor de desarrollo, él / ella puede poseer completamente la aplicación de producción.
Mark E. Haase
29

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.

deworde
fuente
Este es un buen resumen de las dificultades con el desarrollo en un entorno de producción , pero la pregunta era sobre desarrollar en un entorno separado en el hardware de producción .
Carson63000
@ Carson63000 De acuerdo, y la respuesta de Jacob es definitivamente la mejor de ese lado. He alterado el mío ligeramente.
deworde
13

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.

EL Yusubov
fuente
Este es un buen resumen de las dificultades con el desarrollo en un entorno de producción , pero la pregunta era sobre desarrollar en un entorno separado en el hardware de producción .
Carson63000
Gracias, he agregado una edición que aborda las preocupaciones de hacerlo.
EL Yusubov
10

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.

bunglestink
fuente
Vale gracias. ¿Puede el código de desarrollo hacer que una máquina sea inestable? Estoy trabajando en una vieja aplicación de rieles. Me parece (persona ingenua) que el código de desarrollo http://example.com:3000no afectaría http://example.com.
luk3thomas
2
@ luk3thomas: bueno, claro, no debería. ¿Qué sucede si hay un error en el servidor web o en el marco de Rails que bloquea el servidor? ¿Qué pasa si, como Jacob Terry sugirió en su respuesta, un bucle infinito o una pérdida de memoria en su código de desarrollo absorbe todos los recursos en el servidor de producción y compromete el rendimiento del sitio en vivo?
Carson63000
1
A veces es un requisito. Como tiendas que licencian software costoso y no tienen el presupuesto para una segunda copia solo para el trabajo de desarrollo.
Brian Knoblauch
8

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 .

msanford
fuente
3
notado, gracias por el consejo con VirtualBox
luk3thomas
1
@ luk3thomas ¡También es gratis! Hay toneladas de tutoriales en línea para VirtualBox + Ubuntu (probablemente una de las combinaciones de virtualización más comunes).
msanford
8

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.

Halcón
fuente
1
Aprende esto bastante rápido después de haber arruinado los datos de producción. Supongo que no tiene un DB.
Rocklan
8

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.

lscott3
fuente
rails 2.3.11, probablemente terminaré haciendo algo así
luk3thomas
1

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.

HLGEM
fuente
0

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.

Daniel Iankov
fuente
Si tiene errores que solo ocurren en el entorno de producción, su entorno de desarrollo no está lo suficientemente cerca del entorno de producción. Como mínimo, debe tener un entorno provisional con la misma configuración exacta que el entorno de producción, hasta la configuración exacta del sistema operativo, el hardware de procesamiento y el software instalado.
Nzall