internet, desarrollo, diseño web, sysadmin

Si utilizamos subversion como software de control de versiones, cada vez que creemos un nuevo proyecto rails, habrá una serie de tareas que tendremos que llevar a cabo.

Supongamos que el repositorio está creado y accesible en la URL:

http://svn.misite.com/miproyecto

Lo primero que tendremos que hacer, siguiendo las buenas prácticas del control de versiones con subversion, es crear tres carpetas: trunk, tags y branches.

$ REPO=http://svn.misite.com/miproyecto
$ svn mkdir --message="Layout inicial" $REPO/trunk $REPO/tags $REPO/branches
Commit de la revisión 1.

Después creamos la aplicación rails como siempre:

$ rails miproyecto
      create  
      create  app/controllers
      create  app/helpers
      ...

Ahora, en lugar de hacer un svn import, lo recomendable es hacer un svn checkout del trunk en el directorio de la aplicación y a continuación añadir la estructura de directorios del proyecto. De esta manera podemos eliminar algunos ficheros del control de versiones antes de hacer el commit:

$ cd miproyecto
$ svn checkout $REPO/trunk .
Revisión obtenida: 1
$ svn add --force .
A         lib
A         lib/tasks
...

Los ficheros de log no necesitaremos que estén bajo el control de versiones:

$ svn revert log/*
Se revirtió 'log/development.log'
Se revirtió 'log/production.log'
Se revirtió 'log/server.log'
Se revirtió 'log/test.log'
$ svn propset svn:ignore "*.log" log
propiedad 'svn:ignore' asignada en 'log'

De la misma manera, como cada desarrollador puede tener un database.yml diferente, será una buena idea eliminarlo del control de versiones:

$ svn revert config/database.yml 
Se revirtió 'config/database.yml'
$ mv config/database.yml config/database.yml.sample
$ svn add config/database.yml.sample 
A         config/database.yml.sample
$ svn propset svn:ignore "database.yml" config
propiedad 'svn:ignore' asignada en 'config'
$ cp config/database.yml.sample config/database.yml

Asimismo, el fichero schema.rb, al ser generado dinámicamente por las migraciones, no tiene sentido tampoco que esté bajo el control de versiones:

$ svn propset svn:ignore "schema.rb" db
propiedad 'svn:ignore' asignada en 'db'

También interesará eliminar del control de versiones cualquier fichero que se genere en tmp:

$ svn propset svn:ignore "*" tmp
propiedad 'svn:ignore' asignada en 'tmp'

Ahora ya podremos hacer nuestro primer commit al repositorio:

$ svn commit -m "Nueva aplicación"

Entradas relacionadas

• Scripts útiles para subversion

Se hace raro verle en movimiento y oírle, pero si te encanta Dilbert, como a mí, seguramente vas a disfrutar mucho con su canal en YouTube.

Visto en El Blog Salmón.

A continuación voy compartir con vosotros cómo actualizar WordPress, el software de este blog, a la última versión disponible (la 2.5.1 en este momento). Me he basado en la documentación de la propia web de WordPress. Básicamente, los pasos son:

• Activar una página de mantenimiento.
• Realizar una copia de seguridad.
• Desactivar los plugins.
• Descargarse la nueva versión y actualizar los ficheros.
• Actualizar la estructura de la base de datos.
• Activar los plugins.
• Desactivar la página de mantenimiento.

Página de mantenimiento

Durante el proceso de actualización no es posible asegurar que el contenido del blog vaya a mostrarse correctamente. Por ello, es conveniente que cualquier contenido del blog apunte a una página estática que indique que el blog no está disponible por mantenimiento. En la documentación recomiendan el plugin Maintenance Mode, pero a mí me ha dado problemas. Leo aquí que les pasa algo parecido. Parece que el plugin no se lleva bien con el upgrade a las últimas versiones de WordPress.

Copia de seguridad

Necesitaremos hacer realmente dos copias de seguridad:

• del software propiamente dicho, incluyendo los plugins, los temas, etc.
• del contenido de la base de datos.

Supongamos que el blog está instalado en /var/www/miblog y que vamos a realizar la copia de seguridad de los ficheros en el directorio backups del directorio home del usuario. El backup lo podemos realizar con los siguientes comandos:

$ MIBLOG=/var/www/miblog
$ cd $MIBLOG
$ mkdir ~/backups
$ tar cvf ~/backups/miblog.tar .

Y para hacer la copia de seguridad de la base de datos simplemente haremos:

$ mysqldump -u user -p database -h host > ~/backups/miblog_database.dmp

Desactivación de los plugins

Es recomendable desactivar los plugins, ya que alguno podría dar problemas con la nueva versión. Supongo que si tenemos un entorno de pruebas (porque lo tenemos, ¿no?), no sería muy descabellado, si las pruebas han ido bien, no desactivar los plugins durante el proceso de actualización en producción.

Actualización de los ficheros

Primeramente nos descargaremos la última versión de WordPress y la descomprimimos:

$ cd /var/www
$ wget http://wordpress.org/latest.zip
$ unzip latest.zip
$ rm latest.zip

A continuación, borramos los directorios wp-includes y wp-admin de la versión antigua y copiamos los ficheros de la nueva versión:

$ cd $MIBLOG
$ rm -rf wp-includes wp-admin
$ cd wordpress
$ tar cvf - .  (cd $MIBLOG tar xvf -)

También es necesario comprobar si al aumentar la versión del software, debemos añadir alguna línea nueva en el fichero de configuración, wp-config.php. Para ello, a parte de leer la documentación de la nueva versión, algo siempre recomendable, podemos ver las diferencias entre nuestro wp-config.php y el fichero wp-config-sample.php que se habrá copiado de la nueva versión:

$ cd $MIBLOG
$ diff wp-config-sample.php wp-config.php

Por ejemplo, en la versión 2.5 se ha introducido la variable SECRET_KEY. Deberemos, por lo tanto, editar el fichero wp-config.php y añadir:

// Change SECRET_KEY to a unique phrase.  You won't have to remember it later,
// so make it long and complicated.  You can visit http://api.wordpress.org/secret-key/1.0/
// to get a secret key generated for you, or just make something up.
define('SECRET_KEY', 'put your unique phrase here'); // Change this to a unique phrase.

Actualización de la estructura de la base de datos

Si es necesaria una actualización de la estructura de la base de datos, al intentar acceder a la interfaz de administración, obtendremos una pantalla como la siguiente:

Al aceptar, se actualizará la estructura de la base de datos.

Activación de los plugins

Si hemos desactivado los plugins, los tendremos que volver a activar.

Desactivación de la página de mantenimiento

Si hemos activado una página de mantenimiento, la deberemos desactivar.

Como ya se ha publicado en mil sitios, Julio Alonso ha sido condenado en primera instancia por vulnerar el derecho al honor de la Sociedad General de Autores (SGAE).

Para quien no lo sepa, todo esto comenzó con un post sobre el google bombing SGAE = ladrones.

¡Yo también soy Espartaco! ¡Todos a una, Fuenteovejuna!

Noticias destacadas de Ruby y Rails durante el mes de junio de 2008:

• Se lanza Rails 2.1.
• Se anuncia MagLev, una nueva máquina virtual de Ruby que utiliza una base de datos distribuida orientada a objetos.
• IronRuby también es capaz de ejecutar Rails.
• Se anuncia Capistrano 2.4.
• Se lanza Ruby Enterprise Edition.
• Se abre el registro para la RailsConf Europe 2008.
• Antonio Cangiano comienza el proyecto Ruby Benchmark Suite.
• Rails 2.1 funciona en Glassfish.
• Varias vulnerabilidades en ruby pueden permitir la ejecución de código arbitrario.
• Se anuncia RubyGems 1.2.
• Se lanza la versión final de Phusion Passenger 2.0.
• Nace rails-doc.org, una nueva web de documentación de Rails.