前端工程化—部署

前端工程化—部署

使用脚手架建立初始项目，在本地搭建开发服务器进行项目开发。编码完成后，通过构建生成目标环境可用的代码，到此阶段的全部工做都属于开发环节。下一步的工做须要将代码部署到指定的环境中，方便进一步的联调测试工做。

在部署一些我的项目或者小团队的项目时，可能就是使用一些工具（如FTP上传工具）将文件上传到指定的服务器，而后交给运维人员发布上线便可。 这种发布方式简单快速，适合于我的项目或者小规模团队。可是对于用户量庞大的产品和拥有多种开发体系的技术团队，项目部署必须考虑协做、速度、安全等多方面因素，须要一套完整的流程实现项目部署。

先来看三个场景，从实际场景出发考虑前端部署须要注意哪些因素。

一、开发人员使用FTP工具上传代码到服务器。在测试阶段，测试人员提了一个Bug给开发同窗，开发人员修复完成后须要打开FTP工具，定位到指定目录而后上传代码。每次的Bug修复都须要重复这个过程。

二、多人协做的项目中，若是A同窗在修复一个Bug后没有将代码提交到代码仓库，其余开发在旧代码基础上进行改动，部署后发现A修复的Bug又出现了。

三、开发同窗失误将代码部署到其余应用的目录中，致使其余应用功能故障。

以上三个场景分别对应了部署流程中须要考虑的3个因素：速度、协做和安全。不一样结构、不一样规模的团队有着不一样的侧重点，小团队注重速度，大团队注重于协做和安全。

部署工具

针对场景1中的速度问题，咱们须要一个自动化的部署工具，工具必须可配置且操做简单。

• 可配置化：部署的目标服务器、路径信息与项目一一对应，可供运维人员部署。
• 操做简化：部署操做应该实现自动化，开发人员经过命令行或者可视化页面部署项目。 平台应该实现高度的自动化，开发人员只须要申请测试环境，而后点击部署项目便可进行测试。背后的服务器资源分配、项目构建、项目资源部署都无需开发人员关注。

部署流程

针对场景2中的写做问题，咱们须要一个完善的部署流程。 场景2中存在两个问题：沟通不及时致使代码不一样步；控制不严格致使部署内容错误覆盖。

首先咱们须要完善分支管理机制，多人开发的项目使用版本控制系统Git，本地的项目不能直接部署到服务器上，服务器部署是从Git仓库中拉取分支代码，要想在服务器上部署必须将代码推送到Git仓库中。

开发者能够申请多个平常环境部署本身的项目分支，可是要保证每一个项目的预发环境中只能有一个或者两个分支。发布必须以队列的形式进行发布，并且发布队列中只能有一个项目分支，从而保证项目内容不会被错误覆盖，都是最新的代码。 以Git为例，多人协做的项目中，都是从master分支建立feature进行开发，在平常环境中能够部署本身的feature分支，可是在预发部署时，必须merge master的代码，不然预发编译报错，发布必须从预发队列发布。 

简单来讲，部署队列就是将全部的部署请求按顺序排成一个队列，必须依次完成发布，且每次发布以前对流程进行卡点。必须保证预发功能验证经过，代码安全性扫描经过，code review经过，不然不容许项目发布。

权限体系

对于场景3中的安全问题，咱们须要创建权限体系。 开发人员只保留请求部署的权限，项目部署到哪台服务器、具体路径以及部署的环境等信息对于开发人员来讲是透明的，因此开发人员只须要关注业务便可。项目的部署到目标服务器和目标地址的过程应该使用代码或者脚本自动化完成，减小人为因素形成的误操做。

前端静态资源部署

在设计部署流程的时候，须要考虑到的是前端领域和其余领域最大的区别是前端资源都是静态资源，其中最特殊的就是HTML文件。

HTML文件是Web网站的惟一入口，全部其余资源必须由html文件直接或者简介引用才能被夹在。HTML的特殊性决定了它只能使用协商缓存，其余资源（Js、CSS等）应使用强缓存。这种缓存策略保证用户每次访问网站可以获取到最新的HTML资源，其余静态资源的更新可以直接体如今HTML中，只要HTML及时更新，就保证了全站资源的更新。能够在服务器中针对不一样的静态资源设置不一样的缓存策略。

HTML和其余静态资源应部署在不一样的域名下，有两个好处：

• 若是部署在统一域名下，请求静态资源（Js、CSS）时也会携带cookie，浪费资源，将这些静态资源部署在另外一个域名下，就解决了这个问题。
• Js、CSS等文件能够部署在CDN中，优化网站性能。

总结

以上所述都是前端工程化部署中须要考虑的一些基本问题，实施过程当中还有不少细节须要考虑，例如代码回滚机制、部署队列优先级处理、权限体系中的黑白名单策略等，可是在设计部署方案时，必定要考虑速度、协做和安全三个因素，而后设计最适合本身团队的具体方案。

参考资料

• 大公司里怎样开发和部署前端代码？

文章首发于个人Github：前端知识体系