Rails: moviendo el código al servidor
Un par de apuntes sobre algunos problemas que siempre se me atragantan al mover el código al servidor:
- Siempre se debe trabajar en otro directorio que no sea el que está corriendo actualmente la aplicación.
- Copiar los archivos de configuración
database.ymlyenviroment.rbde la antigua aplicación a la nueva. Con el archivoenviroment.rbhay que ser cuidadoso si se ha introducido nuevas variables (de nuestro código, de algún plugin,…). - Copiar la base de datos de producción sobre la de desarrollo. En el caso de cargarnos algo la base de datos de producción seguirá funcionando correctamente.
- Para SQLite simplemente copiaremos un archivo sobre el otro.
- Para MySQL utilizar la orden:
mysqldump --opt --user usuario --password contraseña db_production | mysql --user usuario --password contraseña db_development.
- Realizar la migración de la base de datos de desarrollo. En este momento veremos los posibles fallos al realizar la migración de los datos de producción. Ahora es cuando podemos corregir nuestro código o datos incorrectos en la base de datos. No se puede pasar de este punto hasta que todo esté perfecto.
- Realizar las pruebas de la aplicación. La base de datos de prueba parece que copia su estructura de la de desarrollo, por lo que esta última debe estar migrada para que las pruebas no hagan cosas raras. Se deben corregir todos los fallos encontrados por las pruebas. Es posible que aparezcan fallos por la diferencia de sistemas operativos o la diferencia de bases de datos. De nuevo no se puede pasar de este punto hasta que esté todo perfecto.
- Modificar ciertos archivos de la instalación:
.htaccesssi la ruta de la aplicación ha sido modificada o si cambiamos de CGI a FastCGI,environment.rbsi se debe establecer el entorno de producción “a mano”, el shebang de los archivosdispatch.*si el path a Ruby ha cambiado…
Sí, ya se que existe Capistrano, pero no siempre se puede utilizar y muchas de las cosas que comento creo que no las sabe hacer.

