一、我們要解決的問題
無論是什么樣的解決方案,一定要牢記我們要解決的問題是什么,切不能將解決方案當做問題本身。具體到過程改進,不管是何種方式的改進,它們所要解決的問題永遠只有一個:縮短從產品想法到可用軟件之間的時間周期。自動化發布正是如此,如果軟件發布只做一次,我們說根本不需要自動化,但如果三次以上,那么軟件開發的黃金法則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將環境的自動化部署與自動化測試串聯起來,搭建起整個研發流程自動化平臺:
六、小結
沒有銀彈,自動化所做的只是將之前手工工作交給計算機完成,需要做的工作一個都不能少,此外,我們還要多做一些封裝或腳本工作,但是,當我們需要重復做這些事情的時候,價值就出現了。我們的目標永遠是縮短從產品想法到可用軟件之間的時間周期。讓時間真正用到開發當中去。
http://www.aygfsteel.com/ronghao 榮浩原創,轉載請注明出處:)