Advocates：
http://build-doctor.com/
Build Tools Reference：
Maven + Go
http://blog.orfjackal.net/2012/08/continuous-delivery-with-maven-and-go.html
Go Download
http://www.go.cd/download/
Problems with Make
http://blog.plover.com/2008/03/28/
Build Tools 問題:
Make:平臺相關
Ant: 寫XML太累，難以維護，統計每個步驟的時間還有測試通過率等指標需要自己寫插件
Maven: 項目目錄結構和流程必須符合其規範，自動升級，難以固定住依賴庫版本，plugin不好寫
Buildr: Apache Buildr 是對Ant和Maven的升級
Scons: 對make的升級，用到python語言
Rake:通用構建工具，用到ruby語言，rubygems
打包：
儘量使用操作系統自帶的打包工具
--Good advice；同意。本人最近經歷過，在windows上使用NSIS腳本，結果發現NSIS默認不支持超過1024個字符的字符串（原先不知道有這個限制），導致在環境變量path超過1024個字符時被清空，在裝了一大堆軟件的機器上會發生，也不是經常發生，一旦發生，恢復起來就不好恢復。
--看來是時候把NSIS換爲windows系統自帶的打包工具了。
Jean-Paul Boodhoo’s blog
http://blog.developwithpassion.com/categories/continuous-integration/ (Current)
http://codebetter.com/jpboodhoo/ (Previous blogs)
Maven標準目錄結構
向遠程機器部署的三種方法：（P161）
第一種：寫一個腳本，分別登錄各機器，執行有關命令
(Unix: scp, rsync; Windows: Psexec, Powershell)
(工具：Fabric, Func, and Capistrano）
(很難處理錯誤情況，因此儘量避免)
第二種：寫一個本地腳本，但是有遠程的Agent
（次強大，持續集成服務器（帶有agent模型），
(很難處理錯誤情況，因此儘量避免)
第三種：打包，用基礎設施管理工具或者部署工具部署
（最強大，可以同時完成部署和基礎設施管理）
(可以處理錯誤情況，首選)
部署工具：
ControlTier
BMC BladeLogic
基礎設施管理工具：
Marionette Collective
CfEngine
Puppet
部署的層次 P162
硬件
操作系統、操作系統的配置
中間件、中間件的配置
應用、應用的配置
基礎設施的冒煙測試
配置管理最佳實踐 Bob Aiello
http://www.amazon.cn/%E5%9B%BE%E4%B9%A6/dp/B00EHLQWGY
http://cmbestpractices.com/
只使用相對路徑
絕對路徑另行存放，不要混在一起
Unix應遵循Filesystem Hierarchy Standard (FHS)應關注整體指標，最重要的是：cycle time（從創意到交付用戶的時間）
而不是單獨關注某個指標：比如bug率，因爲過分追求一個指標不利於整體的提高。
P166
用md5碼，版本號標記一個二進制，存入數據庫不要把二進制文件放進版本管理
把生成的東西放入共享文件系統，
可以使用Maven, Ivy, Nexus
Nexus私服可解決使用maven的機器上不了internet問題
http://www.sonatype.org/nexus/go/
如果某測試失敗了，做個標記，等跑完其他的測試再整體標記failed，這樣可以儘量多收集信息。否則浪費時間。
unit test anti-patterns
http://blog.james-carr.org/2006/11/03/tdd-anti-patterns/
單元測試
執行要快
至少80%代碼覆蓋率
不要調用中間件（數據庫、消息機制）
測試消息時，兩步分開，一步測發消息，一步測收到消息的響應
Stubbing（一般在組件或子系統）：用模擬的替代真實的
Mocking（可以少寫代碼，推薦使用）
時間相關的放入獨立的類
