Heroku rails 3.1 aplicación - compilación de activos localmente frente a la compilación de activos durante la compilación de babosas

Question

Estoy ejecutando una aplicación Rails 3.1 en la pila Heroku Cedar que admite la canalización de activos. Heroku lists 3 ways para compilar elementos

1. Compilación de activos localmente.
2. Compilación de activos durante la compilación de slug.
3. Compilar elementos durante el tiempo de ejecución.

Obviamente, el # 3 es malo para el rendimiento y los documentos de Heroku también lo recomiendan. Pero no estoy seguro de cuál es mejor entre # 1 y # 2.

# 1 requiere que ejecute rake assets:precompile e incluya su carpeta public/assets en git. Su babosa será más grande, pero supongo que el tiempo de inactividad para implementar un sitio será menor. Pero el tamaño más grande de la babosa significa un arranque de la aplicación más lento, así que tal vez sea un lavado.

# 2 lo hará tomar más tiempo para implementar actualizaciones a causa de precompilación que se realiza en el lado Heroku. Sin embargo, tendrá una babosa más pequeña y habrá menos para administrar/recordar.

Mi pregunta es - qué opción (# 1 o # 2) es la mejor para la producción y por qué?

Hasta ahora se ve como la opción # 2, pero quiero asegurarme de que no estoy pasando por alto algo.

Answer 1

I abordado algunas de estas cuestiones y una gran Gotcha en mi pregunta aquí: Rails 3.1.1 asset pipeline Heroku caching gotcha

preferiría # 2 si funcionó para mí, así que no tengo que checkin activos compilados que acaba hincha el GIT repositorio.

activos durante la compilación Compilación babosa no dará lugar a ningún tiempo de inactividad adicional debido a que su aplicación existente permanecerá hasta babosa compilación es completa, de modo que no hay preocupaciones.

Mi consejo sería # 2 si puede hacer que funcione para usted. Si terminas yendo con w/# 1, entonces toma las mejores prácticas: git rm -r public/assets antes de los activos de rake: precompila para asegurarte de que no quede nada.

Answer 2

Podría depende del tamaño de la carpeta de activos, (y tal vez una solución a largo plazo sería poner esos activos fuera de la aplicación y alojarlas en S3 o similares.)

De lo contrario, yo estoy suponiendo # 1 sería el mejor en producción ya que cualquier activo se puede usar y guardar en caché de inmediato.

Estoy leyendo la sección de documentación de Heroku en assets, y parecen indicar que el n. ° 2 se usará en caso de que haya olvidado hacerlo usted mismo, como una conveniencia. No obtendrá una pequeña babosa, ya que los resultados de la preparación de los activos se incluirán en la babosa para desplegarse.