封面图
近期一直瞎忙，没拍到特别好看的风景
前端项目部署
一说到部署项目，一些没实际操作过部署流程的同学有可能会觉得部署项目这个事儿跟前端没什么太大的关系。其实这个是跟前端有没有关系并不重要，重要的是我们需要了解它是怎么样的一个流程，以及部署的方式和手段有哪些。
通常来讲，对于前端开发同学来讲，我们的项目一般采用的都是前后端分离的方式进行开发，前后端开发任务完成后，测试通过后便可开始部署项目。
对于前端来说，最简单的操作是将项目进行build，之后将编译好的静态资源发送给服务端同学，由服务端同学去操作后面的流程，通常来说我们将静态资源发送给服务端同学以后，部署的任务就跟我们没什么关系了。
那么，部署的过程到底是什么样子的呢？其实很简单，就是将build之后的静态资源放置到服务器指定的目录之下。
通常服务端使用的web服务器为Nginx居多，所以这里需要我们了解一些基本的Nginx的知识，当然需要识记很多关于配置项的知识点，以及Nginx的启停，检查配置项等各种命令。
最简单的部署方式
了解了项目部署的流程之后，其实我们就可以自己部署项目了，假设我们有自己的服务器，最简单的方式是使用FileZilla这个客户端工具进行上传。
如果你对linux 的命令比较熟悉，那么你就可以更方便的使用命令进行上传，通常可以使用scp命令将本地的资源直接上传到服务器指定的目录之下。而更方便的是，我们可以使用脚本来代替手动输入繁琐的命令。比如我经常用的简单的脚本：
#! /bash
# yarn build:
# docsify serve docs
#echo "\033[32m编译完成......\033[0m"
#cd dist
file="/*"
BASE_PATH=`pwd`
echo $BASE_PATH$file
# echo $BASE_PATH$page
# scp -r $BASE_PATH$file root@152.146.112.199:/export/webserver/html
scp -r $BASE_PATH$file root@152.146.112.199:/usr/share/nginx/html/interview
echo "\033[32m---index页面--上传成功......\033[0m"
# rm -rf dist
# echo "\033[32mdist文件夹已删除......\033[0m"%持续集成 cd/ci
虽然采用手动上传或者执行脚本的方式已经能够解决我们发布项目的需求，但是还是不够完善，我们需要能够让这个流程自动化才好。
一种简单的方式是使用git的钩子方法。我们可以在服务器上建立代码仓库，然后在git的钩子方法中添加脚本，每次监听到push这个动作后，就对代码进行编译，将编译之后的资源移动到指定的目录。
但是这种方式个人觉得只适用于小型的公司，并且只能用于测试环境的持续集成。
其次，我们可以借助deploy-cli-service来提供一站式服。
首先，安装npm服务。
yarn add deploy-cli-service -d配置scripts脚本。
"build-deploy-config":"deploy-cli-service i"先生成配置文件:
根据选择的环境配置部署参数、项目名称、密钥地址、打包命令、服务地址、端口、用户名、密码、本地打包目彔和配置部署目彔等。部署后在项目根目彔下生成deploy.config.js文件。
我们也可以手动创建该文件，只要字段能对应上即可。在部署文件初始化时，可以根据选择的环境生成相应的配置字段。有了配置文件之后，就可以用下面的命令部署服务了。
deploy-cli-service deploy --mode
"deploy:dev":"deploy-cli-service deploy --mode dev"
"deploy:test":"deploy-cli-service deploy --mode test"
"deploy:prod":"deploy-cli-service deploy --mode prod"其他方式
部署的工具有很多，比如：Java项目通常比较喜欢用Jenkins, 其他如： docker,k8s等等，以及阿里云或者腾讯云提供的持续集成的能力。
在中型或者大型企业中，项目的部署过程通常叫做跑流水线，本质上还是将静态资源复制或移动到服务器指定的目录下。
只不过将原来需要手动执行的命令提前配置到了指定的脚本或命令中，仅此而已。
附：Nginx常用命令
