在很久之前，我接到任務，要幫忙協助前端做團隊建設和流程優化(重點在于代碼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的配置，其實就是改了打包的目錄。