Як швидко налаштувати процес збірки для статичного сайту

У вас є статичний сайт, реалізований і готовий бачити світ, але де його розміщувати? Як правильно вибрати платформу та спланувати набір статичних файлів? Як ви можете забезпечити, щоб веб-сайт автоматично відновлювався щоразу, коли ви змінюєте його вміст?

У цій статті я покажу вам, як створити статичний сайт, налаштувати автоматичний процес збірки, який ініціюється змінами вмісту, та розгорнути сайт на загальнодоступному сервері.

Вступ

У попередніх статтях я пояснив, як створити динамічний веб-сайт JavaScript із вмістом із безголової CMS Kentico Cloud. Потім я показав вам, як перетворити його на статичний сайт, щоб покращити продуктивність, безпеку та SEO. Отже, настав час згенерувати цей сайт і викласти його в Інтернеті, щоб його побачив увесь світ.

Створення статичного сайту

Кожен статичний генератор сайтів дозволяє створювати сайт локально, не створюючи всіх файлів після кожної зміни файлу. Якщо ви стежили за моїми статтями, у вас є сайт на Vue.js, який перетворений для використання Nuxt.js як основи, але все одно вимагає сервера розробки для обробки запитів веб-сайту. Щоб створити статичні файли, виконайте таку команду:

npx nuxt generate

Відкрийте distпапку в кореневій частині проекту, щоб знайти згенеровані файли, і переконайтеся, index.htmlщо ваш веб-сайт правильно сформовано. Я маю звичку також перевіряти дочірні сторінки, де я знаю, що є якийсь вміст із безголової системи управління вмістом, наприклад сторінки блогу. Якщо ви бачите вміст у формі HTML, ви перемогли!

Де я повинен розміщувати статичний сайт?

Це, мабуть, наступне запитання, яке ви задаєте після створення всіх файлів. Якщо ви відновлюєте сайт, а ваш старий веб-сайт все ще перебуває в мережі, ви, ймовірно, думаєте використовувати того самого постачальника для статичного сайту. Це чудово. Однак якщо ваш старий сайт був побудований на основі традиційної системи управління вмістом або іншої мови програмування, можливо, вам доведеться добре подумати.

Ваш поточний простір хостингу масштабується відповідно до вимог іншої системи або призначений для підтримки конкретних налаштувань, таких як PHP та MySQL або .NET та PostgreSQL. Отже, якщо це так, ви, ймовірно, використовували обсяг трафіку, сеансів та інших значень, щоб підрахувати, яка обчислювальна потужність вам знадобиться (або, як я раніше, просто сподівався, що це буде нормально).

З статичними сайтами з’являється полегшення: немає більш складних формул, наближень та професійних здогадок. Розміщення купу статичних файлів - це те, що кожен веб-сервер може зробити легко. Найважливішим аспектом є те, що серверу більше не потрібно проходити складний конвеєр обробки запитів для кожного звернення. Натомість він просто обслуговує статичні файли. І це легко і швидко.

Тому розміщення статичних сайтів набагато дешевше. Існують десятки сервісів, які дозволяють розміщувати ваші веб-сайти безкоштовно або принаймні мати безкоштовні початкові плани. Вони включають:

  • Сторінки GitHub
  • Netlify
  • Героку
  • та інших глобальних та місцевих постачальників. Звичайно, ви також можете скористатися послугами глобального хостингу веб-сайтів, такими як Azure або AWS.

Я вирішив вибрати сторінки GitHub, оскільки всі мої сховища вже розміщені на GitHub. Він також повністю безкоштовний і підтримує власні домени 2-го рівня.

Як створити та розгорнути статичний сайт?

Але справа не лише в хостингу. Розміщення сторінок в Інтернеті є важливим, але так само важливо продумати весь процес розгортання. Тобто - як будуть генеруватися і транспортувати статичні сторінки на сервер. Для першої збірки ви можете генерувати сторінки у вашому локальному середовищі, використовуючи npx nuxt generateта копіюючи і вставляючи статичні файли у ваш хостинговий простір за допомогою FTP. Але чи збираєтеся ви повторювати цей процес щоразу, коли змінюється вміст?

Процес розгортання статичного сайту складається з трьох частин:

  1. Тригер
  2. Збірка
  3. Розгортання

Тригер

Нова збірка повинна відбуватися, коли відбувається зміна вмісту або реалізації. Це означає, що всякий раз, коли редактор вмісту публікує новий вміст у безмежній системі управління вмістом або ви змінюєте вихідний код, веб-сайт повинен перебудувати. Але як ми цього можемо досягти?

Тригер зміни вмісту

Кожна зріла безголова система управління вмістом має веб-хуки. Вони представляють повідомлення від послуги до певного типу дії. Отже, коли редактор публікує елемент вмісту, безголовна CMS ініціює сповіщення веб-хука, яке надсилається на визначену URL-адресу. У цьому випадку на сервер збірки, який діятиме за сповіщенням та відновлюватиме сайт.

Але як сервер збірки знає, що робити? Ну, він поняття не має, який тип сховища ви використовуєте, і, мабуть, не зрозумів би загального сповіщення про веб-хук. З цієї причини я додав просту функцію Azure посередині, яка робить дві речі - спочатку перевіряє, чи джерелом сповіщення є 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);}

(див. повний файл на GitHub)

а потім запускає збірку за допомогою 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']}` },
...

(див. повний файл на 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