持續交付和部署
— 筆記整理自 北京理工大學 計算機學院
Hello World!
備註：圖片託管於github，請確保網絡的可訪問性
- 這是一個jsp小程序發佈到雲端，用戶可以直接訪問
- 這是軟件發佈的第一個版本，假設現在需求發生了變化
- 程序員修改了代碼，提交到版本控制庫, 經過後臺的持續集成和持續部署
- 如果沒有錯誤發生，第二個版本就直接可以給用戶發佈使用了
- 持續部署極大縮短了從開發到部署的過程, 減輕了手工部署的工作量，提高了開發和部署的可靠性
示例架構
備註：圖片託管於github，請確保網絡的可訪問性
- 上圖所用工具都可以通過其他類似工具代替
- 開發者可以使用任意編輯器修改代碼
- 然後提交到版本控制服務器上去
- 經過git和jenkins的配合完成自動化部署的發佈，全程不需要運維人員的參與
- 具體做法是在git服務器上設置一個push的鉤子,每次提交代碼,git都會給一個遠程http的地址發送一個post請求
- 在jenkins中設置一個token供git在遠程調用的時候使用，jenkins在接收到git傳遞過來的消息之後, 觸發一個遠程構建命令到目標服務器
- 目標服務器按照預先定義的任務，執行一系列的工作，比如利用maven構建一個hello.war項目包，然後重建容器，構建一個新的image, push到docker的私有庫中
- 最後重新把docker容器部署起來，就完成了一個持續部署流程
不滿足於CI
- 持續交付和持續部署正是爲了解決持續集成到最後發佈之間的最後一公里
- 持續集成的目的:驗證集成正確性，儘早發現錯誤
- 客戶不關心持續集成等開發過程，只想看到發佈的結果
- 軟件開發團隊做到持續集成是不夠的
- 軟件手工發佈的風險很大
備註：圖片託管於github，請確保網絡的可訪問性
持續交付
- 持續交付和持續部署都可以認爲是持續集成的延續
- 持續交付( Continuous Delivery )是任何的修改都已證明可以在任何時候實施部署，是在持續集成的基礎上將集成後的代碼部署到更接近真實生產環境的預生產環境中去
- 比如在完成單元測試後將代碼部署到數據庫環境中進行更多的測試，如果代碼沒有問題可以手動部署到生產環境之中
- 是每家企業都應該追求的目標
- 持續部署(Continuous deployment)是持續交付的更高階段:自動的部署到產品環境裏，是在持續交付的基礎之上把部署到生產環境的過程自動化
- 如果企業沒有制約的情況下，應該以持續部署爲目標
- 在很多場景中一種業務需要等待另外的功能出現之後才能上線，這樣就沒有辦法完成持續部署了
- 所有，持續部署是否適合某一家企業是基於業務需求而非技術限制
- 開發團隊能夠交付代碼的時候它們纔能有信心在短短几分鐘時間內，把剛剛修改好的結果提交給客戶，爲客戶提供真正的有價值的服務
備註：圖片託管於github，請確保網絡的可訪問性
軟件部署的一般過程
備註：圖片託管於github，請確保網絡的可訪問性
- 持續部署需要考慮部署到哪些環境，是測試環境還是生產環境，還有各個依賴包的版本，環境的配置等
- 一般情況下，從安裝軟件到啓動環境，第一步是選擇要部署的軟件包的版本，根據生產環境的要求，生成新的部署實例
- 同時，要對目標機環境進行清理和配置，以滿足軟件產品的要求，如硬盤，內存以及第三方的依賴等等
- 將軟件包下載到目標機之後就可以進行軟件配置了，消除運行故障，確保程序可以正常運行
- 最後將用戶的訪問請求從舊版切換到新版，完成新版軟件的部署
- 爲了記錄部署過程和爲後續軟件維護提供支持，往往需要生成一份部署報告來記錄軟件相關的配置參數
軟件交付:部署流水線
- 部署流水線指一個應用程序從構建，部署，測試到發佈整個過程的自動化實現
- 部署流水線大致工作方式是這樣的
- 應用程序的配置，源代碼，環境，或數據的每一個變化都會創建一個新的流水線實例
- 流水線首要工作之一是創建二進制文件和安裝包
- 其餘工作都是針對這些二進制文件和安裝包所做的一系列的測試
- 開發人員會更加相信這些二進制文件，配置信息，環境和數據所構成的特殊組合能夠正常工作
- 如果這個產品通過了所有測試就可以發佈了
- 部署流水線以持續集成爲理論基礎，是持續集成的自然結果
- 部署流水線對每個組織都是不同的，取決於每個組織對軟件發佈的價值流的定義，其背後的原則都是一樣的
備註：圖片託管於github，請確保網絡的可訪問性
部署流水線的目標
- 讓構建、部署、測試和發佈過程對所有人可見，促進合作
- 在整個過程中改善反饋，更早的發現和解決問題
- 通過一個完全自動化的過程在任意環境上部署和發佈軟件的任意版本
- 這是爲客戶提供最終價值的體現
備註：圖片託管於github，請確保網絡的可訪問性
軟件交付的原則
- 爲軟件的發佈創建一個可重複且可靠的過程
- 將幾乎所有的事情自動化
- 把所有的東西都納入版本控制
- 提前並頻繁的做讓你感到痛苦的事情
- 如果集成讓你覺得痛苦, 你就應該在提交代碼之後馬上進行集成
- 如果測試讓你痛苦，在一開始的時候就應該不斷的進行測試
- 如果軟件發佈讓你痛苦，就應該嘗試在每次代碼提交併通過所有自動化測試之後馬上進行發佈，如果不能發佈到生產環境中去，就發佈到預生產環境中
- 越早發現缺陷，修復它們的成本就越低
- 內建質量
- 完成意味着發佈
- 交付過程是每個成員的責任
- 持續改進
持續部署帶來的問題
- 部署性能問題
- 大量的持續部署，回滾，文件傳輸給持續部署系統帶來了很大的壓力
- 還要考慮未來更大規模的擴展性問題
- 目標機環境管理
- 多環境部署的時候資源複用問題和新舊機器(環境)的切換問題
- 部署一致性事務問題
- 如果有多臺服務器的時候，有依賴關係的包被部署到了不同機器上，是要求它們一次性成功還是全部失敗最後回滾
- 部署環境的版本控制問題
- 當目標機部署的版本越來越多的時候, 各個環境的包的版本開始出現混亂, 各種依賴的版本也會出現不統一的情況
- 部署計劃
- 計劃過多
- 不同的部署策略都會產生不同的部署計劃
- 部署的監控和維護
- 當規模上去以後
- 部署系統的監控和維護就會變得非常複雜，往往不亞於一個大型的互聯網應用
備註：圖片託管於github，請確保網絡的可訪問性
不簡單，需要根據團隊規模，自動化開發程度，項目特點等等因素綜合考慮，逐步推進
新的趨勢
- 持續集成、持續交付和持續部署的出現及流行反映了新的軟件開發模式發展趨勢
- 工作職責和人員分工的轉變
- 軟件開發人員運用自動化開發工具進行持續集成，進一步將交付和部署擴展
- 而原來的手工運維工作也逐漸被分派到了開發人員的手裏
- 運維人員的工作也從重複枯燥的手工作業轉化爲開發自動化的部署腳本，並逐步併入開發人員的行列之中
- 大數據和雲計算基礎設施的普及進一步給部署帶來新的飛躍
- 雲計算的出現使得計算機本身也可以自動化的創建和回收
- 這種環境管理的範疇將進一步的擴充
- 部署和運維工作也會脫離具體的機器和機房，可以在遠端進行
- 部署能力和靈活性也會出現質的飛躍
- 研發運維的融合
- 減輕運維的壓力，把運維和研發融合在一起
總結
- 持續交付和持續部署是一個很複雜的話題，在逐步提高團隊自動化開發的水平之上逐步推進，紮紮實實做好每一個細節
- 最後才能踏上持續部署的這趟告訴列車，才能享受軟件自動化給團隊和客戶的實實在在的好處