Bien batido y revuelto

Seguimos con Ruby on Rails y ahora se trata de las migraciones y los problemas que pueden aparecer cuando se trabaja en un equipo. No es un problema exclusivo de RoR, pero puesto que Rails invita a las buenas prácticas y ofrece un mecanismo interesante para definir la base de datos (las migracionadas), nos puede pasar desapercibido y olvidemos el problema de la estructura de la base de datos hasta que demos de lleno con el problema.

Cuando trabajamos en un equipo de desarrolladores en una aplicación Ruby on Rails puedes encontrarte con la situación de que 2 personas creen al mismo tiempo una migración. Puesto que el nombre del fichero contiene una primera parte con un número de migración es bastante posible que dos desarrolladores creen un fichero con el mismo número en su copia local, y por culpa de ello luego pueda resultar complicado salir del paso. Quien se haya encontrado con este problema sabrá de que estoy hablando, pero por si acaso mejor usaré un ejemplo:

Supongamos que estamos desarrollando una aplicación en la que existen usuarios (User) que escriben comentarios (Comment). En un determinado momento la base de datos está en la versión 12, y uno de los desarrolladores decide crear un sistema de roles y para ello crea 2 migraciones


$ script/generate migration add modify_user
exists db/migrate
create db/migrate/013_modify_user.rb
$ script/generate migration add create_roles
exists db/migrate
create db/migrate/014_create_roles.rb
$ rake migrate


Al mismo tiempo otro desarrollador está añadiendo la funcionalidad de tener comentarios anidados:


$ script/generate migration add modify_comments
exists db/migrate
create db/migrate/013_modify_comments.rb
$ rake migrate


Cuando terminan de implementar la funcionalidad que empezaron a desarrollar cada programador actualiza del repositorio y su copia local (svn update && svn ci), y en el caso del primer desarrollador, al hacer un rake migrate no se aplicará ningún cambio puesto que el fichero que subió el segundo desarrollador es un cambio para una versión 13, mientras que el segundo desarrollador al actualizar aplicará el cambio que modifica los roles. Además, los dos usuarios tendrán una versión de la base de datos no funcional y los cambios en el código dejarán una aplicación “rota” puesto que la base de datos no está tal y como la aplicación espera.

Quizás los primero que se nos pase por la cabeza para esquivar este problema sea subir al gestor de versiones las migraciones tal y como las creamos, pero esto puede crear nuevos problemas, porque quizás el cambio haga que la aplicación deje de funcionar del todo. Un ejemplo típico de ese caso podría ser que decidimos cambiar la forma en la que se guardan las direcciones de los usuarios y el campo Address desaparece y aparecen los campos ZIP, City y demás; en este ejemplo no podríamos subir la migración hasta que no hayamos completado algo el código.

Si bien es cierto que unas buenas prácticas como Integración Continua (por cierto, tengo pendiente mirar CruiseControl.rb) detectarían el problema, la realidad es que no es algo trivial de solucionar. De hecho hay algunas propuestas como migraciones con marcas temporales, llevar un control de las migraciones que hay en el repositorio, o bien detectar la colisión en el commit pero en todas ellas encuentro diversos problemas que no se superan del todo. Creo que al final la mejor solución es evitar cualquier remedio técnico al problema y usar una la comunicación para conocer las intenciones de modificar la base de datos. Posiblemente sea la solución con menos contras ¿o tenéis alguna otra?