分类
前端项目的部署根据工作的特点可以分为首次部署，常规部署和优化部署。
首次部署
首次部署，指的是生产环境仅仅是一个有着公网网络服务的操作系统，在这基础之上通过部署，使得可在浏览器输入网址访问到内容的过程。
首次部署的特点是从零开始，因此涉及的面非常广，该过程往往需要系统架构师，系统运维工程师，系统研发工程师等协同工作。从前端项目的特点来看，其核心的问题是：需要部署的项目包需要HTTP服务器提供怎样的服务？这决定了安装部署的HTTP服务器应该有怎样的功能以及相关的配置。这个问题在下文中还会提及。
常规部署
常规部署，指的是每次开发迭代后，将新的功能更新到特定服务器的过程。
常规部署的本质就是“复制”部署包，“粘贴”到服务器上。该过程操作简单，但是大量重复着内容相同的简单工作是低效率的，因此，针对常规部署，有着很多自动化的工具。借由合适的工具，可以将简单的常规部署，从简单变成更简单。
优化部署
优化部署，指的是为了提高服务的性能，由系统架构师和研发工程师进行研究以及试验后，提供出一套方案，根据方案进行调整的过程。
优化部署的特点是目的性强。每一次显式的优化部署（如果优化的内容在研发的代码中已经完全实现，这时候对于部署而言仅仅就是常规部署，也可被理解为隐式优化部署）总是带有其目的性，或者是为了解决问题，或者是为了提高某方面的性能，总是可以被度量的。优化部署后应该跟踪效果，如果没能到达预期时，必须跟进优化，如果确认没有效果，必须回滚设置方便再次调整。
物理URL和路由
在研发人员的日常对话中，URL、路由、API这些词是可以混用的，这个时候它们在语境中仅仅表示一个特定字符串，拿到这个特定字符串之后，经过调用就可以拿到数据或者看到页面，进而可以开始下一步的操作。但是，在部署的时候，URL、路由应该有各自严格的含义和边界。
URL
URL是统一资源定位符，用来描述互联网上一个特定资源的位置。
物理URL
看到URL的解释，可以知道URL可以定位一个特定的资源，但是并没有说明该特定的资源是否对应的是一个真实的物理文件。这是由于URL概念出现的时期互联网资源都是静态的，自然无需特别说明，随着互联网的发展出现了动态资源，URL的含义被放大了。仅在本文，将定位的特定资源就是对应真实的物理文件的URL称为物理URL。
路由
上面说到，URL的含义被放大了，URL可以定位到动态资源。这其实是Web服务中路由的能力。具体表现为的一个URL，通过其主机地址找到对应的Web服务，然后Web服务将之后的URL部分视为字符串，寻找并提供匹配该字符串的服务。
回到首次部署的那个核心问题，明确了项目是使用物理URL方式还是路由方式访问，就明确了HTTP服务是提供静态资源服务还是代理服务（由HTTP服务器后端的Web服务器处理）。
前后分离项目 VS 前后捆绑项目
现在越来越流行前后端项目分离，简单的看一下两者的优缺点以及对部署的影响。
分离的好处
- 独立项目，可以用更合适的工具提高研发效率
- 去耦合，有利于团队协作
分离的缺点
- 运用服务端渲染的难度增加
捆绑的好处
- 运用服务端渲染，加载更快方便seo
- 有利于全局思考
捆绑的缺点
- 对于研发人员的要求高，必须什么都要会
- 效率低
影响
前后分离项目才存在如何部署前端项目的问题，反之是前后捆绑的项目，毫无疑问是通过HTTP服务器通过代理让Web服务器提供服务，因此只要对应的按照后端项目部署即可完成对前端的部署。
部署包的目录
到底部署包长什么样呢？里面的目录结构有没有统一的命名规范和层次结构呢？首先，思考一下开发源码包的目录设计，为什么源码包最终会是那个样子呢？显然，是研发人员为了方便分区块存放代码，同时代码之间需要相互引用，它们往往是使用相对路径的进行关联。使用本地文件系统的路径和使用物理URL本质上是相同的，物理URL不正是服务器文件系统里特定的一些路径吗？因此，如果生成代码包的过程没有修改源码中关于相对路径的代码，则部署包的目录结构等同于源码包，随着修改相对路径的代码越来越多，则部署包和源码包的目录结构就差距越大（使用webpack打包，默认情况下会把所有资源放置到同一级目录里）。
部署的工具
关于部署包目录的思考，真正的意义是在常规部署时选择怎么样的工具进行“复制粘贴”。工具大体上分为两类，一类是git这样的版本控制工具，一类是FTP，rsync这类的文件系统工具。版本控制工具的好处是自动化，可以控制版本的前进回滚，文件系统工具的好处是精细化文件增量，复制文件的过程完全由自己控制。如果部署包的文件结构越复杂，那么手动复制粘贴文件的效率极低，如果由于目录复杂的无法采用增量部署，那么采用文件系统工具的意义就越小，采用版本控制工具的好处就越明显。因此，可以首选采用版本控制工具管理部署包。只需要在部署的目录里拉取新版本的数据即可完成替换工作，同时也具备了版本的管理能力。
部署应遵循的原则
独立原则
任何的部署都应该是独立的，即使有多个部署任务，也不能进行一半后就直接开始下一个，尤其是做整体构建或者自动化设计时，尤为应该保持单个部署的独立性。
高效原则
任何部署都应该朝着高效部署的方向发展，应该要简化部署的过程，尽可能的使用上自动化的手段。
正确性原则
任何的部署意味着有新的改动，而新的改动应该是正确的，也不能影响旧功能（相应的测试工作应该及时跟上）