跳到主要内容

前端部署概念

CI​

CI(持续集成)，把代码集成到一个仓库里 在源代码变更后自动检测、拉取、构建和（在大多数情况下）进行单元测试的过程。持续集成是启动管道的环节（尽管某些预验证 —— 通常称为 上线前检查(pre-flight checks) —— 有时会被归在持续集成之前）。

持续集成的目标是快速确保开发人员新提交的变更是好的，并且适合在代码库中进一步使用。（针对提交代码）

持续集成的基本思想是让一个自动化过程监测一个或多个源代码仓库是否有变更。当变更被推送到仓库时，它会监测到更改、下载副本、构建并运行任何相关的单元测试。

CD​

持续交付（CD）通常是指整个流程链（管道），它自动监测源代码变更并通过构建、测试、打包和相关操作运行它们以生成可部署的版本，基本上没有任何人为干预。（针对完整产物）

持续交付在软件开发过程中的目标是自动化、效率、可靠性、可重复性和质量保障（通过持续测试）。

持续交付包含持续集成（自动检测源代码变更、执行构建过程、运行单元测试以验证变更），持续测试（对代码运行各种测试以保障代码质量），和（可选）持续部署（通过管道发布版本自动提供给用户）。

HTML 文件部署​

HTML 文件已经被上传到回源服务器上了，可以通过 CDN 来访问 HTML 文件了。前端页面部署工作是不是就结束了？显然没这么简单。 CDN 缓存有效地提升了访问速度，但是也带来了文件无法及时更新的问题。一般通过 Hash 字符串的方式来解决这个问题。在每个文件名后面加一个 hash 字符串，每次发布的静态资源的文件名都不一样，相应的访问 URL 也不一样，这样就不会命中缓存。这种方式对 CSS 和 JS 文件很好使，但是对 HTML 文件就不合适了。CSS 和 JS 文件名是写在 HTML 文件中的，文件名的替换由 Webpack 自动完成的。用户访问某个网站时，一般会重定向到主页面。也就是说，HTML 文件名一般是重定向时决定的，需要在重定向的路由中配置，比如 nginx 配置文件，替换工作基本手动完成。每次发布后都需要手动修改 nginx 配置，才能使用户访问最新的 HTML 文件，这显然是不可行的。所以，Hash 字符串的办法不适用于 HTML 文件。 因此，HTML 文件需要另外部署。（不能和 js 和 css 文件部署按照相同策略部署）

与服务端混合部署​

早期的一种解决方案是把 HTML 文件放到服务端工程里面，与服务端服务一起部署。服务端服务是一个运行的服务，可以提供对 HTML 文件的访问。每次需要访问新的 HTML 文件时，把服务端工程里面的 HTML 文件替换成新的文件，然后再重启服务就可以了。 混合部署的缺点：

  • 发布速度慢，受制于后端服务的发布
  • 前后端工程耦合，不利于项目的维护，也不利于部署管理

独立部署​

单独给前端页面起一个页面服务，同时提供管理服务来管理这些页面服务。该页面服务只提供访问 HTML 文件的功能，不实现其他业务功能。 独立部署的优点：

  • 发布速度快
  • 功能聚焦，便于管理 Goofy 就是提供这种独立部署功能的前端部署平台。后期，Goofy 还会集成 CDN 上传功能，以取代上面那种麻烦的 CDN 上传操作。

提前上传 CDN​

在写 CSS 的时候，我们会用到一些图片。一般的做法是，先把图片上传到 CDN，得到 CDN 访问 URL，然后再把 URL 写到 CSS 里面。也就是说，我们需要在代码发布之前就完成一些 CDN 上传的操作。可以通过 CDN 上传平台 来完成。