這篇介紹雖然沒提到 shell script 的相關技術，不過他是一個案例說明，明天我就會跟大家介紹要怎麼利用 shell script 每分鐘都去問『有沒有程式碼變更阿』。
[簡介]
團隊合作之間最怕的就是人，所以在從A到A+這本書上才會一開始就說：『先挑對的人，再上車!。』

[故事內容]
在某一次的開發經驗中，我們團隊曾經遇到過以下情形，不過還是利用 bash shell script 自動的幫我們解決了這個問題，雖然解決的方式不是最佳的，但還是達到目的了。

故事內容是這樣的：
一開始開發時，因為團隊人數不是很多，再加上都是在同一間大辦公室裡開發，所以我們就選擇 SVN 做為我們開發的版本控制工具使用。

後來由於我們開發的案子已經有雛型了，所以上面的頭頭要求我們將程式碼從我們自行架設的 SVN Server 轉移到公司所用的版本控制工具 『Perforce』 上。但由於我們之前在使用 SVN 時有串接 Jenkins 做 Auto build 以及相關測試掃描功能，以達到持續整合的目的。因此我們也希望在 Perforce 上也可以做到相同的功能，只是，那我要怎麼將 post event trigger 加到 Perforce 呢?

後來查閱了相關資料後也找到能讓 Perforce 做 post event trigger 的方式，只不過礙於我們的『權限不夠』，所以無法在Perforce上針對我們要的地方做 post event trigger。

『那這該怎麼處理呢？』

詢問了一些人後，找到一位「可能」有權限的同事，他雖然人在對岸，但是非常的有熱忱。雖然他也沒做過增加 post event 這個功能，但是也很積極的詢問我們該怎麼做，只不過在他嘗試新增時也才發現「他也沒有權限！」於是他又詢問了他的直接主管才知道，真正有權限的人是一位在高雄的同事！！

『終於找到有權限可以完成這部分的人了』我心想。

正在開心事情終於得到解決的時候，莫非定律告訴我們該發生的就是會發生，事情總是不會那麼順利的！

『你們為什麼要加 post event 』高雄的同事問到。

『因為我們希望當 source code 有變動時，Perforce可幫我們去觸發自動建置的功能，只是抓一個網頁而已。』我開心的回答。

高雄同事:『可是你不知道這樣會增加我這邊伺服器的 Loading ？你們可不可以自己做！』

（中間討論過程省略…）

經過短暫的討論後，我知道他是不太願意幫我們做這件事情，因為這事情本就不是他應該做的。公司也沒要求一定要做持續整合，是我們想要讓開發更順暢才自己多做的！

我心想：「好吧！既然你怕增加 server 的 loading，那就由我來增加 server 的 loading 吧！」(我承認或許我的溝通能力也不是很好，才沒辦法說服對方！)

最後我就寫了一支 shell script 一天 24 小時，一個禮拜五天，每分鐘都去問那台 Server 『有程式碼變更嗎？有程式碼變更嗎？』如果有，我就自己去觸發自動建置，如果沒有就什麼是也不做！

最後，我們達到持續整合的目的了，而 Perforce Server 的負載好像也還好，並不會像他說的會增加 loading。

這篇介紹雖然沒提到 shell script 的相關技術，不過他是一個案例說明，明天我就會跟大家介紹要怎麼利用 shell script 每分鐘都去問『有沒有程式碼變更阿』。

鐵人賽文章分享
上一篇 常用的指令介紹之看頭看尾
下一篇 ShellScript真實案例練習之實做