【學習資料】 持續整合---測試自動化學習
[持續交付實踐] 開篇：持續整合&持續交付綜述
前言
隨著微服務架構與容器虛擬化技術的發展，持續整合與持續交付的概念又重新回到了大家的視野，越來越多的公司開始使用持續整合的系統來解決頻繁釋出帶來的質量問題；使用持續交付的工具來實現程式碼在不同環境上的自動部署。原本有些學院派烏托邦式的思想正被千千萬萬次的整合與部署證明著它應有的價值。
持續交付的概念和產生
傳統軟體的開發與交付的週期都很漫長，一款普通的企業軟體通常需要十幾個開發人員，幾個月的時間來完成，從需求的分析、系統的設計、編寫測試用例、系統開發、單元測試、組裝測試到交付除錯。有條不紊的流程與規範像一輛綠皮火車下的枕木，穩定而可靠的保證整個系統緩慢的推進，每一次交付、升級，都需要提供基礎的硬體、軟體的環境、軟體的程式碼、軟體的文件與手冊。
還記得剛剛邁入軟體開發行業的時候，跟隨公司的服務團隊，駐場交付產品，每一個駐場工程師都按照之前預演過好多遍的流程，對照著系統的部署手冊，一步一步的組裝硬體，安裝軟體，稍有差池，就要按照對應的應急預案進行回滾。開始的時候覺得交付像一個神聖的儀式，將用智慧和汗水構建成的軟體交付給客戶使用，是一種非常榮耀和值得驕傲的事情；後來越來越多次的產品交付讓我深深的感覺每一次交付都像分娩一樣痛苦，捫心自問是否有簡單更舒暢的流程可以將軟體交付給客戶呢？
要想快速的交付，首先要明白軟體交付過程中遇到的核心問題是什麼。總結成兩個詞“自動”與“可靠”。自動是一個很寬泛的詞彙，在軟體交付中代表著測試自動化、交付自動化、運維自動化等等，而可靠講的是每一次交付要保證是當前的交付是穩定的或可回滾到穩定版本的。為了解決“自動”與“可靠”的問題，敏捷開發鼻祖Martin Fowler提出了持續整合與持續交付的概念，它所描述的軟體開發，是從原始需求識別到最終產品部署到生產環境這個過程中，需求以小批量形式在團隊的各個角色間順暢流動，能夠以較短地週期完成需求的小粒度頻繁交付。頻繁的交付週期帶來了更迅速的對軟體的反饋，並且在這個過程中，需求分析、產品的使用者體驗和互動 設計、開發、測試、運維等角色密切協作，相比於傳統的瀑布式軟體團隊，更少浪費。通過這種小步快跑的方式，將小功能快速迭代、驗證、交付，通過自動化的工具，將測試、部署、運維自動化，減少需求在軟體生命週期中流動的時間。
《持續交付-釋出可靠軟體的系統方法》，Jez Humble DavidFarley，2011
2011年，Jez Humble編著的《持續交付(釋出可靠軟體的系統方法)》出版，持續交付的理念迅速被軟體行業接受和流行。該書講述如何實現更快、更可靠、低成本的自動化軟體交付，描述瞭如何通過增加反饋，並改進開發人員、測試人員、運維人員和專案經理之間的協作來達到這個目標。《持續交付(釋出可靠軟體的系統方法)》由三部分組成。第一部分闡述了持續交付背後的一些原則，以及支援這些原則的實踐。第二部分是本書的核心，全面講述了部署流水線。第三部分圍繞部署流水線的投入產出討論了更多細節，包括增量開發技術、高階版本控制模式，以及基礎設施、環境和資料的管理和組織治理。
持續交付工具鏈
但是前輩只給了我們先進的思想，並沒有給出預設的實現。不同的公司、不同的產品、不同的技術棧、不同的開發與部署形態決定了持續整合與持續交付註定是因人而異的，大家不斷摸索什麼樣的方式是持續整合與持續交付的最佳實踐。歸根結底，持續整合與持續交付的難點在於如何遮蔽不同語言、不同框架、不同系統之間的持續整合與持續交付流程的差異性。曾經幻想過是否能有一種方式可以歸約軟體的交付，而這就是Martin Fowler留給我們的課後思考題-論如何實現持續整合與持續交付的流程標準化。
當你問十個哲學傢什麼是哲學的時候，你會得到十一種答案，因為每個人都有對哲學不同的理解，對於持續交付也一樣。個人選取了目前開源社群中最流行和優秀的開源軟體，經過改造後搭建了全開源端到端交付流水線，這應該也是目前各大網際網路公司使用最廣泛的方案。其中Jenkins作為業內優秀的的CI/CD工具，擔任整套了工具鏈的核心組織工作。
國內一些公司開發的輪子【非廣告】：
阿里雲效/codepipeline：https://www.aliyun.com/product/codepipeline
百度效率雲：https://xiaolvyun.baidu.com
普元devops平臺：http://www.primeton.com/products/devops/
Jenkins 2.0 新時代：從 CI 到 CD
自從15年9月底Jenkins的創始人Kohsuke Kawaguchi提出Jenkins 2.0（後稱2.0）的願景和草案之後，整個Jenkins社群為之歡欣鼓舞，不管是官方部落格還是Google論壇，大家都在熱烈討論和期盼2.0的到來。16年4月20日，歷經Alpha(2/29)，Beta(3/24)，RC(4/7)3個版本的迭代，2.0終於正式釋出。這也是Jenkins面世11年以來（算上前身Hudson）的首次大版本升級。
Pipeline as Code是2.0的精髓所在，是幫助Jenkins實現CI(Continuous Integration)到CD(Continuous Delivery)華麗轉身的關鍵推手。所謂Pipeline，簡單來說，就是一套運行於Jenkins上的工作流框架，將原本獨立運行於單個或者多個節點的任務連線起來，實現單個任務難以完成的複雜釋出流程。Pipeline的實現方式是一套Groovy DSL(類似Gradle)，任何釋出流程都可以表述為一段Groovy指令碼，並且Jenkins支援從程式碼庫直接讀取指令碼，從而實現了Pipeline as Code的理念。
建立持續交付流水線(Continuous Delivery Pipeline)是持續交付的前提。作為2.0的核心外掛，Pipeline並不是一個新事物，它的前身是Workflow Plugin，而Workflow的誕生是受更早的Build Flow Plugin啟發，由Nicolas De Loof於2012年4月釋出第一個版本。而縱觀Jenkins的幾個競爭對手（Travis CI、phpci、circleci），Pipeline早已不是什麼新鮮概念。可以說這次Jenkins 2.0的釋出是順勢而為，同時也是大勢所趨。
如果要在更大範圍探討Pipelined的產生背景，我認為有三個層面的原因。
第一層面，與不斷增長的釋出複雜度有關，其中一個典型場景就是灰度釋出。原本只有大公司才有的灰度釋出，隨著敏捷開發實踐的廣泛採用、產品迭代週期的不斷縮短、資料增長理念的深入人心，越來越多的中小公司也開始這一方面的探索，這對釋出的需求也從點狀的CI升級到線狀的CD。這是Pipeline產生的第一個原因。
第二層面，與應用架構的模組化演變有關，以微服務為代表，一次應用升級往往涉及到多個模組的協同釋出，單個CI顯然無法滿足此類需求。這是Pipeline產生的第二個原因。
第三層面，與日益失控的CI數量有關。一方面，類似於Maven、pip、RubyGems這樣的包管理工具使得有CI需求的應用呈爆發性增長，另一方面，受益於便捷的Git分支特性，即便對於同一個應用，往往也需要配置多個CI。隨著CI數量的不斷增長，集中式的任務配置就會成為一個瓶頸，這就需要把任務配置的職責下放到應用團隊。這是Pipeline(as Code)產生的第三個原因。
先簡單開個頭，後續會詳細介紹Pipeline的實現。
持續交付和Devops的關係
devops（開發到運維）是另外一個現在很火的工程概念，和持續交付的關係很多時候讓人傻傻分不清楚。從概念上來說，DevOps更關注Ops(Operations), 持續交付更關注Dev (Development) 。他們的目標都是解決相同的問題，即加速軟體開發，減少軟體開發到交付或上線的時間，並使開發、測試、運維幾個角色協作的更緊密。一般來說個人傾向於兩者說的是同一回事，它們只不過是一枚硬幣的正反面而已，在概念上並沒有什麼爭議。
引用《持續交付》譯者喬樑的觀點，細微的差別可能就是持續交付體現的是產品交付的完整過程，devops強調的是從開發到運維的交付，傳統的持續整合則更強調產品研發過程（開發+測試）。
所以，你們開心就好^_^
結語
近期主要專注於基於開源框架的CI/CD平臺的搭建和具體實現，積累了一些體會，也正在整個公司進行推廣和應用。這裡先開個頭，時間允許的話儘可能把這一系列的文章完成，不要太監哈哈。另外，本篇部分概念和文字引用了其他持續交付相關文章的觀點和截圖，如有雷同，純屬我個人偷懶。
參考大神： https://testerhome.com/topics/9977
目錄結構:
-
持續交付實踐-認識jenkins pipeline
- 1.pipeline使用-快速入門
- 2.pipeline使用-語法詳解
- 3.pipeline使用-專案樣例
- 4.pipeline使用-Multibranch Pipeline
- 5.pipeline使用-Shared Libraries
- 6.pipeline使用-Jenkins Pipeline高可用性設計
- 編外1-Jenkins User Confluence China：參會見聞
-
持續交付實踐-設計交付流水線
-
持續交付實踐-研發協作平臺建設實踐