Sådan oprettes hurtigt en byggeproces for et statisk sted

Du har et statisk sted, som alle er implementeret og klar til at se verden, men hvor skal du være vært for det? Hvordan vælger du den rigtige platform og planlægger et sæt statiske filer? Hvordan kan du sikre, at webstedet automatisk regenereres, når du ændrer dets indhold?

I denne artikel vil jeg vise dig, hvordan du genererer et statisk sted, opretter en automatisk byggeproces, der udløses af indholdsændringer og distribuerer webstedet til en server, der vender offentligt.

Introduktion

I tidligere artikler forklarede jeg, hvordan man opbygger et dynamisk JavaScript-websted med indhold fra en hovedløs CMS Kentico Cloud. Så viste jeg dig, hvordan du konverterer det til et statisk sted for at hjælpe med ydeevne, sikkerhed og SEO. Så nu er det tid til at få det websted genereret og skubbe det online for hele verden at se.

Generering af et statisk sted

Hver statisk stedgenerator giver dig mulighed for at opbygge webstedet lokalt uden at generere alle filer efter hver enkelt filændring. Hvis du fulgte mine artikler, har du et websted på Vue.js, der er konverteret til at bruge Nuxt.js som en ramme, men stadig kræver en udviklingsserver til at håndtere webstedsanmodninger. For at generere de statiske filer skal du køre følgende kommando:

npx nuxt generate

Åbn distmappen i roden af ​​dit projekt for at finde de genererede filer, og tjek ud index.htmlfor at sikre, at dit websted genereres korrekt. Jeg har for vane at også kontrollere børnesiderne, hvor jeg ved, at der er noget indhold fra et headless CMS, som en blog-side. Hvis du ser indholdet i HTML-form, er du en vinder!

Hvor skal jeg være vært for et statisk sted?

Det er sandsynligvis det næste spørgsmål, du stiller efter at have genereret alle filerne. Hvis du genopbygger et websted, og dit gamle websted stadig er online, overvejer du sandsynligvis at bruge den samme udbyder til det statiske websted. Det er helt fint. Men hvis dit gamle websted blev bygget oven på et traditionelt CMS eller et andet programmeringssprog, skal du muligvis tænke to gange.

Dit nuværende hostingrum er skaleret til at passe til kravene i et andet system eller designet til at understøtte en bestemt opsætning, som PHP og MySQL eller .NET og PostgreSQL. Så hvis det er tilfældet, har du sandsynligvis brugt mængden af ​​trafik, sessioner og andre værdier til at beregne, hvilken mængde computerkraft du har brug for (eller som mig tidligere, håbede bare, det ville være OK).

Med statiske steder kommer lettelse: ikke mere komplicerede formler, tilnærmelser og professionelt gætteri. At hoste en masse statiske filer er noget, som enhver webserver nemt kan gøre. Det vigtigste aspekt er, at serveren ikke længere behøver at gennemgå den sofistikerede pipeline til anmodningshåndtering for hvert hit. Det serverer bare statiske filer i stedet. Og det er let og hurtigt.

Hosting af statiske websteder er derfor meget billigere. Der er snesevis af tjenester, der giver dig mulighed for at være vært for dine websteder gratis eller i det mindste have gratis startplaner. De omfatter:

  • GitHub-sider
  • Netlify
  • Heroku
  • og andre globale og lokale udbydere. Du kan selvfølgelig også bruge globale webstedshostingtjenester som Azure eller AWS.

Jeg besluttede at vælge GitHub-sider, da alle mine arkiver allerede er hostet på GitHub. Det er også helt gratis og understøtter brugerdefinerede 2. niveau domæner.

Hvordan bygger og implementerer jeg et statisk sted?

Men det handler ikke kun om hosting. Det er vigtigt at have siderne online, men det er lige så vigtigt at tænke på hele implementeringsprocessen. Det vil sige - hvordan skal de statiske sider genereres og transporteres til serveren. Til den første build kan du generere sider i dit lokale miljø ved hjælp af npx nuxt generateog kopier-indsæt de statiske filer til dit værtsrum via FTP. Men skal du gentage denne proces hver gang der sker en indholdsændring?

Processen med at implementere et statisk sted består af tre dele:

  1. Udløser
  2. Byg
  3. Implementering

Udløser

En ny build skal ske, når der enten sker en indholds- eller implementeringsændring. Det betyder, at når en indholdseditor udgiver nyt indhold i et headless CMS, eller du ændrer kildekoden, skal webstedet genopbygges. Men hvordan opnår vi det?

Udløser til indholdsændring

Hver moden hovedløs CMS har webhooks. De repræsenterer service-til-service-meddelelser om en bestemt type handling. Så når en editor udgiver et indholdselement, initierer den headless CMS en webhook-underretning, der sendes til en defineret URL. I dette tilfælde til en build-server, der vil reagere på underretningen og genopbygge webstedet.

Men hvordan ved build-serveren, hvad de skal gøre? Nå, det har ingen idé om, hvilken slags indholdsopbevaring du bruger, og vil sandsynligvis ikke forstå den generiske webhook-underretning. Af den grund tilføjede jeg en simpel Azure-funktion i midten, der gør to ting - først kontrollerer den, at meddelelsens oprindelse er 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);}

(se den komplette fil på GitHub)

og udløser derefter bygningen ved hjælp af build-serverens API:

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']}` },
...

(se den komplette fil på 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. Sådan tændes dit websted med Vue.js og minimal indsats
  4. Sådan blandes headless CMS med et Vue.js-websted og betal nul
  5. Sådan oprettes formularindsendelser på et API-websted
  6. At opbygge et superhurtigt og sikkert websted med et CMS er ikke noget stort. Eller er det?
  7. Sådan oprettes et statisk websted med Vue.js på ingen tid
  8. Sådan oprettes hurtigt en byggeproces for et statisk sted