Estrategias de implementación de Heroku + Github

Estoy trabajando en una aplicación web, alojando el código fuente en Github y ejecutando la aplicación en Heroku. Todo funciona bien, pero tengo un problema que no puedo entender. Antes de implementar mi código, ejecuto algunas secuencias de commands para optimizar el código (minificación, concatenación de files, etc.). La aplicación heroku solo usa la versión optimizada de la aplicación.

Básicamente, tengo dos carpetas: desarrollo y production . Dev contiene el código fuente que escribo, la production es producida por mis scripts de compilation (utilizo grunt y requirejs). Actualmente, ambas carpetas están en mi repository de Git y ambas se envían a Github y Heroku. Lo que preferiría es solo tener un dev en Github y solo production en Heroku. Leí algunos artículos sobre cómo configurar diferentes twigs para Heroku, como se describe en este blog . ¿Podría configurar una twig de producción y solo tener la carpeta de production allí mientras mantengo la carpeta de desarrollo en mi twig principal? ¿O necesitaría repositorys separados?

¿Alguien ha intentado algo similar? Supongo que esto no es algo fuera de lo común.

Puede considerar simplemente usar el file heroku .slugignore (ref https://devcenter.heroku.com/articles/slug-compiler ).

Este file le permitiría eliminar la carpeta dev del package que heroku implementa en cada instancia del server, al mismo time que le permite mantener todo el código en el mismo repository.

La raíz del problema es pensar en la estrategia de implementación como una en la que carga bits finales a su server, donde los bits son un artefacto de la construcción de su repository . En tales casos, las construcciones generalmente se almacenan y archivan por separado de la fuente.

El model de Heroku es ligeramente diferente de esto, ya que supone que su repository es el artefacto a desplegar . La diferencia es leve, pero en su caso, solo significa que debe enviar a su repository los bits que desea que sirva heroku.

Otra forma de pensar es que puede prescindir de su carpeta de production y, como parte del inicio de su server, la secuencia de commands se ejecutará para generar los files de la carpeta de production . Esto le permitiría eliminar la carpeta de production y mantener su repository limpio a costa de ejecutar este process en cada inicio de su server. Esto puede resultar prohibitivamente costoso e indeseable (hay límites en cuanto a cuánto time Heroku esperará a que el server se inicie antes de que se rinda), pero es de esperar que ayude a proporcionar cierta claridad sobre la relación entre Heroku y Git.

Esta situación es un poco inusual. Pero aquí hay algunas ideas:

  • Utilizo un process que es similar al del artículo al que hizo reference.
  • Crearía solo una aplicación como tu dices. Lo crearía comenzando un nuevo repository de git en tu carpeta de desarrollo.
  • Entonces recomendaría una estrategia de implementación similar a la descrita en esta respuesta: http://sofes.miximages.com/a/8058194/267025 . Lo he adaptado a continuación:

Cree un file de rake con dos tareas: rake deploy:production y rake deploy:postprocess_files . Esas tareas pueden parecerse a esto:

 namespace :deploy do task :production do puts "turn on 'maintenance page' on heroku" system "heroku maintenance:on" puts "deploying to production" system "git push heroku-prod master" puts "post processing files..." system "heroku run rake production:postprocess_files" puts "take off maintenance page" system "heroku maintenance:off" puts "done" end task :postprocess_files do puts "run postprocessing of files on heroku" ... add commands here to post process the files. end end 

Luego desplácese a la producción usando el rake deploy:production lugar de presionar el uso de git directamente. El file de rake será entonces:

  1. establecer la página de mantenimiento,
  2. empujar a la producción,
  3. hacer su procesamiento posterior de files,
  4. quitar la página de mantenimiento.

Tenga en count que la segunda tarea de rake en su file tiene los commands para hacer el procesamiento posterior en sus files y se invoca para ejecutarse en heroku en la primera tarea de rake.

Como alternativa, es posible que pueda ampliar los activos: tarea de precompilation que Heroku ejecuta como parte de cada implementación. Eso es esencialmente lo que estás haciendo de todos modos: preparando los activos para la implementación en la producción.

Es un poco confuso porque:

  • su desarrollador y su production representan entornos , y son directorys con contenido generado :
    No deberían estar en un VCS, sino producidos automáticamente por un script que reconocería el entorno en el que se está ejecutando, y crearían el directory correcto en consecuencia.

  • el desarrollador y la production mencionados en el artículo al que se refiere " Despliegue de múltiples entornos en Heroku (mientras que todavía aloja código en Github) " representan etapas de promoción y son twigs .

El uso de twigs es bueno, solo para aislar variaciones de código (en dichas twigs), no para almacenar código generado de liberación.
Su problema particular de administración de lanzamientos (es decir, generar la entrega correcta) debe ser administrado por un script (que puede ser controlado por la versión junto con su código) y usarlo como un gancho, por ejemplo, para generar e implementar el set correcto de códigos en el lugar correcto.

Personalmente, me encanta esta solución: https://github.com/mbuchetics/heroku-buildpack-nodejs-grunt Y eche un vistazo a esto también: https://medium.com/the-javascript-collection/how-to-deploy -a-grunt-project-on-heroku-c227cb1ddc56

Honestamente, es una de las maneras más limpias.