【发布时间】：2020-10-03 23:01:58
【问题描述】：
我正在开发一个由静态站点生成器支持的网站，该生成器将构建大约 10 万个静态 HTML 页面。目前，我的工作流程是在本地机器上构建项目，并使用FTP工具将本地机器的输出文件夹（约40G）上传到远程生产服务器，这是一个漫长而痛苦的上传过程，可能需要大约24 小时。
我想知道是否有推荐的方法来设置更好的构建和部署流程以使其更快、更自动化？
【问题讨论】：
标签： next.js devops gatsby static-site
【发布时间】：2020-10-03 23:01:58
【问题描述】：
对于大量页面，构建时间一直是静态站点生成器的关键。解决方案是将生成一些页面的时间从构建时间推迟到请求时间。
例如，您只能statically generate 在构建时请求最多的前 10,000 个，以缩短构建时间。然后，在请求时间，您可以使用Next.js 和Incremental Static Regeneration 来构建静态页面。
假设有一个请求来自您尚未静态生成的其他 90,000 个页面之一。第一个请求将访问服务器以获取数据并生成静态页面，而不是获取静态站点。然后，该页面被缓存。当其他人访问此页面时，他们将看到静态页面（这比直接与服务器对话要快得多）。
您还可以使用revalidate flag 使缓存无效。例如，您可以使用revalidate: 60 让您的页面每分钟获取新信息。
使用此设置将 Next.js 应用程序部署到 Vercel 应该可以将您的构建和部署时间减少到不到 10 分钟，同时仍然可以创建一个高性能的静态站点。只需 git push 到您的存储库，GitHub integration 将为您构建和部署您的应用程序。不再需要 FTP！
【讨论】：
Gatsby 最近添加了一项功能来解决此问题（或尝试解决此问题），即called incremental builds。基本上，它会缓存您的所有数据，并且会重新部署更改的文件和代码更改。
实际上，这似乎是一项仅限于 Gatsby Cloud 或其他 CMS 的功能，不适用于自定义部署服务器。这是在Netlify 中实现它的示例。
在 Gatsby 的策略最近发生这些变化之前，您只需要在命令 deploy 中添加一个环境变量：
GATSBY_EXPERIMENTAL_PAGE_BUILD_ON_DATA_CHANGES=true gatsby build
请记住，此选项不适用于所有部署服务器。如果您在每个构建中从头开始重新生成 /public 文件夹，它将无法正常工作。
另一种选择是使用 Amazon 的大型 S3 机器并在部署完成后将其杀死。
【讨论】：