很多人在說到Daily Build的時候總是喜歡背書。背書就背書吧，總比混跡軟件行業連書都沒看過的強。很久以前遇到一個奇葩。每次到代碼提交測的通知就著急忙慌的催促組員趕緊幹活，開始嚴重加班，晚飯都不吃。。。偶爾還需要開通宵。但是即使如此，最後也不會得到什麼好的反饋。那個team就是這樣循環往復的做著項目，直到永恒。如果項目的相關人員能背背敏捷什麼的開發書籍，想必情況總能有所改善。
相信以上情況各位多少都遇到過，那麼Daily Build為什麼會對這樣的情況有所改善呢？
- 快速定位錯誤。那天的Daily Build出問題瞭就是那天繼承到系統中得代碼出的問題。有check in到SVN的代碼必須是可以編譯的這樣的約定也無濟於事，一個疏忽就扒瞎。Daily Build才是對代碼可運行的最好保證。
- 給客戶想要的軟件。及早的把可運行的代碼給客戶看。用戶可以及時看到可用的功能，可以及早的提出開發和需求理解不一致的內容。這個客戶不一定是特質甲方。也可以理解為給開發部門提出需求的產品等其他部門。一般來說，如果最後給“客戶”一個“出乎意料”的軟件，這有可能不是客戶想要的。
- 開發進度約%60。軟件開發這個東西就是不能像蓋樓一樣看到明顯的結果。%60是個多少？Daily Build可以讓需要瞭解進度的人非常清楚的瞭解開發的進度。
- Daily Build對軟件的質量也有很大的幫助。每天一個可運行的版本出來，測試就可以開始測瞭。盡早的測出bug來，盡早的修改。這些都會在不大量增加工作量的前提下保證代碼質量。比在最後的最後通宵熬夜效果好到不知道多少。
XCODEBUILD
下面Daily Build iOS項目。Xcode有一個command tool的工具xcodebuild。用這個工具可以用來使用命令行編譯Xcode項目。
然後先看看這個xcodebuild都能做些什麼。輸入man xcodebuild命令：
功能很強大！不過我們目前要用到的還隻是其中的一小部分。一點點的看。
切換到你項目所在的目錄
cd /Users/username/Desktop/MyiOSApp/
試試這句
xcodebuild -configuration Distribution clean build
最後看到這句** BUILD SUCCEEDED **就算是命令執行成功瞭。你可以在你的目錄下發現一個新建的文件夾build，在這個文件夾裡就可以找到編譯並且打包好的你的app：YourProjectName.app。沒錯這個打好得包是app格式的。我們要得時ipa的包，腫麼辦呢。往下看。
xcodebuild -scheme MyiOSApp archive -archivePath /Users/username/Desktop/MyiOSApp.xcarchive
xcodebuild命令，這裡使用-scheme來打包成xcarchive。然後。
xcodebuild -exportArchive -exportFormat ipa -archivePath /Users/username/Desktop/MyiOSApp.xcarchive -exportPath /Users/username/Desktop/MyiOSApp.ipa這個命令執行完成之後，你就會在剛剛生成的build文件夾裡找到你的app的ipa包瞭。
自動化起來
用shell把xcodebuild命令串起來？No，用Python。使用Python可以做shell能做的，還可以做shell不能的。而且python簡單易學，誰拿過來都可以分分鐘學會。最關鍵的一點，很多的linux系統都已經預裝瞭python。mac也不例外。現在mac默認安裝的時Python2.7的環境。所以，下面的代碼都是基於Python2.7的。
上面講瞭“大象裝冰箱”的三步走。一一的用Python代碼實現出來。
準備工作
下面用接收命令行的方式傳入三步走中需要指定的內容。Python在執行的時候是這樣的：
python yourFileName.py command line
我們要傳入的參數包括scheme的名稱，項目所在的目錄等。還有別的，目前所用到的主要是這兩個。例如：
python yourFileName.py --scheme=[your scheme name] -x [project path] [out put path.format]
有瞭命令瞭，就應該解析瞭：
opts, args = getopt.getopt(sys.argv[1:], x, [scheme=])
參數從第二個開始算sys.argv[1:]，因為第一個是yourFileName.py。getopt方法會把長參數名都拿出來給opts數組。opts數組中得每一個元素都是一個tuple的結構，第一個元素是長參數的名稱，第二個元素是長參數對應的值。-x後面的參數都放在args數組中。args的每一個元素都是一個字符串，相當於[project path] [out put path.format]字符串按照空格split成的字符串數組。
走三步，1.cd。。。
跳轉到項目所在的目錄。參考這麼一句import os os.system(ls)可以執行ls命令。但是，這個卻不能執行“cd”命令。因為那個不能修改python主進程的工作目錄。用這個：
import os directory = your ios project path os.chdir(directory)
2. archive
import subprocess archiveCmd = xcodebuild -scheme + targetName + archive -archivePath + directory + targetName + .xcarchive subprocess.Popen(archiveCmd, shell=True)
第一句就是拼一個字符串。一個xcodebuild的命令字符串，然後放到subprocess中執行。
3. 打包成ipa
ipaCmd = xcodebuild -exportArchive -exportFormat ipa + -archivePath + directory + / + targetName + .xcarchive + -exportPath + directory + / + targetName + .ipa subprocess.Popen(ipaCmd, shell=True)
和第二部一樣，拼一個字符串把上一步中打好包的xcarchive重新打包成ipa並輸出。
so far so good？
這幾條命令分開執行，確實都不會有任何的問題。會在項目的目錄下生成一個build的目錄，在裡面可以找到我們在前面兩部的命令中得到的xcarchive文件和最後輸出的ipa文件。很好，都放在python的文件中按照我們預定的方式執行一次。python yourFileName.py -scheme yourSchemeName -x youriOSPeojectPath。執行之後會輸出滿屏幕的xcodebuild的輸出內容。但是看看項目文件夾下，沒有ipa文件！
原來，subprocess執行命令的時候，xcodebuild命令沒有執行完成就已經返回瞭。也就是ipa打包的命令執行的時候上一步的命令還沒有執行完，xcarchive還沒有生成。這一點很好解決，python給subprocess提供瞭一個wait方法。等命令全部執行完瞭再執行下一步。
process = subprocess.Popen(archiveCmd, shell=True) process.wait()
so far so good！
這個時候就算是全部的問題都解決瞭。代碼在這裡。Python語言本身非常的靈活。在這一代碼上可以很容易擴展出其他的功能。比如定時執行，編譯或者打包不成功發送通知郵件等。