在很久之前，我接到任务，要帮忙协助前端做团队建设和流程优化(重点在于代码review上），当时出过一版方案来做静态资源的部署——js、css、imgs。但由于当时对前端的参与度不够，方案并不合适。于是废弃了。
先来说下前端的流程，接到任务，开个feature分支写代码，完成后使用grunt打包到dest目录下，同时通过设置host可以本地进行调试。本地测试没问题，把代码全部推到远端（注意：包含了dest文件夹的内容），之后再测试服务器上使用一个shell脚本，把代码从git仓库的dest文件下cp到nginx的目录下。然后就能在测试环境测试了。
测试完毕之后，正常来说使用git和gitlab做代码管理的情况下，应该是提一个merge request出来，然后其他同学review代码，没问题之后进行合并。这个阶段问题就来了，因为dest目录下的代码基本上是完全做了更改，包括二进制文件，会产生一个很大的diff，大到在gitlab上根本无法查看。
因此常用的做法是在windows上通过git GUI的工具过滤掉dest文件进行diff，这么做也属正常，毕竟能review代码了，另外的问题在于每次merge都会产生大量冲突，因为dest下的内容都做了更改。
有读者可能说了，那把dest文件直接git ignore掉不就行了，源码有，在测试服务器上重新生成一份dest，然后cp到nginx的目录中。这个其实就是我一开始采用的方案，改动之前的shell脚本，加入重新grunt build的逻辑，构建dest下的文件。实话实说，shell的可读性真的不高，但要改成我的方案也没什么问题。但是需要重新npm install包，毕竟不知道有没有新的依赖。这样也可行，就是每次发测试环境的时候需要多等一会。
但是另外一个问题是，dest目录的另外一个作用是分发最终的js、css。分发是指把打包好的静态文件放到cdn上去。因此可能需要在部署的服务器上重复打包的逻辑。这也是之前的其他同学不太喜欢这个方案的原因，他更相信本机测试过的代码，通过dest发布之后是可信的。事实上最终也还是通过dest来做的。
最近参与到前端开发中之后意识到，其实git push本地测试好的dest目录到远端，然后登录到测试服务器上，运行shell脚本，cp文件到nginx目录，这一套流程并不是必须的。对于长期搞服务器端开发的人来说，要把代码放到放到测试服务器的nginx中，完全不需要通过git这个渠道来传递。直接scp不就完事了。
上面的一系列流程不就是干了这么一个事，中间还产生了副作用(dest冲突)。于是搜了下grunt scp，看了下grunt的语法，新建一个test_dest专门存放用于测试的构建好的代码，本地测试也行，需要远程测试的话就直接部署到测试服务器上。grunt scp的研究过程就不说了，只说一句，不懂的地方看源码吧，文档太少，直接贴配置吧:
代码语言：javascript复制 // 需要安装grunt-scp
// 省略的grunt配置xxxxxxx
scp: {
options: {
username: 'root',
host: '127.0.0.1',
privateKey: require('fs').readFileSync(process.env.HOME '/.ssh/id_rsa') //直接读取用户家目录下的私钥
},
js_css: {
files: [{
cwd: 'test_dest/',
src: ['**/*.js', '**/*.{css, html,shtml,ico}'],
filter: 'isFile',
// path on the server
dest: '<%= nginx_dir_prefix %>/<%= pkg.name %>/dest/'
}]
}
}
// 省略的grunt配置xxxxxxx
grunt.registerTask('deploy-test', ['build-test', 'scp:js_css']);
// 省略的grunt配置xxxxxxx相对于之前使用一个shell来部署所有项目的情况 deploy.sh -p project_name -b branch_name --domain=xxxxx
现在只需要本地执行: grunt deploy-test--domain=xxxxx 并且每次构建都不需要改动dest的东西，dest专门用来做部署就ok了。大家又可以愉快的使用merge request来提交review申请了.
当然上面省略了build-test的配置，其实就是改了打包的目录。
