Últimamente al “deployar” mi pet-project dejaba de funcionar la aplicación, passenger no arrancaba. Mirando los logs me di cuenta de que la dependencia de prawn y prawn-labels me estropeaban el deploy.
Recomiendan instalar prawn (y prawn-labels) como submódulo y eso por suerte está contemplado en los despliegues con Capistrano, al menos parcialmente, añadiendo la siguiente variable a nuestro deploy.rb:
set :git_enable_submodules, true
Ver fichero: capistrano/lib/capistrano/recipes/deploy/scm/git.rb
De todos modos al hacer un nuevo despliegue la cosa seguía fallando. Siguiendo el proceso a mano resulta que Capistrano solo hace el init y update de los submódulos “raíz”. Quiero decir que si estos tienen mas submódulos no son tenidos en cuenta.
Finalmente dándome un paseo por Internet encontré la solución, se trata de la gema capistrano-deepmodules de morhekil. La cosa es muy simple:
- Instalamos la gema “morhekil-capistrano-deepmodules”
- Añadimos en nuestro deploy.rb: “require ‘capistrano/deepmodules’”
- (Opcional) podemos quitar de nuestro deploy.rb: “set :git_enable_submodules, true”
That’s all folks!
Siguiendo con la tónica de ”cosas de las que quise hablar en el taller de Capistrano y no pude – episodio 2″.
A veces toca hacer deployment de aplicaciones que no tienen nada que ver con rails, el caso mas claro unas páginas estáticas(solo subir ficheros, sin migration, ni restart).
Para eso Lee Hambley hizo la gema railsless-deploy, básicamente lo que hace es quitar las “railties” de Capistrano. Con esta gema y un pequeño cambio en tu fichero Capfile puedes “deployar” lo que quieras. 
Por una vez no me voy a enrollar y a escribir paso a paso un ejemplo porque creo que con las explicaciones que hay en la página de la gema es suficiente.
“Solo puede deployar uno” – Los inmortales
Mientras veía caer los copos de nieve por la ventana, observando como cuajaban en el patio, me vino a la mente que este “viernes de Capistrano” tenía que ser diferente, no estaba/estoy lo suficiente inspirado para corregir bugs. Entonces he recordado que tengo una deuda pendiente con la gente que vino al taller de Capistrano en la Conferencia Rails. Hubo varios temas que quería haber tocado pero que tuve que eliminar por falta de tiempo. Así que vamos a por uno de esos temas, el multistaging.
Leer más…
Lee Hambley hace unos días anunció “Capistrano 2.5.9 preview release”, la finalidad de esta pre-release era comprobar que la corrección de un bug importante se había solucionado y no provocaba ninguna destrucción Además se añadió alguna pequeña funcionalidad y se corrigieron otros bugs.
Esperábamos algo de feedback y la verdad es que no ha llegado nada de nada.
Entonces desde aquí hago una llamada a toda la comunidad ror-es para que, por favor, probéis esta release y nos hagáis saber si os ha funcionado todo como debía o si la hemos “liao parda”.
Podéis reportar desde Lighthouse, mandándome un email(rgo en aspgems punto com) o por twitter a @leptom.
Para probarla tenéis actualizar net-ssh a la versión 2.0.14 y descargar la gema desde aquí e instalarla:
http://groups.google.com/group/capistrano/web/capistrano-2.5.9.gem
Para ver los cambios realizados en esta release:
http://capistrano.googlegroups.com/web/2.5.9-Release-Notes.txt.md
Gracias a todos!
La mayor parte de la documentación que hay por ahí sobre como configurar Apache para poder usar la tarea de Capistrano deploy:web:disable es usar la directiva RewriteRule para ver si existe la página de mantenimiento.
Aparentemente está bien, pero no es así porque no cambia el código de la respuesta. Los clientes recibirán un 200 OK, indicando de que el servidor está funcionando como debe. El código de estado correcto debiera ser 503 Service Unavailable. Con un 503, conseguiremos prevenir que los motores de búsqueda indexen nuestra página de mantenimiento, a los que usan nuestra API les haremos la vida mas fácil, las peticiones AJAX pueden ser tratadas correctamente cuando el site se ha caído, etc.
La configuración de apache para realizar esto es la siguiente:
Leer más…
