¿Consejos de implementación en varias etapas?

Question

¿Cuáles son algunas de las mejores prácticas y la teoría general de la implementación en varias etapas para aplicaciones web?

estoy particularmente interesado en el despliegue de los carriles aplicaciones usando Git, Capistrano, y de pasajeros, y he encontrado mensajes que tratan sobre los aspectos básicos del proceso:

• Capistrano: Multistage
• Introducing AutoTagger

¿Qué consideraciones debo tomar con respecto a cada etapa (pruebas, puesta en escena, producción)? ¿Deben implementarse las etapas en diferentes servidores físicos? ¿Alguna sugerencia o consejo sobre la implementación en varias etapas? ¿Algún inconveniente que debería tener en cuenta?

mejor,

Jacob

Answer 1

Es mejor tener dos entornos de servidores diferentes: puesta en escena y la producción. Siempre ignoro el entorno de prueba. El entorno de prueba actúa como producción, pero revierte la base de datos cuando termina. La ejecución de ambos en el mismo servidor puede afectar negativamente el rendimiento y la estabilidad del entorno de producción. La actualización de una gema para probar en el entorno de etapas puede afectar negativamente la producción y le puede costar el tiempo de inactividad.

Debe ser muy vigilantes para que las mismas versiones de gemas son en ambos servidores. Puede causar problemas si una versión de una aplicación funciona en etapas pero no está en producción debido a este tipo de discrepancia.

que siempre tendría una ventana de la consola abierta que está listo para hacer retroceder la última implementación en caso de que algo va mal. Realmente no hay mucho más en el proceso que eso.

Ahórrese algo de dinero y compre el servidor de almacenamiento más económico que pueda. Eres el único que lo usará, ¿verdad? Solo asegúrate de que sean del mismo proveedor.

Answer 2

siempre he acabo de crear tareas del casquillo para cada destino de despliegue y los utilizó en la línea de comandos:

# deploy.rb 
task :stage do 
    server 10.0.0.1 ... 
end 

> cap stage deploy 

También puede definir personalizar tareas dentro de cada tarea de destino, como un despliegue que hace la limpieza en puesta en escena, pero no en producción.

Desde estas tareas de despliegue de destino son raramente muy grande, realmente nunca vi el punto de algo así como la instalación de las extensiones de tapa para multi-etapa, pero supongo situaciones de otro tipo pueden ser diferentes.

Creo que la producción debe estar separado de sus otros entornos, de lo contrario existe el peligro de que los procesos de puesta en escena o similar porta mal podría afectar al rendimiento de la producción.

No Como tareas tapa para mayor comodidad en la puesta en escena, como la voladura de la base de datos y cargar de nuevo, desde el volcado más reciente producción. Estas tareas deben verificar su destino de implementación a través de una variable establecida o similar y se niegan a postularse para la producción como un seguro contra un error tipográfico a altas horas de la noche.

Es tentador poner un montón de comportamiento personalizado en su deploy.rb, pero he encontrado que esto tiende a afectar y requiere mucho esfuerzo de mantenimiento a medida que cambia su entorno o el cambio de la API.

Otra práctica que he visto en entornos más grandes es tener una cuenta shell con un checkout que rastrea la rama estable específicamente configurada para actuar como punto de control de capistrano. Usted ingresa y ejecuta comandos de tapa allí en lugar de localmente. Esto puede ayudar a evitar problemas en los que deploy.rb tiene implementadas modificaciones que no está listo para implementar con la producción. Este es un problema menor con git vs svn, pero aún así uno debe tener cuidado de pensar cuál es su deploy.rb local en el momento en que ejecuta los comandos de límite.

Heroku realmente está haciendo estas cosas fáciles en estos días, y EY y otros no están exactamente muy atrás.

Answer 3

Hemos estado utilizando el despliegue multicapa capistrano con mucho éxito durante más de un año. El sistema separa muy bien los archivos de implementación para cada etapa de una manera casi idéntica a los archivos de entorno de Rails. Fue muy fácil de configurar y administrar.