Ako rýchlo nastaviť proces zostavenia statickej stránky

Máte všetky statické stránky implementované a pripravené na to, aby ich videl celý svet, ale kde by ste ich mali hostiť? Ako vyberiete správnu platformu a naplánujete sadu statických súborov? Ako môžete zabezpečiť, aby sa webová stránka automaticky regenerovala vždy, keď zmeníte jej obsah?

V tomto článku vám ukážem, ako vygenerovať statický web, nastaviť automatický proces vytvárania, ktorý je vyvolaný zmenami obsahu, a nasadiť tento web na verejne prístupný server.

Úvod

V predchádzajúcich článkoch som vysvetlil, ako vytvoriť dynamický web JavaScript s obsahom z bezhlavého CMS Kentico Cloud. Potom som vám ukázal, ako ho previesť na statický web, ktorý pomáha výkonu, bezpečnosti a SEO. Takže teraz je čas nechať si vygenerovať túto stránku a poslať ju online, aby ju videl celý svet.

Generuje sa statická stránka

Každý statický generátor stránok umožňuje vytvoriť lokalitu lokálne bez generovania všetkých súborov po každej zmene súboru. Ak ste sledovali moje články, na Vue.js máte web, ktorý je konvertovaný na použitie Nuxt.js ako rámca, ale stále vyžaduje vývojový server na spracovanie požiadaviek na web. Ak chcete vygenerovať statické súbory, spustite nasledujúci príkaz:

npx nuxt generate

Otvorte distpriečinok v koreňovom adresári vášho projektu, vyhľadajte vygenerované súbory a skontrolujte, index.htmlči sa váš web generuje správne. Mám vo zvyku kontrolovať aj podradené stránky, kde viem, že existuje nejaký obsah z bezhlavého CMS, napríklad stránka blogu. Ak vidíte obsah vo formáte HTML, ste víťazom!

Kde by som mal hosťovať statické stránky?

Toto je pravdepodobne ďalšia otázka, ktorú sa opýtate po vygenerovaní všetkých súborov. Ak prestavujete web a váš starý web je stále online, pravdepodobne uvažujete o použití rovnakého poskytovateľa pre statický web. To je úplne v poriadku. Ak však bola vaša stará stránka postavená na tradičnom CMS alebo inom programovacom jazyku, možno si to budete musieť rozmyslieť.

Váš súčasný hostiteľský priestor je upravený tak, aby vyhovoval požiadavkám iného systému, alebo je navrhnutý tak, aby podporoval konkrétne nastavenie, ako sú PHP a MySQL alebo .NET a PostgreSQL. Takže ak je to tak, pravdepodobne ste pomocou množstva prenosu, relácií a ďalších hodnôt vypočítali, aké množstvo výpočtového výkonu budete potrebovať (alebo podobne ako ja v minulosti, len dúfali, že to bude v poriadku).

So statickými stránkami prichádza úľava: žiadne zložitejšie vzorce, aproximácie a profesionálne dohady. Hostenie mnohých statických súborov je niečo, čo každý webový server dokáže ľahko. Najdôležitejším aspektom je, že server už nemusí prejsť sofistikovaným potrubím vybavovania požiadaviek pre každý prístup. Namiesto toho slúži iba statické súbory. A to je ľahké a rýchle.

Hostenie statických stránok je preto oveľa lacnejšie. Existujú desiatky služieb, ktoré vám umožňujú bezplatne hostiť vaše webové stránky alebo majú aspoň bezplatné štartovacie programy. Zahŕňajú:

  • Stránky GitHub
  • Netlify
  • Heroku
  • a ďalších globálnych a miestnych poskytovateľov. Môžete samozrejme využiť aj globálne hostiteľské služby webových stránok, ako sú Azure alebo AWS.

Rozhodol som sa zvoliť stránky GitHubu, pretože všetky moje úložiská sú už hostené na GitHube. Je tiež úplne zadarmo a podporuje vlastné domény druhej úrovne.

Ako môžem vytvoriť a nasadiť statickú stránku?

Nie je to však iba o hosťovaní. Mať stránky online je nevyhnutné, ale rovnako dôležité je myslieť na celý proces nasadenia. To znamená - ako sa budú generovať statické stránky a prenášať ich na server. Pri prvom zostavení môžete vygenerovať stránky v miestnom prostredí pomocou npx nuxt generatea kopírovanie a prilepenie statických súborov do hostiteľského priestoru pomocou protokolu FTP. Ale budete tento postup opakovať zakaždým, keď dôjde k zmene obsahu?

Proces nasadenia statickej stránky má tri časti:

  1. Spúšťač
  2. Stavať
  3. Nasadenie

Spúšťač

K novému zostaveniu musí dôjsť, keď dôjde k zmene obsahu alebo implementácie. To znamená, že kedykoľvek editor obsahu zverejní nový obsah v bezhlavom CMS alebo zmeníte zdrojový kód, je potrebné web znova zostaviť. Ako to však dosiahneme?

Spúšťač zmeny obsahu

Každý zrelý bezhlavý CMS obsahuje webhooky. Predstavujú oznámenie od služby k určitému typu akcie. Takže keď editor zverejní položku obsahu, bezhlavý CMS iniciuje oznámenie webhooku, ktoré sa odošle na definovanú adresu URL. V tomto prípade na zostavovací server, ktorý bude konať na základe upozornenia a znova zostaví web.

Ako ale vie server buildu, čo má robiť? Netuší, aký druh úložiska obsahu používate, a pravdepodobne by nepochopil všeobecné upozornenie webhooku. Z tohto dôvodu som do prostriedku pridal jednoduchú funkciu Azure, ktorá robí dve veci - najskôr skontroluje, či je pôvod upozornenia 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);}

(pozri kompletný súbor na GitHub)

a potom spustí zostavenie pomocou API servera zostavy:

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

(pozri kompletný súbor na 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. Ako zapnúť webovú stránku pomocou Vue.js a s minimálnym úsilím
  4. Ako zmiešať Headless CMS s webom Vue.js a platiť nulu
  5. Ako zaistiť zabezpečenie odosielania formulárov na webových stránkach API
  6. Vytváranie superrýchlych a bezpečných webových stránok pomocou CMS nie je nič veľké. Alebo je to?
  7. Ako vygenerovať statický web pomocou Vue.js v krátkom čase
  8. Ako rýchlo nastaviť proces zostavenia statickej stránky