2持續(xù)交付2.pptx

1、,講師：陳 浩 2016-9-28,中國廣州,軟件研發(fā)的優(yōu)化實踐,中國移動,目錄 CONTENTS,01.,02.,03.,04.,敏捷開發(fā),持續(xù)交付,測試驅(qū)動開發(fā),全息化生產(chǎn),01.,02.,03.,集成產(chǎn)品開發(fā)體系,產(chǎn)品型研發(fā)活動,游戲化研發(fā)實踐,高效研發(fā)實踐,高價值化研發(fā),高效研發(fā)實踐,1,1, 持續(xù)交付 ,PART ONE,PART ONE,背景介紹,在互聯(lián)網(wǎng)的產(chǎn)品開發(fā)時代，產(chǎn)品迭代越來越頻繁，“從功能開發(fā)完成直到成功部署”這一階段被稱為軟件開發(fā)“最后一公里”。很多開發(fā)團隊也越來越認識到，敏捷開發(fā)和持續(xù)交付可幫助開發(fā)團隊提高迭代效率和質(zhì)量。,移動互聯(lián)網(wǎng)又使得DevOps成為一個十分火熱

2、的概念。當企業(yè)希望將原本笨重的開發(fā)與運營之間的工作移交過程變得流暢無礙，便可借助DevOps來完成,PART ONE,背景介紹,持續(xù)集成是一種軟件開發(fā)實踐：許多團隊頻繁地集成他們的工作，每位成員通常進行日常集成，進而每天會有多種集成。每個集成會由自動的構(gòu)建（包括測試）來盡可能快地檢測錯誤。許多團隊發(fā)現(xiàn)這種方法可以顯著的減少集成問題并且可以使團隊開發(fā)更加快捷。 持續(xù)集成，讓很多開發(fā)團隊又 愛 又 恨 。愛，在于整個流程對項目的交付價值大有裨益，盡最大可能地減少不必要的加班；恨，在于成本過大，部署的困難、工程文化的隔閡。,PART ONE,持續(xù)集成的益處,在開發(fā)中，問題暴露的越早，修復代碼的成本越

3、低，成功部署的勝算就越大。持續(xù)集成高頻率地編譯、測試、審查、部署項目代碼，這其中代碼集成是主要的風險來源。要想規(guī)避這個風險，只有提早集成，持續(xù)而有規(guī)律的集成，以此來確保當前代碼庫的質(zhì)量，把握開發(fā)的進程和節(jié)奏。 很明顯的一點，使用持續(xù)集成后，程序員們提交代碼也會變得更加小心謹慎。,盡早暴露問題，把握開發(fā)節(jié)奏,PART ONE,持續(xù)集成的益處,在通常的開發(fā)環(huán)境中，工具及環(huán)境的滯后，加上工作的重復枯燥，讓開發(fā)者對寫程序失去新鮮感。在持續(xù)集成過程，一步一步的編譯、測試、審查、部署，牽扯大量重復的工作。 在搭建持續(xù)（自動化）集成環(huán)境之后，可以讓開發(fā)人員不再需要手動地 checkout 代碼，節(jié)省大量的時

4、間和避免不必要的壓力，把精力放在更多有價值的事情上，這樣也可以形成良性的循環(huán)。,避免重復操作，讓流程自動化,PART ONE,持續(xù)集成的益處,每日高頻率的集成保證了項目隨時處于可部署運行的狀態(tài)，如果沒有持續(xù)集成，項目發(fā)布之前將不得不手動地集成，然后花費大量精力修復集成問題，弄的團隊成員疲憊不堪。 使用持續(xù)集成，幫助我們跨越頻繁部署的障礙。大家都知道，只有保持頻繁部署，讓用戶看到產(chǎn)品的新特性， 才能不斷地磨合優(yōu)化構(gòu)建和發(fā)布流程，讓反饋周期更短更有效。,保持隨時部署，簡化發(fā)布流程,PART ONE,持續(xù)集成的益處,無論什么樣的工程師，都會對存在大量 bug 的代碼產(chǎn)生恐懼心理，這就是心理學上的的

5、Broken Windows 綜合癥（Broken Windows syndrome）。CI 可以有效防止破窗綜合征，讓開發(fā)團隊一點點積累起對產(chǎn)品的信心，對使用技術(shù)的保持成就感。 與此同時，持續(xù)集成讓每個人都能看到良好的界面和視圖來了解項目的成熟度，讓所有人都知道正在發(fā)生什么。也許更容易增強開發(fā)信心，培養(yǎng)團隊良好的工程文化，齊心協(xié)力向目標前進。,增強團隊信心，建立工程師文化,PART ONE,持續(xù)集成的不足,場景1：環(huán)境升級 項目A和項目B都依賴于Web容器，公司決定升級Web容器版本，而公司要升級的機器有上百臺，依賴人肉升級已不現(xiàn)實，維護團隊因此針對各種軟件開 發(fā)了相應的自動化腳本，但當新的

6、軟件出現(xiàn)時，必須要開發(fā)新的腳本。而且當同時升級若干環(huán)境軟件時，則難度隨之增大，手工調(diào)度的方式極易出錯，當升級失敗時 仍需要大量人工處理。由于存在大量升級腳本，有一定的維護成本。,PART ONE,持續(xù)集成的不足,場景2：依賴于環(huán)境的軟件升級與回滾 針對環(huán)境升級，公司為項目A和項目B開發(fā)了新的版本。但環(huán)境的升級和軟件的升級不是同步進行，出錯的可能性非常大（想一想間接依賴和多重依賴的情 況）。當新版本部署到生產(chǎn)系統(tǒng)時，發(fā)現(xiàn)問題，需要回滾到之前的版本所有運行時版本都需要回滾，而且環(huán)境也需要同步回滾。幾百臺機器,PART ONE,持續(xù)集成的不足,場景3：運行時依賴 在第一節(jié)的方案中，我們將所有的運行時

7、依賴都打包到一起。當項目依賴關(guān)系復雜時，這樣產(chǎn)生的包將非常臃腫，潛在地延長了部署的時間（想一想全世有幾 百臺服務(wù)器，一個部署計劃需要部署幾百兆文件的情況），而且產(chǎn)生沖突的可能性非常大，而且對于不同類型的項目（Java和Ruby項目）缺乏通用性。06 年左右，Nortel可是拿Excel統(tǒng)計過運行時依賴的，牽涉若干項目組，反復多次，沒有個把月真搞不定。,PART ONE,持續(xù)集成的不足,場景4：泛濫的部署 每個項目相關(guān)的持續(xù)集成環(huán)境都需要開發(fā)自己的部署腳本，重復投入大，而且各個項目的部署過程不一致，并且對于同一個項目無法同時滿足不同目的部署要求，例如，環(huán)境或系統(tǒng)配置參數(shù)改變后，無需安裝包，只需做

8、清理和激活的工作。最后，持續(xù)集成只是支持了和代碼修改有關(guān)的部署。,PART ONE,持續(xù)集成的不足,場景5：不一致的環(huán)境 簡單項目中，開發(fā)環(huán)境和運行環(huán)境都由開發(fā)人員搭建，當公司變大時，系統(tǒng)的運行環(huán)境將由運維人員搭建，而開發(fā)環(huán)境如果由運維人員搭建則工作量太大，由開發(fā)人員自己搭建則操作復雜又容易產(chǎn)生不一致的情況。,PART ONE,持續(xù)集成的不足,場景6：熱切換 對于某些部署，需要盡量減少服務(wù)的停止時間，需要在服務(wù)的同時進行部署。,PART ONE,持續(xù)集成的不足,大型企業(yè)，人多，項目多，機器多，項目環(huán)境復雜，部署維護工作繁多。以持續(xù)集成為基礎(chǔ)的部署可以解決各個項目的集成問題，卻無法幫助企業(yè)應對復

9、雜的項目環(huán)境和各種不同的部署要求。 要實現(xiàn)真正意義上的持續(xù)交付與部署，我們就必須把環(huán)境和項目同等對待，通通納入管理之中。同時，部署本身要得到統(tǒng)一。 一個好的部署機制，應該是易于建立，易于使用，易于維護。,PART ONE,解決持續(xù)集成后續(xù)的問題,持續(xù)交付(Continuous Delivery) 用來確保讓代碼能夠快速、安全的部署到產(chǎn)品環(huán)境中，它通過將每一次改動都提交到一個模擬產(chǎn)品環(huán)境中，使用嚴格 的自動化測試，確保業(yè)務(wù)應用和服務(wù)能符合預期。因為使用完全的自動化過程來把每個變更自動的提交到測試環(huán)境中，所以當業(yè)務(wù)開發(fā)完成時，你有信心只需要按一次按鈕就能將應用安全的部署到產(chǎn)品環(huán)境中。 持續(xù)部署(C

10、ontinuous deployment) 持續(xù)交付的更高階段：所有通過了自動化測試的改動都自動的部署到產(chǎn)品環(huán)境里。大多數(shù)的公司如果沒有制度的約束或其它條件的影響，都應該以持續(xù)部署為目標。,PART ONE,解決持續(xù)集成后續(xù)的問題,持續(xù)交付/持續(xù)部署已經(jīng)超越了傳統(tǒng)軟件研發(fā)的工作界面，構(gòu)建了一種新型的研發(fā)、運維場景。要像真正達到持續(xù)交付的目標，就必須實施 DevOps （Development Operations）， 將研發(fā)與運維兩個部門、兩個思維觀念的差異點整合起來,PART ONE,DEVOPS的使命,敏捷的出現(xiàn)打破了用戶、開發(fā)和測試之間的隔閡，實現(xiàn)了團隊的協(xié)作。 新近出現(xiàn)的DevOps則

11、借鑒了敏捷思想，將敏捷原則應用于運維領(lǐng)域，使交付團隊與運維團隊建立起更緊密的合作關(guān)系。DevOps讓企業(yè)能夠獲得更快交付高質(zhì)量、高價值軟件的能力，從而增強企業(yè)競爭力。,PART ONE,DEVOPS的益處,DevOps 就是想方設(shè)法的避免各種“終極失敗”，同時讓大家用更聰明更有效的方式去工作。 它是一種框架，包含了很多優(yōu)秀想法和原則，它鼓勵開發(fā)部門和運維部門通力合 作。 在DevOps環(huán)境中，開發(fā)人員和系統(tǒng)管理員會構(gòu)建一些關(guān)系、流程和工具，從而更好的與客戶互動，最終提供更好的服務(wù)。,PART ONE,DEVOPS的益處,DevOps 也不僅僅是一種軟件的部署方法。它通過一種全新的方式，來思考如

12、何讓軟件的作者（開發(fā)部門）和運營者（運營部門）進行合作與協(xié)同。 使用了DevOps模型 之后，會使兩個部門更好的交互，使兩者的關(guān)系得到改善，從而讓很多領(lǐng)域從中受益，例如：自動化、監(jiān)視、能力規(guī)劃和性能、備份與恢復、安全、網(wǎng)絡(luò)以及服務(wù)提供（provisioning）等等。,PART ONE,特征解析,持續(xù)集成 持續(xù)交付 持續(xù)部署 三者究竟是什么，有何聯(lián)系和區(qū)別呢？,PART ONE,從持續(xù)集成到持續(xù)部署,PART ONE,從持續(xù)集成到持續(xù)部署,持續(xù)集成是指軟件個人研發(fā)的部分向軟件整體部分交付，頻繁進行集成以便更快地發(fā)現(xiàn)其中的錯誤?！俺掷m(xù)集成”源自于極限編程（XP），是 XP 最初的 12 種實踐之

13、一。,PART ONE,CI 需要具備的特性,全面的自動化測試。這是實踐持續(xù)集成&持續(xù)部署的基礎(chǔ)，同時，選擇合適的自動化測試工具也極其重要； 靈活的基礎(chǔ)設(shè)施。容器，虛擬機的存在讓開發(fā)人員和 QA 人員不必再大費周折； 版本控制工具。如 CVS，SVN ，Git等； 自動化的構(gòu)建和軟件發(fā)布流程的工具，如 Marven，Jenkins； 反饋機制。如構(gòu)建/測試的失敗，可以快速地反饋到相關(guān)負責人，以盡快解決達到一個更穩(wěn)定的版本。,PART ONE,CI 的優(yōu)勢,“快速失敗”，在對產(chǎn)品沒有風險的情況下進行測試，并快速響應； 最大限度地減少風險，降低修復錯誤代碼的成本； 將重復性的手工流程自動化，讓工程

14、師更加專注于代碼； 保持頻繁部署，快速生成可部署的軟件； 提高項目的能見度，方便團隊成員了解項目的進度和成熟度； 增強開發(fā)人員對軟件產(chǎn)品的信心，幫助建立更好的工程師文化。,PART ONE,從持續(xù)集成到持續(xù)部署,持續(xù)交付在持續(xù)集成的基礎(chǔ)上，將集成后的代碼部署到更貼近真實運行環(huán)境的類生產(chǎn)環(huán)境（production-like environments）中。持續(xù)交付優(yōu)先于整個產(chǎn)品生命周期的軟件部署，建立在高水平自動化持續(xù)集成之上。,PART ONE,持續(xù)交付的焦點,開發(fā)不能等到所有東西都完成了才向下個環(huán)節(jié)交付，這樣所有的問題只會在最后才爆發(fā)出來，解決成本將巨大到無法解決。 代碼沒有問題之后，是繼續(xù)手

15、動部署到生產(chǎn)環(huán)境中的。 持續(xù)交付并不是指軟件每一個改動都要盡快部署到產(chǎn)品環(huán)境中，它指的 是任何的代碼修改都可以在任何時候?qū)嵤┎渴稹?PART ONE,持續(xù)交付的優(yōu)勢,快速發(fā)布。能夠應對業(yè)務(wù)需求，并更快地實現(xiàn)軟件價值。 編碼-測試-上線-交付的頻繁迭代周期縮短，同時獲得迅速反饋； 高質(zhì)量的軟件發(fā)布標準。整個交付過程標準化、可重復、可靠， 整個交付過程進度可視化，方便團隊人員了解項目成熟度； 更先進的團隊協(xié)作方式。從需求分析、產(chǎn)品的用戶體驗到交互 設(shè)計、開發(fā)、測試、運維等角色密切協(xié)作，相比于傳統(tǒng)的瀑布式軟件團隊，更少浪費。,PART ONE,從持續(xù)集成到持續(xù)部署,持續(xù)部署是指當交付的代碼通過評審之

16、后，自動部署到生產(chǎn)環(huán)境中。持續(xù)部署是持續(xù)交付的最高階段。這意味著，所有通過了一系列的自動化測試的改動都將自動部署到生產(chǎn)環(huán)境。它也可以被稱為“Continuous Release”。,PART ONE,持續(xù)部署的優(yōu)勢,持續(xù)部署主要好處是，可以相對獨立地部署新的功能，并能快速地收集真實用戶的反饋。 “You build it, you run it”，這是 Amazon 一年可以完成 5000 萬次部署，平均每個工程師每天部署超過 50 次的核心秘籍。,PART ONE,持續(xù)部署的要素,PART ONE,從持續(xù)集成到持續(xù)部署,持續(xù)集成（Continuous Integration）、持續(xù)交付（Co

17、ntinuous Delivery）和持續(xù)部署（Continuous Deployment）提供了一個優(yōu)秀的 DevOps 環(huán)境，對于整個團隊來說，好處與挑戰(zhàn)并行。 頻繁部署、快速交付以及開發(fā)測試流程自動化將成為軟件工程的重要組成部分,PART ONE,從持續(xù)部署到DevOps,把開發(fā)交付劃分為，計劃、編碼、構(gòu)建、測試、部署、運維幾部分，我們可以從圖看出DevOps和持續(xù)交付，持續(xù)集成，持續(xù)測試，持續(xù)部署以及敏捷開發(fā)的關(guān)系。能具備持續(xù)集成，持續(xù)測試，持續(xù)部署的能力，并逐步完善從而實現(xiàn)具備持續(xù)交付的能力。,PART ONE,DevOps的重點,警惕總體安全風險 虛擬化、云、BYOD以及軟件定義網(wǎng)

18、絡(luò)（SDN）等新興技術(shù)不斷得到采用意味著網(wǎng)絡(luò)變得越來越復雜，愈發(fā)的異構(gòu)化，安全風險也是如此。這是一個文化問題，需要安全、開發(fā)者以及運營團隊培育出此前未有過的一定水平的信任和協(xié)作。 安全風險變化 把DevOps看作一種可將開發(fā)者和IT運營引向更快更高效的部署、運營及升級應用的協(xié)作理念和流程很重要。 可伸縮性 企業(yè)和技術(shù)的人必須在功能、推向市場的時間、成本以及風險承受能力等方面做出權(quán)衡。你需要有合適的衡量目標，包括特定模式下的那些端點上有多少用戶，有多少并發(fā)請求。 實現(xiàn)易用 DevOps就是自動化和可重復性。 管理網(wǎng)關(guān) 盡管新的目標是在開發(fā)和運營團隊之間建設(shè)最好的文化，但為了確保產(chǎn)品環(huán)境保持穩(wěn)定，

19、在這兩個職能之間保留一些網(wǎng)關(guān)仍然是好的。,PART ONE,DevOps的一個使用場景,使用RTC ( Rational Team Concert ) 進行協(xié)同開發(fā)，項目管理，以及管理代碼。通過提交代碼自動觸發(fā)持續(xù)集成任務(wù)，Jenkins作為持續(xù)集成工具解決各種模塊之間的依賴，并且能觸發(fā)接下來的構(gòu)建過程，在成功完成的構(gòu)建之后，還可觸發(fā)預置的簡單的腳本調(diào)用測試環(huán)境的準備,PART ONE,持續(xù)集成的步驟,最重要的一環(huán)是選擇合適的持續(xù)集成系統(tǒng)。是搭建私有部署還是選擇托管型持續(xù)集成系統(tǒng)，關(guān)鍵在于團隊運行的基礎(chǔ)設(shè)施，團隊對持續(xù)集成系統(tǒng)的資源投入力度。 對比一下私有部署和托管型持續(xù)集成系統(tǒng)，或許能幫助你

20、更好地做出選擇。,PART ONE,CI工具的選擇,Self Hosted CI 指的是將軟件部署在公司的機房或內(nèi)網(wǎng)中，需要提供多臺服務(wù)器來完成 CI 系統(tǒng)的運轉(zhuǎn)，同時需要對不同機器之間進行環(huán)境配置。比如Maven 或 Gradle 或 Jenkins ，他們的特點是自由開源，且文檔支持廣泛。 Hosted CI 指的是由 SaaS 型的 CI 服務(wù)，全程在線進行構(gòu)建配置，不需要考慮裝機器，裝軟件，環(huán)境搭建等成本。常見的有 CircleCI，Codeship 和 TravisCI 等，還有國內(nèi)的持續(xù)集成服務(wù)flow.ci 。,PART ONE,CI工具的特點,Self Hosted CI 對構(gòu)

21、建環(huán)境有完全的控制權(quán)，能夠?qū)崿F(xiàn)完全定制。但需要搭建環(huán)境和配置、維護成本高，需要買專門的機器，花費人力物力且更新遷移風險高； Hosted CI 無需額外機器，幾分鐘就可以用起來?？梢愿鶕?jù)你的需要動態(tài)調(diào)度資源。省時，省心，省力。,Jenkins 過去一直是大部分公司的選擇，但這個現(xiàn)象正在發(fā)生改變，隨著公有云服務(wù)、Docker，SaaS 的普及，越來越多的企業(yè)開始選擇 Hosted CI，也就是托管型持續(xù)集成系統(tǒng)。,PART ONE,持續(xù)集成的前提,將所有的源代碼保存在單一的地點，讓所有人都能從這里獲取最新的源代碼（以及以前的版本）。 使創(chuàng)建過程完全自動化，讓任何人都可以只輸入一條命令就完成系統(tǒng)的

22、創(chuàng)建。 使測試完全自動化，讓任何人都可以只輸入一條命令就運行一套完整的系統(tǒng)測試。 確保所有人都可以得到最新、最好的可執(zhí)行文件。,PART ONE,持續(xù)集成的步驟,STEP1 . 提交 流程的第一步，是開發(fā)者向代碼倉庫提交代碼。所有后面的步驟都始于本地代碼的一次提交（commit）。,PART ONE,持續(xù)集成的步驟,STEP2. 測試（第一輪） 代碼倉庫對commit操作配置了鉤子（hook），只要提交代碼或者合并進主干，就會跑自動化測試。 測試有好幾種。 單元測試：針對函數(shù)或模塊的測試 集成測試：針對整體產(chǎn)品的某個功能的測試，又稱功能測試 端對端測試：從用戶界面直達數(shù)據(jù)庫的全鏈路測試 第一輪

23、至少要跑單元測試。,PART ONE,持續(xù)集成的步驟,STEP3. 構(gòu)建 通過第一輪測試，代碼就可以合并進主干，就算可以交付了。 交付后，就先進行構(gòu)建（build），再進入第二輪測試。所謂構(gòu)建，指的是將源碼轉(zhuǎn)換為可以運行的實際代碼，比如安裝依賴，配置各種資源（樣式表、JS腳本、圖片）等等。 常用的構(gòu)建工具有： Jenkins Travis Codeship Strider Jenkins和Strider是開源軟件，Travis和Codeship對于開源項目可以免費使用。它們都會將構(gòu)建和測試，在一次運行中執(zhí)行完成。,PART ONE,持續(xù)集成的步驟,STEP4. 測試（第二輪） 構(gòu)建完成，就要進

24、行第二輪測試。如果第一輪已經(jīng)涵蓋了所有測試內(nèi)容，第二輪可以省略，當然，這時構(gòu)建步驟也要移到第一輪測試前面。 第二輪是全面測試，單元測試和集成測試都會跑，有條件的話，也要做端對端測試。所有測試以自動化為主，少數(shù)無法自動化的測試用例，就要人工跑。 注意：新版本的每一個更新點都必須測試到。如果測試的覆蓋率不高，進入后面的部署階段后，很可能會出現(xiàn)嚴重的問題。,PART ONE,持續(xù)集成的步驟,STEP5. 部署 通過了第二輪測試，當前代碼就是一個可以直接部署的版本（artifact）。將這個版本的所有文件打包（ tar filename.tar * ）存檔，發(fā)到生產(chǎn)服務(wù)器。 生產(chǎn)服務(wù)器將打包文件，解包

25、成本地的一個目錄，再將運行路徑的符號鏈接（symlink）指向這個目錄，然后重新啟動應用。 這方面的部署工具有Ansible Chef Puppet等。,PART ONE,持續(xù)集成的步驟,STEP6. 回滾 一旦當前版本發(fā)生問題，就要回滾到上一個版本的構(gòu)建結(jié)果。最簡單的做法就是修改一下符號鏈接，指向上一個版本的目錄。,PART ONE,持續(xù)部署一覽圖,PART ONE,持續(xù)部署的步驟,PART ONE,持續(xù)部署的管道,交付管道的建立和自動化是持續(xù)交付的基礎(chǔ)。,PART ONE,持續(xù)部署的要求,如果持續(xù)集成實現(xiàn)了自動化而部署過程需要大量手工操作，那部署就無法跟上持 續(xù)集成的節(jié)奏。部署也需要自動化

26、，部署自動化工具可以幫助一個構(gòu)建自動地在部署管道中推進，使部署本身不成為瓶頸。 自動化可以確保整個部署過程可以固化下來，在每次部署中可重復進行。這樣就可以既測試待部署工件的質(zhì)量，也同時驗證部署流程的質(zhì)量，把這種流程也作為資產(chǎn)管理起來。,PART ONE,DevOps目標,PART ONE,DevOps工具,PART ONE,DevOps的推進,1.弄清楚“為什么？” 首先非常清楚跨團隊的成員為什么會聚到一起，知道團隊試圖實現(xiàn)什么，清楚大家的目的是什么是非常重要的。 組織的主要目標是我們實現(xiàn)DevOps文化的唯一原因，除此之外沒有其他原因。 DevOps僅僅是達到目標的一種手段，但是它自己本身并

27、沒有結(jié)束：“DevOps并不是你的為什么，不是你合作伙伴的為什么，當然也不是你業(yè)務(wù)的為什么”。,PART ONE,DevOps的推進,2. 實現(xiàn)組織合作 接下來是使整個跨團隊組織合作，讓所有人基于一組共享的條件和規(guī)則向一個共同的目標努力。 當能夠把同一個目標指定給多個人的時候，一個組織就實現(xiàn)了正確的合作，大家會選擇同樣的方式去實現(xiàn)各自的目標，對于同一個問題有同樣的答案。這可能是“組織合作的終極夢想”。 為了完成這種合作，組織內(nèi)部必須要有人描繪一個DevOps愿景。這并不能通過教學過程實現(xiàn)，因為人們只會嘗試著機械性地遵循這些步驟。,PART ONE,DevOps的推進,3.持續(xù)改進循環(huán) 這些循環(huán)

28、的目的是通過制定計劃、實現(xiàn)計劃、測量輸出和決定如何持續(xù)地改進流程。,PART ONE,CI 需要具備的特性,單一代碼源 自動化創(chuàng)建腳本 自動化測試 主創(chuàng)建 代碼歸還,PART ONE,CI的數(shù)理基礎(chǔ),集成的工作量是與兩次集成間隔時間的平方成正比 每周集成一次所需的工作量絕對不是每天集成的5倍，而是大約25倍。,PART ONE,成功創(chuàng)建的標準,所有最新的源代碼都被配置管理系統(tǒng)驗證合格 所有文件都通過重新編譯 得到的目標文件（例如Java的class文件）都通過連接（Link），或者得到可執(zhí)行文件 系統(tǒng)開始運行，針對系統(tǒng)的測試套件開始運行 所有的步驟都沒有錯誤、沒有人為干涉，所有的測試也都通過了

29、,PART ONE,成功創(chuàng)建的標準,絕大多數(shù)的集成都可以而且應該自動完成。 讀取源代碼、編譯、連接、測試，這些都可以自動完成。 在整個創(chuàng)建過程中，完全不需要你動腦子。,PART ONE,對CI的領(lǐng)悟,如果集成讓你感到痛苦，也許就說明你應該更頻繁地進行集成。 如果方法正確，更頻繁的集成應該能減少你的痛苦，讓你節(jié)約大量時間。 持續(xù)集成應該天天做，實時做,PART ONE,持續(xù)部署成功的關(guān)鍵,充分而廣泛的自動化測試覆蓋； 盡可能短的測試反饋時間； 部署過程自動化； 部署過程要保證數(shù)據(jù)安全； 在穩(wěn)定的前提下，盡早部署； 完善的風險緩解措施； 將同樣的產(chǎn)物部署到不同的環(huán)境中,PART ONE,持續(xù)部署的

30、最佳實踐,實踐1：建立單一的部署來源 開發(fā)團隊可能分布在各處，或者即便是一起開發(fā)也會根據(jù)業(yè)務(wù)邏輯進行團隊劃分。每個團隊都可能有自己的一套應用部署工具和流程。小規(guī)模團隊這種情況還好，而不同的流程和不同的工具對于大型團隊來講，在編排發(fā)布計劃時會帶來巨大的挑戰(zhàn)和風險。 因 此，在制定發(fā)布計劃時，需要建立一個單一的、可信任的、實時更新的部署來源。比如說，待組裝的應用組件應該放在相同的容器里進行管理，發(fā)布的流程設(shè)計應該 統(tǒng)一風格和模式，不同環(huán)境要求的配置項或者屬性信息應該統(tǒng)一設(shè)置和管理，等等。這樣可以讓接入持續(xù)交付管道的各個角色協(xié)同起來，同時提供了整個交付管道的 可視性和可跟蹤性，清楚的知道誰、何時、做

31、了哪些動作。,PART ONE,持續(xù)部署的最佳實踐,實踐2：讓令人痛苦的手工步驟自動化起來 在 部署過程中的手工步驟帶來了許多風險。比如說，如果這個步驟沒有寫的特別詳細，對于新手來說就存在執(zhí)行的不確定性；或者這個步驟在部署到其他環(huán)境中時遺漏 了，就會導致部署失敗。 另外，手工步驟是難于跟蹤和管理的。為了解決這個問題，盡最大可能自動化現(xiàn)有的部署步驟。 自動化能力為完成部署步驟提供了一種安全 的、被驗證過的、成功率更高的手段，理想情況下，所有步驟都應該被自動化。,PART ONE,持續(xù)部署的最佳實踐,實踐3：管理應用內(nèi)部的相互依賴關(guān)系 避 免僅僅依賴開發(fā)人員口頭去描述和理解應用的內(nèi)部依賴關(guān)系。復雜

32、的部署通常包含應用組件的互相依賴。 如果組件 A 依賴于組件 B 的某一個具體版本，那么沒有部署或者沒有正確部署組件 B 將導致整個發(fā)布失敗。需要將這種依賴關(guān)系通過工具管理起來，而且需要保證同時部署的組件必須一起測試過，要測試這些組件的功能和他們的兼容性。 當應用在不 同的測試環(huán)境移動時，必須確保這種依賴關(guān)系的順利移動，也就是說，必須清楚的知道具有依賴關(guān)系的某個組件的某個具體版本是否被正確部署。,PART ONE,持續(xù)部署的最佳實踐,實踐4：讓部署過程的“什么。在哪里?！笨梢暬?不 知道在某一個機器上或者某一個環(huán)境中部署了什么存在很大的風險。尤其當應用向更嚴格的環(huán)境中移動時風險就更大，如當應用

33、從 UAT 環(huán)境向生產(chǎn)環(huán)境遷移，一個存在于 UAT 環(huán)境中的組件版本和生產(chǎn)環(huán)境的另一個組件不兼容，文檔中并沒有記錄這一點，那么，這種部署就帶來了極大地風險，甚至成為生產(chǎn)事故。另外，停止應用去跟蹤和 分析其部署也是非常耗時和浪費的事情。如果能對部署環(huán)節(jié)的“什么。在哪里?！惫芾砥饋聿⑶逦梢?，就可以確保各個環(huán)境確實成功部署了組件和組件版本。 另外，跟蹤應用的部署也變得非常輕松。生成工件部署清單并實時追蹤分析就可以為整個應用部署帶來更好的洞察力。,PART ONE,持續(xù)部署的最佳實踐,實踐5：讓部署環(huán)節(jié)的準入條件和批準情況清晰可見 認證和審批可以確保質(zhì)量。在持續(xù)交付管道中定義清晰明確的質(zhì)量屬性是非常

34、重要的。只有當在某一個環(huán)境中部署的應用，符合了下一個環(huán)境的質(zhì)量屬性并得到審核批準后，才能將應用部署到該環(huán)境中。 比如一個構(gòu)建經(jīng)過了SIT 階段，需要向 UAT 階段移動時，理論上應該已經(jīng)通過了單元測試、功能測試、性能測試、接口測試等一系列驗證，并且集成測試部門經(jīng)理也批準該構(gòu)建可以部署在 UAT 環(huán)境中，那么，該構(gòu)建的上述驗證值應該為真（表示已通過驗證），其部門經(jīng)理批準值也為真（表示已經(jīng)批準），在 UAT 測試環(huán)境的準入條件中，只有這些屬性值都為真的時候，才允許部署這個構(gòu)建。讓這些準入條件和審核批準狀態(tài)清晰可見，所有人才能知道一個應用需要什么條件才 能在持續(xù)交付管道中前進。通常我們把這種質(zhì)量屬性

35、稱之為質(zhì)量門（quality gate），它正是作為應用向下一個環(huán)境遷移的準入條件。,PART ONE,持續(xù)部署的最佳實踐,實踐6：在不同的環(huán)境中保持部署的一致性 不同的階段和環(huán)境使用不同的部署流程增加了出錯的概率。 比如，由于生產(chǎn)環(huán)境使用的部署流程并沒有在更早期的環(huán)境中驗證過，僅在該環(huán)境下的特殊步驟就有可能出現(xiàn)錯誤。應該使用測試環(huán)境去驗證會在生產(chǎn)環(huán)境上運行的每一個步驟。當編排和設(shè)計應用的發(fā)布流程時，應該設(shè)計成一個單一流程，它被用到整個持續(xù)交付管道中的 每一個階段中。,PART ONE,持續(xù)部署的最佳實踐,實踐7：發(fā)布計劃簡單明了 發(fā)布計劃應該做到編寫容易，在計劃會議上討論時就能隨手制定，而且

36、應該易于理解，讓每一個持續(xù)交付管道中的角色都能知道計劃是怎樣的，如果發(fā)布變化產(chǎn)生的影響是什么。 發(fā)布變更應該有便利的協(xié)作手段去審核和批準。如果發(fā)布計劃難于理解，通常都會被束之高閣，這會帶來一系列問題，如變更混亂，風險增加。,PART ONE,高效DevOps的最佳實踐,實踐1：利益相關(guān)者的積極參與 DevOps的根本原則是開發(fā)人員,運營人員以及技術(shù)支持人員必須定期緊密的工作在一起。言外之意是他們必須互相視對方為重要的利益相關(guān)人，并積極爭取一起工作。 敏捷社區(qū)中一個普遍的實踐是“現(xiàn)場客戶”。這個實踐出自于極限編程，它鼓勵開發(fā)人員應該與業(yè)務(wù)人員緊密合作。規(guī)范的敏捷團隊將該實踐更進一步， 即利益相關(guān)

37、的積極參與，這意味著開發(fā)人員應該與所有利益相關(guān)者一起緊密工作，包括運營人員及支持人員，而不僅僅是業(yè)務(wù)人員。這是雙向的：運營人員和技術(shù)支持人 員也必須愿意和開發(fā)人員緊密工作。,PART ONE,高效DevOps的最佳實踐,實踐2：自動化測試 敏捷軟件開發(fā)人員被稱為質(zhì)量感染者，這是因為他們關(guān)注于編寫高質(zhì)量的代碼，渴望測試越早開始越好。結(jié)果，自動化的回歸測試是敏捷團隊普遍采用的實踐。該實踐有時又被擴展為測試先行的方式，比如測試驅(qū)動開發(fā)（TDD），以及行為驅(qū)動開發(fā)（BDD）。 由于敏捷團隊經(jīng)常一天多次運行他們的自動化測試集， 并且能夠馬上修復發(fā)現(xiàn)的問題，所以他們比普通團隊能達到更高的質(zhì)量。對于運營人員

38、而言，在同意一個解決方案發(fā)布到產(chǎn)品環(huán)境前，堅持足夠的質(zhì)量審查，這是件 好事情。,PART ONE,高效DevOps的最佳實踐,實踐3：集成配置管理 要實現(xiàn)以集成的方式來進行配置管理（CM），開發(fā)團隊不僅要習慣于在解決方案層級應用CM，還需要考慮自身的解決方案與組織的其余基礎(chǔ)設(shè)施之間的 產(chǎn)品環(huán)境配置問題。對于一些開發(fā)人員而言這是個不小的轉(zhuǎn)變，因為他們往往習慣于只考慮當前他們工作的解決方案的CM。 在DevOps環(huán)境中，開發(fā)人員需要 擁有企業(yè)級視角，在更高的層次看待問題。他們的解決方案如何能在產(chǎn)品環(huán)境結(jié)合其它資源帶來優(yōu)勢？其它資源是否能支持被開發(fā)的解決方案？言外之意是開發(fā)團隊 需要了解及管理他們產(chǎn)

39、品的所有范圍的依賴。集成配置管理也使得運營人員了解新的發(fā)布潛在的影響，從而更容易決定進行發(fā)布的時間。,PART ONE,高效DevOps的最佳實踐,實踐4：綜合變更管理 從IT的角度來看，變更管理（高級配置管理）是一門確保IT基礎(chǔ)設(shè)施的演化能對整體組織的支持成功及有意義的藝術(shù)。但是對于項目-團隊層級則頗具挑戰(zhàn)。這是因為非常多的技術(shù)，甚至相似技術(shù)的多個版本會被使用在單個解決方案的開發(fā)過程中。 由于DevOps引入了與運營有關(guān)的企業(yè)級問題，綜合變更管理策略會變得越來越復雜，因為需要考慮大量的解決方案能夠在產(chǎn)品環(huán)境中同時運行和交互。為了實現(xiàn)綜合變更管理，開發(fā)團隊必須與運營團隊緊密合作，來從組織層面了

40、解任何技術(shù)的改變帶來的影響。該方式依賴于前面的實踐-利益相關(guān)者的積極參與，集成配置管理及自動化測試。,PART ONE,高效DevOps的最佳實踐,實踐5：持續(xù)集成 持續(xù)集成（CI）是構(gòu)建及驗證項目的規(guī)范，當有代碼更新被遷入到版本控制系統(tǒng)時，會進行自動化的回歸測試及代碼分析。 CI是與DevOps相關(guān)的敏捷開發(fā)實踐之一（至少從開發(fā)人員角度來說是如此）。 CI確保開發(fā)人員以較小的，可以對代碼缺陷立即反饋的常規(guī)步驟來開發(fā)一個高質(zhì)量的可以工作的解決 方案。,PART ONE,高效DevOps的最佳實踐,實踐6：集成部署計劃 從開發(fā)團隊角度而言，部署計劃總是需要與該組織的運營人員交互。有些情況下，與運營人員接口的專家被特稱為發(fā)布工程師。經(jīng)驗豐富的團