Cómo configurar rápidamente un proceso de compilación para un sitio estático

Tiene un sitio estático implementado y listo para que el mundo lo vea, pero ¿dónde debería alojarlo? ¿Cómo selecciona la plataforma adecuada y planifica un conjunto de archivos estáticos? ¿Cómo puede asegurarse de que el sitio web se regenerará automáticamente cada vez que cambie su contenido?

En este artículo, le mostraré cómo generar un sitio estático, configurar un proceso de compilación automático que se desencadena por cambios de contenido e implementar el sitio en un servidor público.

Introducción

En artículos anteriores, expliqué cómo construir un sitio web JavaScript dinámico con contenido de un CMS Kentico Cloud sin cabeza. Luego le mostré cómo convertirlo en un sitio estático para mejorar el rendimiento, la seguridad y el SEO. Así que ahora es el momento de generar ese sitio y publicarlo en línea para que todo el mundo lo vea.

Generando un sitio estático

Cada generador de sitio estático le permite construir el sitio localmente sin generar todos los archivos después de cada cambio de archivo. Si siguió mis artículos, tiene un sitio en Vue.js que se convierte para usar Nuxt.js como marco, pero aún requiere un servidor de desarrollo para manejar las solicitudes del sitio web. Para generar los archivos estáticos, ejecute el siguiente comando:

npx nuxt generate

Abra la distcarpeta en la raíz de su proyecto para encontrar los archivos generados y verifique index.htmlpara asegurarse de que su sitio web se genere correctamente. Tengo la costumbre de revisar también las páginas secundarias donde sé que hay contenido de un CMS sin cabeza, como una página de Blog. Si ve el contenido en formato HTML, ¡es un ganador!

¿Dónde debería alojar un sitio estático?

Esa es probablemente la siguiente pregunta que hace después de generar todos los archivos. Si está reconstruyendo un sitio y su antiguo sitio web todavía está en línea, probablemente esté pensando en utilizar el mismo proveedor para el sitio estático. Eso está perfectamente bien. Sin embargo, si su sitio anterior se creó sobre un CMS tradicional u otro lenguaje de programación, es posible que deba pensarlo dos veces.

Su espacio de alojamiento actual se escala para adaptarse a los requisitos de otro sistema o está diseñado para admitir una configuración específica, como PHP y MySQL o .NET y PostgreSQL. Entonces, si ese es el caso, probablemente usó la cantidad de tráfico, sesiones y otros valores para calcular qué cantidad de potencia informática necesitará (o como yo en el pasado, solo esperaba que estuviera bien).

Con los sitios estáticos viene el alivio: no más fórmulas complicadas, aproximaciones y conjeturas profesionales. Alojar un montón de archivos estáticos es algo que todos los servidores web pueden hacer fácilmente. El aspecto más importante es que el servidor ya no necesita pasar por el sofisticado proceso de manejo de solicitudes para cada visita. En su lugar, solo sirve archivos estáticos. Y eso es fácil y rápido.

Por tanto, alojar sitios estáticos es mucho más económico. Hay docenas de servicios que le permiten alojar sus sitios web de forma gratuita o al menos tener planes de inicio gratuitos. Incluyen:

  • Páginas de GitHub
  • Netlify
  • Heroku
  • y otros proveedores globales y locales. Por supuesto, también puede utilizar servicios de alojamiento de sitios web globales como Azure o AWS.

Decidí elegir las páginas de GitHub porque todos mis repositorios ya están alojados en GitHub. También es completamente gratuito y admite dominios personalizados de segundo nivel.

¿Cómo creo e implemento un sitio estático?

Pero no se trata solo de hospedaje. Tener las páginas en línea es esencial, pero es igualmente importante pensar en todo el proceso de implementación. Es decir, cómo se generarán y transportarán las páginas estáticas al servidor. Para la primera compilación, puede generar páginas en su entorno local utilizando npx nuxt generatey copiar y pegar los archivos estáticos en su espacio de alojamiento a través de FTP. ¿Pero vas a repetir ese proceso cada vez que haya un cambio de contenido?

El proceso de implementación de un sitio estático tiene tres partes:

  1. Desencadenar
  2. Construir
  3. Despliegue

Desencadenar

Es necesario que suceda una nueva compilación cuando se produzca un cambio de contenido o de implementación. Eso significa que cada vez que un editor de contenido publica contenido nuevo en un CMS sin cabeza, o cambia el código fuente, el sitio web debe reconstruirse. Pero, ¿cómo lo logramos?

Activador de cambio de contenido

Todos los CMS maduros sin cabeza incluyen webhooks. Representan una notificación de servicio a servicio sobre un determinado tipo de acción. Entonces, cuando un editor publica un elemento de contenido, el CMS sin cabeza inicia una notificación de webhook que se envía a una URL definida. En este caso, a un servidor de compilación que actuará sobre la notificación y reconstruirá el sitio.

Pero, ¿cómo sabe el servidor de compilación qué hacer? Bueno, no tiene idea de qué tipo de almacenamiento de contenido usa y probablemente no entendería la notificación genérica de webhook. Por esa razón, agregué una función simple de Azure en el medio que hace dos cosas: primero, verifica que el origen de la notificación sea Kentico Cloud:

...
if (!isValidSignature(req, process.env['KC_WEBHOOK_SECRET'])) { context.log('Signature was invalid'); return;}
...
const isValidSignature = (req, secret) => { const givenSignature = req.headers['x-kc-signature']; const computedSignature = crypto.createHmac('sha256', secret) .update(req.rawBody) .digest();
 return crypto.timingSafeEqual(Buffer.from(givenSignature, 'base64'), computedSignature);}

(ver el archivo completo en GitHub)

y luego activa la compilación usando la API del servidor de compilación:

request.post({ url: "//api.travis-ci.org/repo/Kentico%2Fkentico.github.io/requests", headers: { "Content-Type": "application/json", "Accept": "application/json", "Travis-API-Version": "3", "Authorization": `token ${process.env['TRAVIS_TOKEN']}` },
...

(ver el archivo completo en GitHub)

I know I know, Azure asks you for your credit card before you can create functions. But you can use Webtask.io, which is completely free. I explained how to create a simple function there in one of my previous articles.

Code change trigger

With code, the process gets even easier. The build servers often offer direct integration with GitHub, so it is just a matter of authorizing the build server with GitHub. When you push your code change into a remote repository, the build server receives the information automatically, and based on its configuration triggers a new build.

Build

I know, the words “build server” sounds so complicated and expensive. But when you think about it, the only thing a build server needs to do for you is to generate pages and deploy them. Exactly what you did manually with one npx command and copy-paste operation. And that was not that hard, was it?

So how can you decide which build server to use? First, you need to choose whether you want to run the build locally on your server or remotely on a third-party service. I don’t have a local server I could use for this purpose, so I decided to use third-party services. These services include:

  • AppVeyor
  • Travis CI

Both of these services are free for open-source projects.

“What? Is my website open-source? This guy is crazy!”

Am I? :-) I already mentioned the benefits of open-sourcing your website implementation in my previous article about security. In most cases, websites are very similar in functionality, so there is probably no special know-how in your implementation. It’s the content that holds the value.

But let’s get back to the build server. I chose Travis CI as it was recommended to me by a colleague. We use it for many GitHub projects in our company. So how long does it take to set it up?

Initially, I was expecting a complicated UI to configure all aspects of a build within Travis (remember VSTS online?), so finding out it all sits in a single file was a relief. So the first thing you need to do is create a file #.travis.yml# in the root of your project. This file defines what is happening during a build.

dist: trusty language: node_js node_js: — "stable" before_script: — npm install script: — npm run build deploy: ...
packages.json:"scripts": { ... "build": "npx nuxt generate && cpx CNAME dist", ...}

You see it is straightforward to understand. First I instruct NPM to install all required packages as a prerequisite to running a build. Then all static files are generated into a dist folder — this is the default when using Nuxt. I also included a preview of a packages.json file, which defines build script. Note that I am also copying CNAME file to dist directory — this tells GitHub Pages I am using custom domain rather than github.io.

Deployment

Finally the last part of the whole process. We have files generated, and now we need to transfer them to our hosting space, just like we did before using FTP. This is yet another thing a build server can do for you.

As I mentioned before I have chosen GitHub Pages as my host and Travis CI as a build server. Travis provides many options for automated deployments including GitHub Pages, so the configuration was a piece of cake. Take a look at the deployment configuration:

deploy: local-dir: dist target-branch: master provider: pages skip-cleanup: true github-token: $GITHUB_TOKEN keep-history: true verbose: true on: branch: source

Local-dir defines where my generated static pages are, target-branch marks a branch in the GitHub repository to deploy to, and pages is the name of the Travis provider for GitHub Pages. To deploy successfully you also need to generate and provide a github-token. You see there is just a variable in the build configuration as the file sits in public repository. The token’s value is stored in repository settings in Travis UI.

The finale of the series

And that’s it. That’s all you need to trigger, build, and deploy a static site automatically. Without any previous experience with build and deployment processes, this should not take you longer than a few hours. You see, static sites can be very dynamic in terms of content, the actual static file generating is handled automatically without a single human effort.

During this series of articles, I explained how to build a website using Content-as-a-Service (CaaS) to store your content, how to ensure your website is secure by not using any database, and how to ensure such a website still contains dynamic functionality like form submissions.

Good luck with your new static websites and have a #staticNewYear!

Other articles in the series:

  1. How to start creating an impressive website for the first time
  2. How to decide on the best technology for your website?
  3. How to power up your website with Vue.js and minimal effort
  4. How to Mix Headless CMS with a Vue.js Website and Pay Zero
  5. How to Make Form Submissions Secure on an API Website
  6. Building a super-fast and secure website with a CMS is no big deal. Or is it?
  7. How to generate a static website with Vue.js in no time
  8. How to quickly set up a build process for a static site