the5fire

最近暂时接管前端组，人手不足的情况下只能自己撸起袖子写代码（打断一下：我们还在招前端！！！！），发现问题还真不少。这次先说下部署方式改造的事，其他的事之后有空可以扯一扯。比如：前端工程师算不算工程师啦~~，前端工程师面试遇到的奇怪问题了~~~等等等等吧，当然，我没有任何拉仇恨的意思。

先来说部署方式改造的事。

在很久之前，我接到任务，要帮忙协助前端做团队建设和流程优化(重点在于代码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的研究过程就不说了，只说一句，不懂的地方看源码吧，文档太少，直接贴配置吧:

 // 需要安装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的配置，其实就是改了打包的目录。