一、我們要解決的問題
無論是什麼樣的解決方案，一定要牢記我們要解決的問題是什麼，切不能將解決方案當做問題本身。具體到過程改進，不管是何種方式的改進，它們所要解決的問題永遠只有一個：縮短從產品想法到可用軟件之間的時間週期。自動化發佈正是如此，如果軟件發佈只做一次，我們說根本不需要自動化，但如果三次以上，那麼軟件開發的黃金法則DRY就必須遵守，讓時間真正用到開發當中去。
二、與發佈相關的問題
所謂自動化只不過是將原先手工做的工作謙讓給機器做，所以自動化之前一定要先清楚與發佈相關的問題有哪些，即使不自動化，這些工作也一個也不能少：
- 應用程序如何打包？ 發佈包能否追蹤到SVN版本號？
- 對目標機器環境有什麼樣的要求？
- 配置信息是否需要根據目標機器信息做出調整？
- 應用程序如何安裝和啓動？
- 應用程序啓動後如何切流量？
- 應用程序如何升級？ 舊版本程序數據如何遷移？
- 升級過程中和結束後如何切流量？
- 應用程序如何卸載？
三、我們的方案
李安的少年Pi正在狂刷票房，我們的自動化發佈方案也要跟上潮流：Puppet+CI我們的少年Pi。
Ø 使用CI自動化打包，追蹤每個發佈包的SVN版本；
Ø 使用Puppet管理髮布包、目標機器環境、應用程序配置信息以及應用程序線上生命週期；
Ø 使用伽利略系統提供應用程序的命名服務和進行流量切換。
現在應用程序的發佈需要兩步：CI一鍵打包、puppet指定應用程序版本SVN提交。
四、具體方案
具體方案也就是如何解決與發佈相關八個問題的過程。
1. 如何安裝、升級和卸載應用程序
我們使用操作系統原生包管理系統來安裝、升級和卸載應用程序，我們的應用程序打出RPM二進制包。免安裝，所有機器自帶，綠色的，有機的。
打包：rpm -ba ./team_member-1.spec
安裝：rpm –ivh team_ member-2.0.1-48.x86_64.rpm
升級：rpm –U team_ member-2.0.1-49.x86_64.rpm
卸載：rpm –e team_ member-2.0.1-48.x86_64.rpm
程序升級前要停舊版本服務怎麼辦？舊版本數據要做處理怎麼辦？RPM已經幫我們料理好這一切，只要寫出spec文件，剩下的交給我們。盡情的插入吧：
2. 如何管理目標機器環境和應用配置信息
應用程序已經打好rpm包了，但這還不夠，應用程序發佈到哪臺機器上？應用程序對目標機器有什麼要求？發佈時需要修改哪些配置和參數？實際發佈如何執行，難道需要登陸到每臺目標機器運行rpm命令嗎？
我們使用Puppet來搞定這一切，Puppet是現在應用第一的devops工具，它通過master/agent的工作模式管理機器。我們通過聲明來控制我們的機器達到目標狀態。同時，所有puppet文件全部在SVN裏，所有對機器的修改全部codereview和可審計。
如何管理應用程序發佈到哪臺機器上？在回答這個問題前我們必須將應用程序在線上的生命週期再進行一次封裝。
應用程序TeamMember被我們封裝成一個puppet module，配置文件和參數被封裝在對應templates和files裏，每次發佈前都要修改配置文件和傳遞不同的參數？out了吧，puppet幫你傳參搞定:
Teammember.conf文件內容：
封裝完成後的效果是這樣的：
最後在管理部署的site.pp文件裏聲明一下，應用程序TeamMember的2146版本就被自動部署到10.128.34.141.test.back.shequ這臺機器上了，我們後續的工作也就是維護這個site.pp文件了，所有應用程序的部署信息都在SVN被集中管理起來：
登陸到每臺目標機器運行rpm命令？No!現在TeamMember已經被封裝，我們修改完畢site.pp並提交後，puppet就自動執行命令了，要不怎麼說是自動化呢。（現在puppet默認在agent每半小時同步一次，但同時支持馬上觸發執行）。
3. 如何追蹤每次發佈的SVN版本號
我們使用CI進行應用程序的打包，將build號作爲包命名的一部分：
4. 如何在發佈過程中切換流量
這是另外一個很大的話題，參見伽利略計劃。
五、下一步工作
使用CI將環境的自動化部署與自動化測試串聯起來，搭建起整個研發流程自動化平臺：
六、小結
沒有銀彈，自動化所做的只是將之前手工工作交給計算機完成，需要做的工作一個都不能少，此外，我們還要多做一些封裝或腳本工作，但是，當我們需要重複做這些事情的時候，價值就出現了。我們的目標永遠是縮短從產品想法到可用軟件之間的時間週期。讓時間真正用到開發當中去。