develumpen.com

Montando un blog poco a poco con Ruby on Rails

Hace años que dejé de usar CMS en el ámbito personal. Aunque sea más laborioso prefiero montarme algo personalizado. Usualmente utilizo Ruby on Rails.

Ya lo sé. Montar un blog así es como cazar moscas a cañonazos. Podría usar uno de los miles de servicios o CMS que existen por ahí con este propósito. Pero no me apetece.

El código que hace funcionar este blog es público. Lo voy escribiendo en mis ratos libres. Imagino que dista de ser perfecto y puede que no le sea útil a nadie más que a mi. Si te resulta útil o crees que algo se puede mejorar, siéntete libre de abrir una pull request y la revisaré encantado.

¿Cómo probar el blog en un entorno de desarrollo local?

Necesitarás Ruby 3.4.2 instalado en tu máquina.

Clona el repositorio. Puedes hacerlo con el comando: git clone [email protected]:develumpen/blog.git

Entra dentro del directorio y ejecuta bundle install para instalar las dependencias.

Ejecuta bin/dev para correr el servidor de desarrollo. Seguramente se queje de que tienes migraciones pendientes por correr. Si apretando el botón que te aparece en la web no funciona, prueba ejecutando bin/rails db:migrate.

Si todo ha ido bien, deberías poder acceder al blog desde http://localhost:3000

¿Cómo desplegar una copia del código a un entorno de producción?

¿Se dice desplegar? No acostumbro a hablar sobre desarrollo en castellano y escribir deployar me parecía un poco cutre.

Esto es algo personal y hay muchas maneras de hacerlo. Yo utilizo Kamal.

Para no exponer credenciales, he creado un repositorio privado nuevo en Github. Acto seguido, he clonado el repositorio público en un directorio diferente, por ejemplo git clone [email protected]:develumpen/blog.git mi-repositorio-privado.

Esto copiará el contenido del repositorio original en el directorio recién creado mi-repositorio-privado.

Como quiero poder traer los cambios del repositorio original al privado, renombro origin a upstream con el comando git remote rename origin upstream. Imagino que le puedes poner el nombre que te de la gana, pero siempre lo he hecho así.

Lo siguiente es definir el origen del repositorio privado que he creado en Github con git remote add origin xxx, sustituyendo xxx por el repositorio privado. Una vez definido el nuevo origin, subo el código con git push -u origin main.

Ahora ya tengo una copia del código público en mi repositorio privado.

Como he dicho, utilizo Kamal para desplegar a producción. Dentro del repositorio privado, ejecuto kamal init y siguiendo la documentación configuro lo que necesite.

Después de configurar Kamal hay un par de cosas que hay que configurar en la aplicación. La primera es la base de datos. Edito lo que necesito en config/database.yml en la sección production:.

Lo siguiente es regenerar los credenciales. Debí haberlos omitido al subir el código. Como no voy a compartir la clave maestra, los credenciales encriptados del repositorio público son inservibles (dentro no hay nada). Para generar una nueva clave y unos credenciales válidos ejecuto bin/rails credentials:edit. Como uso VSCode, he de modificar un poco el comando : EDITOR=code --wait bin/rails credentials:edit.

Así a grandes rasgos es como lo hago yo. Si necesitas ayuda puedes dejarme un comentario (de momento no, porque no se puede) o escribirme a [email protected].

¿Cómo traer los cambios del repositorio público al repositorio privado?

Todo el desarrollo del blog ocurrirá en el repositorio público. Para traer los cambios al repositorio privado usaré los dos remote que definí un poco más arriba.

Para no arrepentirme en caso de que algo vaya mal, lo primero es crear una nueva rama en el repositorio privado. Seguidamente traigo los cambios con git fetch upstream y los aplico en la nueva rama con git rebase upstream/main. También se puede hacer git merge upstream/main si lo prefieres.

A veces habrá conflictos si en el repositorio privado toco algo que ha cambiado en el público. Se resuelven como conflictos normales de git.

Antes de hacer merge (¿cómo se dice esto en castellano?) despliego la nueva rama para ver que todo ha ido bien.

Conclusión

No es un sistema muy complicado para desarrollar en público y desplegar en privado. Es posible que haya mejores alternativas (por favor, ¡házmelas saber!).

En el pasado implementé un "complicado" sistema de scripts en bash y Ruby pero era un rollo de mantener.

Tengo pensado desarrollar unas cuantas aplicaciones usando este sistema y me gustaría entender si es útil y fácil para otras personas. ¿Cómo lo haces tú?