Strapi + Gatsby: Builds automáticas en cPanel

Cuando nos lanzamos a renovar nuestra web se decidió por dividirla en las dos áreas de Bullhost:

• Ciberseguridad y sistemas bajo un dominio .security.
• Desarrollo y marketing digital (en la que estás ahora mismo) con un dominio .agency.

Ambos sitios webs están desarrollados en Gatsby y son alimentados desde una instancia de Strapi común para ambos. Esto nos aportaba la ventaja de tener en una única interfaz la gestión de los contenidos en cualquiera de los sitios.

Todo parecía perfecto (aunque trabajábamos con una tecnología relativamente nueva para nosotros) hasta que nos dimos cuenta de algo. Tanto las webs como el CMS iban a estar alojados en nuestro CPD, obviamente, y con planes de hosting securizados. Esto descartaba cualquier tipo de servicio con builds automáticas (como Gatsby Cloud o Netlify), ya que el framework sólo las soporta en esos casos. ¿Íbamos a tener que estar lanzando builds de forma manual cada vez que se publicase contenido en la web? ¡Locura! Así que se abrió el debate en el equipo de desarrollo de Bullhost para poder solventar este problema que, por error, habíamos pasado por alto durante la elección de tecnologías para el proyecto.

¿Qué solución podíamos encontrar? Tirar de los hooks que tiene Strapi al guardar contenido y llamar a un script que realizase la build cada vez que es invocado.

Se creó una carpeta de staging para cada web, en la que se aloja el código recibido desde nuestro repositorio de GIT para que ahí se realicen las builds. También creamos una carpeta donde alojar los dos scripts que llevan a cabo las acciones necesarias y otras dos donde dejamos archivos relevantes para nuestras webs (htaccess, robots…).

Actualmente hay dos tipos de contenido que activan dichas builds automáticas: los posts de nuestro blogs y los proyectos o casos de éxito. Cuando uno de éstos es guardado, el hook de Strapi se lanza y comprueba el estado de este. 

Finalmente, y con el objetivo de no lanzar builds como locos, impusimos condiciones en las que se lanzase dicho script:

1. Cuando el contenido pasa a publicado.
2. Cuando el contenido se guarda mientras está publicado.
3. Cuando un contenido publicado se pasa a borrador de nuevo.
4. Cuando el contenido se borra.

Este hook llama a un script que realiza varios pasos de forma consecutiva:

1. Realiza un backup de los archivos de producción y lo copia a una carpeta asignada.
2. Lanza la build.
3. Si la build no da errores, borra el contenido de la carpeta de producción.
4. Copia el contenido de la carpeta public generada en la build a la carpeta de producción.
5. Copia los archivos importantes (htaccess, robots…).

Gracias a este stack hemos conseguido centralizar el contenido para ambas webs en un CMS ligero y sencillo de utilizar, además de tener unas webs muchísimo más rápidas para el usuario final. Creemos que este pequeño inconveniente es irrelevante una vez visto el resultado en términos de velocidad y de usabilidad para las personas que usan el CMS habitualmente. Gatsby es una tecnología increíble, que permite crear páginas web de una rapidez raramente vista hasta hace poco. Y si hacemos caso a todos los estudios que se publican al respecto, el salvar un par de segundos en la carga de tu web puede suponer un gran aumento en el número de usuarios que deciden quedarse en tu página.