Estaba teniendo problemas con Capistrano 1.4 para hacerlo funcionar con Dreamhost y he tenido que actualizarlo a la nueva versión 2.0, que trae algunos cambios que me han desorientado al principio, más que nada porque en el manual mítico oficial no han actualizado nada. Luego descubrí que la nueva web oficial es otra, aunque apenas tiene documentación.

Los pasos que he seguido son:

Desde el panel de control de Dreamhost:

1. Añadir un nuevo subdominio, como myapp.jesuscarrera.info, dándole soporte para FCGI, y añadiendo /current/public al directorio sugerido.

   Más tarde, en cuanto se propaguen las DNS y podamos acceder a http://myapp.jesuscarrera.info/current/public, y antes de ejecutar cap deploy, deberemos borrar manualmente estos dos directorios, porque cap deploy creará un symlink para que Capistrano y Subversion funcionen bien juntos.

2. Añadimos la base de datos que vallamos a utilizar.
3. Creamos el repositorio de Subversion. Yo tengo creado un subdominio para acceder a esos repositorios. Su URL quedaría así: http://svn.jesuscarrera.info/myapp

En nuestra aplicación (máquina local en desarrollo).

1. Editar el config/database.yml para que en :production tenga los datos de Dreamhost.
2. En config/environment.rb descomentar la línea: ENV['RAILS_ENV'] ||= 'production'
3. En public/dispatch.* cambiarle la primera línea por ésta: #!/usr/bin/env ruby
4. En public/.htaccess asegurarnos de que ésta línea tenga .fcgi y no .cgi RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]
5. Añadir después de RewriteEngine On lo siguiente, para que muestre una página de mantenimiento si existe (cuando ejecutamos cap deploy:web:disable). RewriteCond %{DOCUMENT_ROOT}/system/maintenance.html -f RewriteCond %{SCRIPT_FILENAME} !maintenance.html RewriteRule ^.*$ /system/maintenance.html [L]
6. Instalar Capistrano 2.0
   sudo gem install capistrano
7. Añadimos los archivos de Capistrano a nuestra app. Ejecutamos desde el directorio myapp:
   capify .

   Ésto crea dos archivos: Capfile y config/deploy.rb.

8. Editamos config/deploy.rb para que quede algo así: set :user, 'jesuscarrera' set :application, "myapp.jesuscarrera.info" set :repository, "svn+ssh://jesuscarrera@svn.jesuscarrera.info/home/#{user}/svn/myapp" # ============== # ============== # ============== role :web, application role :app, application role :db, application, :primary => true set :deploy_to, "/home/#{user}/#{application}" set :use_sudo, false

   A mi me ha funcionado sin estas últimas líneas, pero puede que en algunos casos sean necesarias:

   ################################################################# set :checkout, "export" # TASKS # desc "Tasks to execute after code update" task :after_update_code, :roles => [:app, :db, :web] do # fix permissions run "chmod +x #{release_path}/script/process/reaper" run "chmod +x #{release_path}/script/process/spawner" run "chmod 755 #{release_path}/public/dispatch.*" end desc "Restarting after deployment" task :after_deploy, :roles => [:app, :db, :web] do run "touch /home/jesuscarrera/depot.jesuscarrera.info/current/public/dispatch.fcgi" end desc "Restarting after rollback" task :after_rollback, :roles => [:app, :db, :web] do run "touch /home/jesuscarrera/depot.jesuscarrera.info/current/public/dispatch.fcgi" end ########## task :restart, :roles => :app do run "ruby #{current_path}/script/process/reaper --dispatcher=dispatch.fcgi" end # In config/deploy.rb task :after_symlink, :roles => [:web, :app] do # Make dispatcher executable run "chmod a+x #{current_path}/public/dispatch.fcgi" end #################################################################
   Recuerda que para que no pida las claves todo el rato podemos autorizar nuestro equipo para SSH.
9. Realizamos nuestra primera importación al repositorio

   svn import myapp svn+ssh://[email protected]/home/jesuscarrera/svn/myapp -m "Initial import"

10. Renombramos el original (o si eres valiente también lo puedes borrar), y nos descargamos la primera versión del repositorio:
    mv depot depot.imported
    svn co svn+ssh://[email protected]/home/jesuscarrera/svn/myapp myapp
11. Preparamos el servidor para recibir nuestra app:
    cap deploy:setup
12. Enviamos nuestra aplicación aplicando migraciones:
    cap deploy:cold
13. A partir de ahora cada vez que realicemos cambios en nuestra máquina local en desarrollo deberemos en primer lugar enviarlos al repositorio, y luego actualizarla en producción:

    svn commit -m "Change description"
    cap deploy

    Si hemos añadido migraciones sería con:
    cap deploy:migrations

    Si algo va mal podemos volver a la anterior versión con:
    cap deploy:rollback

    Si vamos a realizar un mantenimiento importante podemos deshabilitar y habilitar la web con:
    cap deploy:web:disable
    cap deploy:web:enable

    Para ver otras tareas:
    cap -T

Yo lo he probado con la aplicación que te enseña a hacer el fantástico libro Agile Web Development With Rails. La podéis ver en depot.jesuscarrera.info/store. Ha funcionado tan bien y a la primera que hasta me ha sorprendido!

Capistrano es una estupenda herramienta que nos simplifica y automatiza el despliegue de aplicaciones (deployment). Utiliza unos de archivos de configuración para realizar esas tareas, que podemos modificar dependiendo de nuestras necesidades. Lo que deprec hace es servirnos una serie de recetas precocinadas para Capistrano. En la actualidad (1.9) sólo funciona cuando el deployment es a un Ubuntu 6.06.1 Server LTS, pero en el futuro (2.0) el sistema operativo se servirá como un plugin. Éste screencast nos muestra como de rápido podríamos tener un servidor funcionando con todo lo necesario empezando desde cero.

El procedimiento sería el mismo en servidores remotos (sin utilizar Parallels), y sería resumiendo algo así:

Nota: he modificado algunas cosas que no aparecen el el vídeo, que me hicieron falta para que funcionase.

En el la máquina remota:

sudo apt-get install openssh-server

En la máquina local:

Cremos nuestras keys si no las tenemos
ssh-keygen -t rsa

Subimos las keys al servidor:
cap setup_ssh_keys
sudo gem install deprec -y
echo "require 'deprec/recipes'" >> ~/.caprc

Para que recoja las llaves ssh y no nos pregunte todo el rato la clave:
echo ssh_options[:keys] = %{/Users/jesus/.ssh/id_rsa} >> ~/.caprc

Creamos la aplicación:
rails myapp

Le aplicamos deprec:
cd myapp
deprec --apply-to .

Configuramos config/deploy.rb
Modificamos el :domain, :application, :user.

Instalamos lo necesario para que funcione Rails (Apache, Ruby, etc.)
cap install_rails_stack

Instalamos la aplicación:
cap setup

Añadimos soporte para svn:
cap setup_scm

Actualizamos la aplicación con las migraciones:
cap deploy_with_migrations

Reiniciamos Apache:
cap restart_apache

Ahora en cada actualización utilizaremos:
cap deploy

Y si queremos volver a una versión anterior:
cap revert

Hoy le he dado una alegría a una amiga desesperada porque había perdido unas fotos muy importantes de la tarjeta de su cámara gracias a PhotoRec. Tenía esa aplicación fichada pero nunca había tenido oportunidad de probarla. Resultó ser muy efectiva y fácil de utilizar.

A veces para los frikis es fácil quedar como un héroe.

Cuando tenemos cualquier documento que cambia con frecuencia, es muy útil utilizar un sistema de control de versiones.

Porqué usar un sistema de control de versiones:

• Imprescindible si trabajan varias personas en un mismo código, para evitar sobreescribir el trabajo del otro. También podemos asignar permisos a diferentes ramas del proyecto.
• Aunque se trabaje solo, con él podemos llevar un control sobre las versiones de nuestro trabajo. En caso de haber realizado un cambio que no ha resultado bien, podemos volver a una versión anterior fácilmente, y sin tener que recordar esos cambios.
• Acceso remoto: no necesitamos el código en nuestra máquina, ni siquiera en nuestra LAN.
• Podemos guardar copias de seguridad fácilmente.

Existen multitud de sistemas de control de versiones, pero el más conocido y usado hoy en día es el Subversion. Es open source y tiene todas las características que necesitaremos. Manual oficial.

Pequeña guía de uso

Funcionamiento general: Necesitaremos tener instalados el svn en los clientes y svnadmin en el servidor (aunque pueden ser la misma máquina). El servidor contiene la copia principal (repositorio), y los clientes se descargan una copia para trabajar localmente. Una vez realizados los cambios se actualiza el repositorio.

En el servidor crear repositorio:
mkdir /home/jesus/svn-repos
svnadmin create /home/jesus/svn-repos

Ahora podemos crear ahí las carpetas y archivos necesarios.

Normalmente se utiliza una carpeta llamada trunk para la principal línea de desarrollo, una carpeta branches para las versiones en producción y sus bugfixes, y una carpeta tags para guardar versiones específicas (por ej. la versión 5.0).

Para acceder al repositorio podemos hacerlo de varias formas:

• file:///path si el repositorio está en nuestro equipo.
• svn://servidor/path si el repositorio está en nuestra LAN.
• svn+ssh://servidor/path si trabajamos a través de internet. Necesitaremos tener configurado ssh en el servidor.

También podremos hacerlo con http:// o https:// pero no son tan seguros.

Imaginemos que tenemos en nuestra máquina un proyecto y que queremos subirlo a un servidor donde se encuentra el repositorio:
svn import ./localproject svn+ssh://[email protected]/home/usuario/svn/project/trunk -m "Primer import"

Si queremos bajar un proyecto del repositorio (check out):
svn co file:///home/jesus/svn-repos/project/trunk ./localproject

para recuperar la versión 7 específica añadimos -r 7. No confundir éstas versiones (cambios) con las de branches (releases).

Para actualizar el repositorio cuando tenemos los cambios (commit – check in):
svn ci -m "mensaje informativo"

Si alguien lo ha modificado antes que nosotros deberemos antes actualizar (update):
svn up

Comprobar estado de los ficheros de nuestra copia local (status):
svn st
Nos mostrará los ficheros modificados con un M delante, los ficheros con conflictos con una C, los que no están bajo svn con un ?, etc…

Los ficheros con conflictos deberemos corregirlo e indicar que está arreglado con:
svn resolved fichero

Para ver las diferencias entre ficheros locales y los del repositorio:
svn diff fichero

Si queremos ver la diferencia entre vesiones:
svn diff -r19:21 fichero

Para ver los cambios ocurridos en el repositorio:
svn log

Si realizamos cambios en la estructura de ficheros en nuestra copia local, debemos indicárselo al subversion con copy, delete, move o add.
svn copy file1.txt file2.txt

Por ejemplo si hemos creado un fichero file.txt sin el svn add, a la hora de hacer el commit ese fichero no será subido al repositorio hasta que no pongamos svn add file.txt

Si añadimos un directorio por defecto añade también sus archivos. Si hemos añadido varios ficheros y/o directorios podemos indicarlo recursivamente.
svn add *

Realizar copia de seguridad:
svnadmin dump path/to/repository | gzip > dumpfile.gz

Recuperar copia de seguridad:
gunzip -c dumpfile.gz | svnadmin load path/to/repository

Para crear una imagen que no incluya versiones ni nada, por ejemplo cuando subamos la aplicación a producción:
svn export svn+ssh://[email protected]/home/usuario/svn/project/trunk /local/path

Cuando tenemos un servidor al que accedemos a menudo por SSH lo más cómodo para que no nos esté pidiendo la clave SSH todo el rato lo mejor es autorizarlo enviándole nuestra llave SSH:

Si no la tenemos creada:
ssh-keygen -t rsa

Nos las enviamos:
scp ~/.ssh/id_rsa.pub [email protected]:~/

Nos logueamos:
ssh [email protected]

La añadimos a las autorizadas y les damos permisos:
mkdir .ssh
cat id_rsa.pub >> .ssh/authorized_keys
rm id_rsa.pub

chmod go-w ~
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys