前端静态站点构建_如何快速设置静态站点的构建过程

最新推荐文章于 2024-08-28 11:45:14 发布

cumian8165

最新推荐文章于 2024-08-28 11:45:14 发布

阅读量635

点赞数

文章标签： python java 编程语言大数据 vue ViewUI

原文链接：https://www.freecodecamp.org/news/how-to-quickly-set-up-a-build-process-for-a-static-site-1a6e7923e105/

版权

前端静态站点构建

by Ondřej Polesný

通过OndřejPolesný

如何快速设置静态站点的构建过程 (How to quickly set up a build process for a static site)

You have a static site all implemented and ready for the world to see, but where should you host it? How do you select the right platform and plan for a set of static files? How can you ensure that the website will automatically regenerate whenever you change its content?

您有一个静态站点，所有站点都已实现并且可以向世界展示，但是应该在哪里托管呢？您如何选择正确的平台并计划一组静态文件？您如何确保更改内容后网站将自动重新生成？

In this article, I will show you how to generate a static site, set up an automatic build process that is triggered by content changes and deploy the site to a public facing server.

在本文中，我将向您展示如何生成静态站点，如何设置由内容更改触发的自动构建过程以及如何将该站点部署到面向公众的服务器。

介绍 (Introduction)

In previous articles, I explained how to build a dynamic JavaScript website with content from a headless CMS Kentico Cloud. Then I showed you how to convert it into a static site to help performance, security, and SEO. So now it’s time to get that site generated and push it online for the whole world to see.

在之前的文章中，我解释了如何使用无头CMS Kentico Cloud的内容构建动态JavaScript网站。然后，我向您展示了如何将其转换为静态网站，以提高性能，安全性和SEO。因此，现在是时候生成该网站并将其在线发布，以供全世界查看。

生成静态站点 (Generating a static site)

Every static site generator lets you build the site locally without generating all files after every single file change. If you followed my articles, you have a site on Vue.js that is converted to use Nuxt.js as a framework but still requires a development server to handle website requests. To generate the static files, run the following command:

每个静态站点生成器都使您可以在本地构建站点，而无需在每次更改单个文件后生成所有文件。如果您按照我的文章进行操作，则会在Vue.js上拥有一个网站，该网站已转换为使用Nuxt.js作为框架，但仍需要开发服务器来处理网站请求。要生成静态文件，请运行以下命令：

npx nuxt generate

Open the dist folder in the root of your project to find the generated files and check out index.html to make sure your website generates correctly. I have a habit of also checking the child pages where I know there is some content from a headless CMS, like a Blog page. If you see the content in HTML form, you are a winner!

打开项目根目录中的dist文件夹以查找生成的文件，并检出index.html以确保您的网站正确生成。我有一种习惯，也要检查子页面，这些子页面我知道无头CMS有一些内容，例如Blog页面。如果您以HTML形式看到内容，那您将是赢家！

我应该在哪里托管静态网站？ (Where should I host a static site?)

That is probably the next question you ask after generating all the files. If you are rebuilding a site and your old website is still online, you are probably thinking of using the same provider for the static site. That’s perfectly fine. However, if your old site was built on top of a traditional CMS or another programming language, you may need to think twice.

生成所有文件后，这可能是您要问的下一个问题。如果您正在重建站点，而您的旧站点仍然在线，则您可能正在考虑对静态站点使用相同的提供程序。很好但是，如果您的旧站点是建立在传统CMS或另一种编程语言之上的，则可能需要三思而后行。

Your current hosting space is scaled to fit the requirements of another system or designed to support a specific setup, like PHP and MySQL or .NET and PostgreSQL. So if that is the case, you probably used the amount of traffic, sessions, and other values to calculate which amount of computing power you will need (or like me in the past, just hoped it would be OK).

您当前的托管空间已扩展以满足其他系统的要求，或旨在支持特定的设置，例如PHP和MySQL或.NET和PostgreSQL。因此，如果是这种情况，您可能会使用流量，会话和其他值的数量来计算所需的计算能力(或者像我以前一样，只是希望可以)。

With static sites comes relief: no more complicated formulas, approximations, and professional guesswork. Hosting a bunch of static files is something every web server can do easily. The most important aspect is that the server no longer needs to go through the sophisticated pipeline of request handling for each hit. It just serves static files instead. And that’s easy and fast.

使用静态站点可以缓解：不再需要复杂的公式，近似值和专业的猜测。每个Web服务器都可以轻松地托管一堆静态文件。最重要的方面是，服务器不再需要为每个匹配项通过复杂的请求处理管道。它只是提供静态文件。这既简单又快速。

Hosting static sites is therefore much cheaper. There are dozens of services that allow you to host your websites for free or at least have free starter plans. They include:

因此，托管静态站点要便宜得多。有数十种服务可让您免费托管您的网站，或者至少拥有免费的入门计划。它们包括：

GitHub pages
GitHub页面
Netlify
Netlify
Heroku
Heroku
and other global and local providers. You can, of course, use global website hosting services like Azure or AWS too.
以及其他全球和本地提供商。当然，您也可以使用全球网站托管服务，例如Azure或AWS。

I decided to choose GitHub pages as all of my repositories are already hosted on GitHub. It is also completely free and supports custom 2nd level domains.

我决定选择GitHub页面，因为我的所有存储库都已托管在GitHub上。它也是完全免费的，并支持自定义二级域。

如何构建和部署静态站点？ (How do I build and deploy a static site?)

But it’s not just about hosting. Having the pages online is essential, but it is just as important to think about the whole process of deployment. That is — how are the static pages going to be generated and transported to the server. For the first build, you can generate pages in your local environment using npx nuxt generate and copy-paste the static files to your hosting space via FTP. But are you going to repeat that process every time there is a content change?

但这不仅仅是托管。使页面联机至关重要，但是考虑整个部署过程也同样重要。也就是说，静态页面将如何生成并传输到服务器。对于第一个构建，您可以使用npx nuxt generate在本地环境中生成页面，然后通过FTP npx nuxt generate静态文件并将其复制粘贴到您的托管空间中。但是，每次内容更改时，您是否要重复该过程？

The process of deploying a static site has three parts:

部署静态站点的过程分为三个部分：

Trigger
触发
Build
建立
Deployment
部署方式

触发 (Trigger)

A new build needs to happen when either a content or implementation change occurs. That means whenever a content editor publishes new content in a headless CMS, or you change the source code, the website needs to rebuild. But how do we achieve that?

当内容或实现发生更改时，需要进行新的构建。这意味着无论何时内容编辑器在无头CMS中发布新内容，或者您更改源代码，网站都需要重建。但是，我们如何实现这一目标？

内容变更触发 (Content change trigger)

Every mature headless CMS features webhooks. They represent service-to-service notification about a certain type of action. So when an editor publishes a content item, the headless CMS initiates a webhook notification that is sent to a defined URL. In this case to a build server that will act upon the notification and rebuild the site.

每个成熟的无头CMS都具有webhooks 。它们表示有关某种类型的操作的服务到服务的通知。因此，当编辑者发布内容项时，无头CMS会启动发送到已定义URL的Webhook通知。在这种情况下，构建服务器将根据通知进行操作并重建站点。

But how does the build server know what to do? Well, it has no idea what kind of content storage you use and would probably not understand the generic webhook notification. For that reason I added a simple Azure function in the middle that does two things — first, it checks that the notification’s origin is Kentico Cloud:

但是构建服务器如何知道该怎么办？好吧，它不知道您使用哪种类型的内容存储，并且可能无法理解通用的Webhook通知。出于这个原因，我在中间添加了一个简单的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);}

(see the complete file on GitHub)

(请参阅GitHub上的完整文件 )

and then triggers the build using the API of the build server:

然后使用构建服务器的API触发构建：

request.post({ url: "https://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']}` },

...

(see the complete file on GitHub)

(请参阅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.

我知道我知道，Azure在创建功能之前会先要求您提供信用卡。但是您可以使用Webtask.io ，它是完全免费的。在之前的一篇文章中，我解释了如何在其中创建一个简单的函数。

代码更改触发器 (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.

使用代码，过程变得更加容易。构建服务器通常提供与GitHub的直接集成，因此仅需使用GitHub授权构建服务器即可。当您将代码更改推送到远程存储库中时，构建服务器会自动接收信息，并根据其配置触发新的构建。

建立 (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?

我知道，“构建服务器”一词听起来如此复杂且昂贵。但是，当您考虑它时，构建服务器唯一需要做的就是生成页面并进行部署。正是您使用一个npx命令和复制粘贴操作手动完成的操作。这并不难，不是吗？

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:

那么，如何确定要使用哪个构建服务器？首先，您需要选择是要在服务器上本地运行构建还是在第三方服务上远程运行构建。我没有可以用于此目的的本地服务器，因此我决定使用第三方服务。这些服务包括：

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?

但是，让我们回到构建服务器。我选择了Travis CI，因为它是同事推荐给我的。我们将其用于公司中的许多GitHub项目。那么设置需要多长时间？

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.

最初，我期望一个复杂的UI在Travis内配置构建的各个方面(还记得VSTS在线吗？)，所以找出所有这些都放在一个文件中是一种解脱。因此，您需要做的第一件事是在项目的根目录中创建一个文件＃.travis.yml＃。该文件定义了构建过程中发生的事情。

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.

您会看到它很容易理解。首先，我指示NPM安装所有必需的软件包，作为运行构建的先决条件。然后将所有静态文件生成到dist文件夹中-使用Nuxt时这是默认设置。我还包括了packages.json文件的预览，该文件定义了构建脚本。请注意，我还将CNAME文件复制到dist目录-这告诉GitHub Pages我使用的是自定义域，而不是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.

最后是整个过程的最后一部分。我们已经生成了文件，现在我们需要将它们传输到我们的托管空间，就像使用FTP之前一样。这是构建服务器可以为您完成的另一件事。

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:

如前所述，我选择了GitHub Pages作为宿主，选择Travis CI作为构建服务器。 Travis提供了许多用于自动部署的选项，包括GitHub Pages，因此该配置很容易。看一下部署配置：

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.

Local-dir定义了我生成的静态页面的位置， target-branch标记了要部署到的GitHub存储库中的一个分支，而pages是GitHub Pages的Travis提供程序的名称。要成功部署，您还需要生成并提供一个github-token 。您会看到构建配置中只有一个变量，因为该文件位于公共存储库中。令牌的值存储在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.

在本系列文章中，我解释了如何使用“内容即服务”(CaaS)构建网站来存储您的内容，如何通过不使用任何数据库来确保您的网站安全以及如何确保仍然使用该网站包含动态功能，例如表单提交。

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

祝您新的静态网站好运，并拥有#staticNewYear ！