【學習資料】持續集成---測試自動化學習

時間 2019-11-08

原文原文鏈接

[持續交付實踐] 開篇：持續集成&持續交付綜述

前言

隨着微服務架構與容器虛擬化技術的發展，持續集成與持續交付的概念又從新回到了你們的視野，愈來愈多的公司開始使用持續集成的系統來解決頻繁發佈帶來的質量問題；使用持續交付的工具來實現代碼在不一樣環境上的自動部署。本來有些學院派烏托邦式的思想正被千千萬萬次的集成與部署證實着它應有的價值。php

持續交付的概念和產生

傳統軟件的開發與交付的週期都很漫長，一款普通的企業軟件一般須要十幾個開發人員，幾個月的時間來完成，從需求的分析、系統的設計、編寫測試用例、系統開發、單元測試、組裝測試到交付調試。有條不紊的流程與規範像一輛綠皮火車下的枕木，穩定而可靠的保證整個系統緩慢的推動，每一次交付、升級，都須要提供基礎的硬件、軟件的環境、軟件的代碼、軟件的文檔與手冊。
還記得剛剛邁入軟件開發行業的時候，跟隨公司的服務團隊，駐場交付產品，每個駐場工程師都按照以前預演過好多遍的流程，對照着系統的部署手冊，一步一步的組裝硬件，安裝軟件，稍有差池，就要按照對應的應急預案進行回滾。開始的時候以爲交付像一個神聖的儀式，將用智慧和汗水構建成的軟件交付給客戶使用，是一種很是榮耀和值得驕傲的事情；後來愈來愈屢次的產品交付讓我深深的感受每一次交付都像分娩同樣痛苦，捫心自問是否有簡單更舒暢的流程能夠將軟件交付給客戶呢？安全

要想快速的交付，首先要明白軟件交付過程當中遇到的核心問題是什麼。總結成兩個詞「自動」與「可靠」。自動是一個很寬泛的詞彙，在軟件交付中表明着測試自動化、交付自動化、運維自動化等等，而可靠講的是每一次交付要保證是當前的交付是穩定的或可回滾到穩定版本的。爲了解決「自動」與「可靠」的問題，敏捷開發鼻祖Martin Fowler提出了持續集成與持續交付的概念，它所描述的軟件開發，是從原始需求識別到最終產品部署到生產環境這個過程當中，需求以小批量形式在團隊的各個角色間順暢流動，可以以較短地週期完成需求的小粒度頻繁交付。頻繁的交付週期帶來了更迅速的對軟件的反饋，而且在這個過程當中，需求分析、產品的用戶體驗和交互設計、開發、測試、運維等角色密切協做，相比於傳統的瀑布式軟件團隊，更少浪費。經過這種小步快跑的方式，將小功能快速迭代、驗證、交付，經過自動化的工具，將測試、部署、運維自動化，減小需求在軟件生命週期中流動的時間。

《持續交付-發佈可靠軟件的系統方法》，Jez Humble DavidFarley，2011
2011年，Jez Humble編著的《持續交付(發佈可靠軟件的系統方法)》出版，持續交付的理念迅速被軟件行業接受和流行。該書講述如何實現更快、更可靠、低成本的自動化軟件交付，描述瞭如何經過增長反饋，並改進開發人員、測試人員、運維人員和項目經理之間的協做來達到這個目標。《持續交付(發佈可靠軟件的系統方法)》由三部分組成。第一部分闡述了持續交付背後的一些原則，以及支持這些原則的實踐。第二部分是本書的核心，全面講述了部署流水線。第三部分圍繞部署流水線的投入產出討論了更多細節，包括增量開發技術、高級版本控制模式，以及基礎設施、環境和數據的管理和組織治理。

持續交付工具鏈

可是前輩只給了咱們先進的思想，並無給出默認的實現。不一樣的公司、不一樣的產品、不一樣的技術棧、不一樣的開發與部署形態決定了持續集成與持續交付註定是因人而異的，你們不斷摸索什麼樣的方式是持續集成與持續交付的最佳實踐。歸根結底，持續集成與持續交付的難點在於如何屏蔽不一樣語言、不一樣框架、不一樣系統之間的持續集成與持續交付流程的差別性。曾經幻想過是否能有一種方式能夠歸約軟件的交付，而這就是Martin Fowler留給咱們的課後思考題-論如何實現持續集成與持續交付的流程標準化。
當你問十個哲學傢什麼是哲學的時候，你會獲得十一種答案，由於每一個人都有對哲學不一樣的理解，對於持續交付也同樣。我的選取了目前開源社區中最流行和優秀的開源軟件，通過改造後搭建了全開源端到端交付流水線，這應該也是目前各大互聯網公司使用最普遍的方案。其中Jenkins做爲業內優秀的的CI/CD工具，擔任整套了工具鏈的核心組織工做。markdown

國內一些公司開發的輪子【非廣告】：
阿里雲效/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強調的是從開發到運維的交付，傳統的持續集成則更強調產品研發過程（開發+測試）。運維

因此，大家開心就好^_^