So richten Sie schnell einen Erstellungsprozess für eine statische Site ein

Sie haben eine statische Site implementiert und sind für die ganze Welt bereit, aber wo sollten Sie sie hosten? Wie wählen Sie die richtige Plattform aus und planen eine Reihe statischer Dateien? Wie können Sie sicherstellen, dass die Website automatisch neu generiert wird, wenn Sie ihren Inhalt ändern?

In diesem Artikel werde ich Ihnen zeigen, wie Sie eine statische Site generieren, einen automatischen Erstellungsprozess einrichten, der durch Inhaltsänderungen ausgelöst wird, und die Site auf einem öffentlich zugänglichen Server bereitstellen.

Einführung

In früheren Artikeln habe ich erklärt, wie eine dynamische JavaScript-Website mit Inhalten aus einer kopflosen CMS Kentico Cloud erstellt wird. Dann habe ich Ihnen gezeigt, wie Sie es in eine statische Site konvertieren können, um Leistung, Sicherheit und SEO zu verbessern. Jetzt ist es an der Zeit, diese Website zu generieren und online zu schalten, damit die ganze Welt sie sehen kann.

Generieren einer statischen Site

Mit jedem statischen Site-Generator können Sie die Site lokal erstellen, ohne nach jeder einzelnen Dateiänderung alle Dateien zu generieren. Wenn Sie meinen Artikeln gefolgt sind, haben Sie eine Site auf Vue.js, die konvertiert wurde, um Nuxt.js als Framework zu verwenden, aber dennoch einen Entwicklungsserver benötigt, um Website-Anfragen zu bearbeiten. Führen Sie den folgenden Befehl aus, um die statischen Dateien zu generieren:

npx nuxt generate

Öffnen Sie den distOrdner im Stammverzeichnis Ihres Projekts, um die generierten Dateien zu finden, und überprüfen Sie, index.htmlob Ihre Website korrekt generiert wurde. Ich habe die Angewohnheit, auch die untergeordneten Seiten zu überprüfen, auf denen ich weiß, dass Inhalte von einem kopflosen CMS vorhanden sind, z. B. eine Blog-Seite. Wenn Sie den Inhalt in HTML-Form sehen, sind Sie ein Gewinner!

Wo soll ich eine statische Site hosten?

Dies ist wahrscheinlich die nächste Frage, die Sie nach dem Generieren aller Dateien stellen. Wenn Sie eine Website neu erstellen und Ihre alte Website noch online ist, denken Sie wahrscheinlich daran, denselben Anbieter für die statische Website zu verwenden. Das ist vollkommen in Ordnung. Wenn Ihre alte Site jedoch auf einem herkömmlichen CMS oder einer anderen Programmiersprache basiert, müssen Sie möglicherweise zweimal überlegen.

Ihr aktueller Hosting-Bereich wird an die Anforderungen eines anderen Systems angepasst oder für die Unterstützung eines bestimmten Setups wie PHP und MySQL oder .NET und PostgreSQL ausgelegt. Wenn dies der Fall ist, haben Sie wahrscheinlich die Menge an Datenverkehr, Sitzungen und anderen Werten verwendet, um zu berechnen, welche Menge an Rechenleistung Sie benötigen (oder wie ich in der Vergangenheit gehofft haben, dass dies in Ordnung ist).

Mit statischen Sites kommt Erleichterung: Keine komplizierten Formeln, Annäherungen und professionellen Vermutungen mehr. Das Hosten einer Reihe statischer Dateien kann jeder Webserver problemlos durchführen. Der wichtigste Aspekt ist, dass der Server nicht mehr für jeden Treffer die ausgeklügelte Pipeline der Anforderungsbearbeitung durchlaufen muss. Stattdessen werden nur statische Dateien bereitgestellt. Und das ist einfach und schnell.

Das Hosten statischer Sites ist daher viel billiger. Es gibt Dutzende von Diensten, mit denen Sie Ihre Websites kostenlos hosten oder zumindest kostenlose Starterpläne haben können. Sie beinhalten:

  • GitHub-Seiten
  • Netlify
  • Heroku
  • und andere globale und lokale Anbieter. Natürlich können Sie auch globale Website-Hosting-Dienste wie Azure oder AWS verwenden.

Ich habe mich für GitHub-Seiten entschieden, da alle meine Repositorys bereits auf GitHub gehostet sind. Es ist auch völlig kostenlos und unterstützt benutzerdefinierte Domains der 2. Ebene.

Wie erstelle und stelle ich eine statische Site bereit?

Es geht aber nicht nur um Hosting. Es ist wichtig, die Seiten online zu haben, aber es ist genauso wichtig, über den gesamten Bereitstellungsprozess nachzudenken. Das heißt - wie werden die statischen Seiten generiert und zum Server transportiert? Für den ersten Build können Sie Seiten in Ihrer lokalen Umgebung generieren npx nuxt generateund die statischen Dateien per FTP in Ihren Hosting-Bereich kopieren und einfügen. Aber werden Sie diesen Vorgang jedes Mal wiederholen, wenn sich der Inhalt ändert?

Der Prozess zum Bereitstellen einer statischen Site besteht aus drei Teilen:

  1. Auslösen
  2. Bauen
  3. Einsatz

Auslösen

Ein neuer Build muss erfolgen, wenn entweder eine Änderung des Inhalts oder der Implementierung erfolgt. Das heißt, wenn ein Inhaltseditor neue Inhalte in einem kopflosen CMS veröffentlicht oder Sie den Quellcode ändern, muss die Website neu erstellt werden. Aber wie erreichen wir das?

Auslöser für Inhaltsänderungen

Jedes ausgereifte kopflose CMS verfügt über Webhooks. Sie stellen eine Service-zu-Service-Benachrichtigung über eine bestimmte Art von Aktion dar. Wenn ein Editor ein Inhaltselement veröffentlicht, initiiert das kopflose CMS eine Webhook-Benachrichtigung, die an eine definierte URL gesendet wird. In diesem Fall an einen Build-Server, der auf die Benachrichtigung reagiert und die Site neu erstellt.

Aber woher weiß der Build-Server, was zu tun ist? Nun, es hat keine Ahnung, welche Art von Inhaltsspeicher Sie verwenden, und würde die allgemeine Webhook-Benachrichtigung wahrscheinlich nicht verstehen. Aus diesem Grund habe ich in der Mitte eine einfache Azure-Funktion hinzugefügt, die zwei Funktionen ausführt: Erstens wird überprüft, ob der Ursprung der Benachrichtigung Kentico Cloud ist:

...
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);}

(siehe die komplette Datei auf GitHub)

und löst dann den Build mithilfe der API des Build-Servers aus:

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

(siehe die komplette Datei auf 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