¿Se puede configurar Heroku para que realice un verdadero despliegue sin problemas?

Question

Nuestro equipo ha estado muy interesado en la implementación continua recientemente, pero nos hemos topado con un pequeño obstáculo en cuanto a cómo realmente implementar el código en Heroku: parece inevitable que tenga que haber una cierta cantidad de tiempo de inactividad para haz un push de código a Heroku.

En un entorno tradicional, la implementación de código, probablemente se vería algo como esto:

1. empuje el código hasta un directorio temporal en alguna parte (código antiguo es todavía viven)
2. migraciones ejecuta en la base de datos (más a menudo que no, es más seguro para ejecutar las migraciones de antemano, y los pocos que rompa el código puede tener vigilancia en contra)
3. medio Take (o algún porcentaje de servidores) del equilibrador de carga.
4. Implementar código en esos servidores.
5. Si es posible, ejecute algún tipo de prueba de humo automático/ejercitar los servidores por lo que son "calientes"
6. Interruptor qué servidores están dentro y fuera del equilibrador de carga
7. Enjuague y repita.

Con Heroku, que tienen muy poco control sobre dos pasos críticos:

• No puedo ejecutar migraciones de bases de datos en primer lugar. Una forma he considerado de evitar esto es mantener las migraciones de bases de datos ramificados por separado, y empujar los heroku a primera - que aunque dolorosa, resolvería el problema - pero sólo exacerbará ...
• Dyno tiempo de spin-up puede tomar un tiempo bastante largo - obviamente, esto es más culpa de Rails que de Heroku, pero el problema clave es que no puedo hacer algo como el balanceo de carga aleatorio para asegurarme de que mi aplicación esté lista y cargada antes de un servidor recién implementado se vuelve a colocar en el equilibrador de carga. En su lugar, yo más o menos no tienen más remedio que dar a los usuarios una segunda pantalla 10-15 carga y esperar lo mejor (y hacer que dos veces si yo uso la estrategia de despliegue de bases de datos desde arriba)

Usamos el mantenimiento Actualmente pantalla, pero no va a ser una solución escalable si nos movemos a la implementación continua completa (que probablemente tendríamos aproximadamente 10-20 despliegues al día, y 10-20 * 30 segundos de pantalla de mantenimiento comienza a sumar)

¿Alguien ha tenido problemas similares? ¿Cómo los abordaron? ¿Algún gran caso de éxito/historias de éxito para verdadero implementación continua en heroku?

Answer 1

Respecto al tiempo de spin-up dinamómetros, Heroku tiene una función de prueba para hacer frente a eso:

https://devcenter.heroku.com/articles/labs-preboot/

Básicamente arranca sus nuevos dinamómetros primero, espera un tiempo, tráfico conmutado y sólo entonces mata al los viejos. Mi aplicación vio una mejora notable en el rendimiento durante los despliegues. Se puede leer aquí:

http://ylan.segal-family.com/blog/2012/08/27/deploy-to-heroku-with-near-zero-downtime/

Answer 2

En Heroku emitiremos un SIGTERM a su (s) banco (es) al reiniciar. Después de un momento, si el proceso no se detiene, serán asesinados. Esto debería permitirle suficiente tiempo de gracia para reiniciar sin problemas cuando no está ejecutando migraciones.

Siempre se puede empujar código para una aplicación puesta en escena a la que apuntaba a su producción DB y migraciones ejecutar desde allí. Pedro escribió una bonita entrada de blog en el funcionamiento de las migraciones cero tiempo de inactividad que debe ayudar también: http://pedro.herokuapp.com/past/2011/7/13/rails_migrations_with_no_downtime/

Espero que esto ayude un poco.