<th id="0poub"></th>
  1. <th id="0poub"><track id="0poub"><dl id="0poub"></dl></track></th><dd id="0poub"><track id="0poub"></track></dd>

    <dd id="0poub"></dd>
    <dd id="0poub"><pre id="0poub"></pre></dd><th id="0poub"></th>
    <th id="0poub"><track id="0poub"></track></th>
    <tbody id="0poub"><pre id="0poub"></pre></tbody>
    <em id="0poub"><acronym id="0poub"><kbd id="0poub"></kbd></acronym></em>
    logo

    地址:深圳南山區大沖國際中心21樓

    聯系我們 : contact@wise2c.com

    產品支持 : service@wise2c.com

    售前咨詢 : sales@wise2c.com

    電話: +86 (755) 33268246

    粵ICP備16049363號

    一月 2017

    • All
    • 技術漫談
    • 最佳實踐
    • 睿云新聞
    • 行業資訊

    關于持續交付你準備好了嗎?

    分享人:鄭云龍 時間:2016-8-25 睿云智合持續交付產品負責人,在敏捷和DevOps領域有豐富經驗的實踐,過去作為敏捷和DevOps技術教練向多家大型企業提供咨詢和培訓服務。   持續交付理論要解決的最重要的問題就是,如何以最快的方式將我們的軟件交付到客戶手上;如何實現可靠,迅速并且低風險的軟件發布。   在傳統的軟件開發方法中我們更多的關注軟件研發環節,而DevOps運動則將軟件研發活動的視角從傳統的需求,開發,測試等活動延伸到了部署,發布以及運維過程中。 軟件的核心價值是為軟件的使用者帶來收益,在過去我們經常聽到開發人員說這個功能已經開發完成了。?但是在持續交付中我們認為之后將特性真正的發布到用戶手上才以為則完成。 持續支付     而要想達到持續交付的目標即實現可靠,迅速并且低風險的軟件交付需要所有相關人員(需求,開發,測試,運維)的協同工作才能保證這一目標的實現。 在持續交付過程中我們希望一個團隊是能夠充分自治的,能夠完成從軟件的需求,設計,開發,部署以及運維的端到端所有工作。 全功能團隊         本文將以持續交付的8個原則來闡述在持續交付過程中的那些方法和實踐:   原則一:為軟件的發布創建一個可重復且可靠的過程 在傳統的軟件研發模式中瀑布式的工作方式深入到軟件研發的各個環境。 在軟件的發布過程中充滿了各種等待: 構建和運維人員在等待說明文檔或者缺陷修復 測試人員等待“好的”版本構建出來 研發團隊可能在新功能發布幾周后才收到缺陷報告 最終的結果就是軟件產品遲遲不能發布甚至延期,同時由于開發與測試,開發和運維之間的過長的反饋周期直接導致軟件產品的質量低下,同時可能并不能真正的為使用者帶來價值 同時如果管理者想要對整個軟件交付過程進行改善將會很容易陷入到局部優化的惡性循環當中,很難真正了解交付的問題瓶頸 而持續部署流水線則是解決這一問題的最佳方式,建立持續部署流水線即建立了一套端到端的軟件交付流程,同時在持續部署流水線的流程當中參與到軟件交付的各個角色都能各司其職,形成一套高效的“拉動系統” 開發人員持續的查看代碼度量數據以及測試失敗等問題,測試人員自助部署測試環境,同時運維人員也可以通過一鍵方式將軟件部署到預生產環境以及生產環境。同時對于管理人員也可以通過度量持續部署流水線的各個環境來分析交付問題,通過合理的方式優化軟件交付流程當中存在的問題。 而將持續部署流水線中的各個環節可以劃分為如下幾個不同的階段 提交階段 該階段主要從技術層面證明軟件系統是可以工作的,該階段會進行軟件的編譯,以及以單元測試為主的自動化測試,以及代碼分析 自動化驗收測試階段 該階段主要從功能和非功能需求角度正面軟件是能夠滿足用戶的需求以及相關的需求驗收條件 手動測試階段 該階段主要試圖發現那些自動化驗收測試不能覆蓋的缺陷,同時證明系統是否能夠真正的為用戶提供價值,所以在該階段中通常需要由測試人員完成相關的探索性測試,集成測試以及用戶驗收測試 發布階段 發布階段則旨在將軟件產品發布到用戶手中包括軟件包發布或者是直接將軟件部署到生產環境   原則二:將幾乎所有事情自動化   為了搞笑的支持持續部署流水線,我們需要將除了探索性測試以外幾乎所有的事情都自動化。 在軟件交付過程中對于自動化我們可以分為兩個方面,一方面是指在產生軟件包過程中的如:編譯,打包,單元測試,集成測試,自動化驗收測試等活動。 自動化構建 在這個過程中我們使用例如maven,gradle這樣的構建工具可以幫助自動化的完成軟件的構建以及解決軟件依賴問題 自動化測試 同時借助諸如robotframework,以及cucumber這樣的自動化測試工具,以及采用BDD或者ATDD的開發實踐能夠幫助我們產生高質量的自動化驗收測試集 基礎設施及代碼 在虛擬化技術和容器化技術盛行的今天,通過諸如AWS的CloudFormation以及Docker的Dockerfile等我們可以將我們的基礎設施也變成自動化的 另一方面則涉及到與軟件運行相關的自動化如包括基礎設施的自動化管理,運行環境的自動化配置,軟件本身的安裝與配置等等 自動化配置管理 自動化配置管理工具如ansible,puppet,chef等相比傳統的腳本。通過dsl環境描述的過程將服務器環境的準備過程變成自動化的,可重復的,并且能夠支持大規模的集群管理   原則三:把所有東西納入版本控制   在過去通常而言我們的svn或者git當中只存在我們源代碼本身,而在持續交付過程當中我們認為任何會對軟件的行為,質量產生影響的部分都應該要做版本化的,并且這些任何部分的每一次變更都應該通過持續部署流水線的形式來進行自動化的驗證。確保任何的變更,如代碼變更,測試用例變更,環境配置變更都能得到快速的驗證,以及反饋 這些相關的“變更集”包括:基礎設施描述文件,源代碼,測試腳本,自動化測試用例,環境配置腳本,部署腳本,以及數據庫的創建,升級,以及回滾腳本等。 從上面的“變更集”也可以看出,持續交付是一個團隊所有人員和角色都應該參與的事情,并且每一個人都對軟件交付富有責任   原則四:提前并頻繁的做讓你感到痛苦的事情   “如果集成是讓你感到痛苦的,那么每一次代碼提交都應該進行集成,而且應該從項目一開始就開始這么做;如果發布軟件過程前測試是一件痛苦的事情,那么就應該從項目一開始就不斷的進行測試;如果軟件發布是一件痛苦的事情,那么每一次代碼提交在完成自動化驗收測試之后都應該進行發布,或者至少發布到類生產環境”   原則五:內建質量   在持續交付過程中持續交付流水線定義了一套標準的,可重復的軟件交付流程;同時借助大量的工具我們可以將這個流程中的機會所有事情都進行自動化。但是另外一個點就是軟件質量。 根據原則四,其實我們也可以推斷出如果對代碼進行測試是一件痛苦的事情,那么在編寫實現代碼之前我們就應該寫測試,TDD,ATDD,BDD等軟件研發實踐正是體現了這一基本原則。 內建質量是戴明提出的名言之一。越早的發現缺陷,修復它們的成本越低。 根據內建質量的原則我們可以知道在軟件交付過程中,測試并不是一個階段,所以并不應該在開發介紹之后才開始。同時測試也不應該主要是測試人員的職責,參與交付的所有人都應該對軟件的質量負責 其中測試四象限很好的闡述了為了確保軟件質量而應該做的各種類型的測試建模   原則六:“Done”意味著“已發布” 在持續交付過程中認為一個特性的交付在理想狀態下應該是已經發布到用戶手中,或者至少已經向用戶進行了演示。 相應的在敏捷開發中,我們每一個迭代結束后都應該想"用戶代表"進行演示,并且在“用戶代表”試用認為是完成了之后才意味則“Done” 其中“用戶代表”可以是正在的用戶,也可以是相關的業務人員   原則七:交付過程是每個成員的責任   在現實情況下,測試部門總是抱怨研發交付的軟件質量差,運維總是抱怨軟件不夠穩定,開發總是抱怨缺陷反饋周期太長,解決問題的成本過高。 而在持續交付當中我們知道,對于交付團隊而言最終目標是確保軟件能夠交付到用戶手中,并且產生相應的價值。 而通過持續部署流水線,我們將所有參與到軟件交付中的角色都聯合成了一個整體,并且各個部分之間是能夠快速的產生反饋,促成各個成員和角色之間的交流,并且快速的解決問題   原則八:持續改進   在任何一個充滿生機的組織當中持續改進是這個組織保持活力的基本要素之一。 參與軟件交付的成員需要定期對過去一段時間內的交付工作進行回顧,去發現在這個流程當中的做的好的方面,以及做的不好的方面,并且提出解決方案。     為了持續交付組織應該做好哪些準備?     交付團隊而非部門   根據康威定律“設計系統的組織,其產生的設計和架構等價于組織間的溝通結構” 由于存在部門墻的存在,導致開發,測試,運維之間的大量溝通成本,嚴重影響效率。甚至嚴重時部門和部門之間甚至會非常容易起沖突。 開發人員只管完成既定的功能缺乏系統整體性思考;測試人員根據需求文檔完成測試用例,但是卻不思考需求本身的合理性;運維人員則缺少對軟件架構本身的理解。各個部門看似各司其職進井有條,但是卻很難對軟件交付的效率和質量做出太多實質性的貢獻。正如開篇所述, 而通過“交付團隊”從項目一開始讓所有項目成員能夠參與到軟件的交付過程中,確保各個角色的人員能夠頻繁的進行交流,并且為了一致的目標而共同努力,這也是DevOps運動核心價值 而相同角色之間的溝通交流通過社團COP的形式來進行領域知識的交流和提升是一個不錯的方式     充分授權團隊   確保持續交付實踐的成功,賦能團隊,授權團隊也是整個組織應該思考的問題。在持續交付中我們知道一個團隊是一個應該是以做產品而非做項目為目標,需要充分授權團隊,使得團隊能夠完成從需求,開發,測試,上線的端到端過程。   當然在實際情況中,組織會有更多的因素需要考慮,比如最典型的場景比如由于落后的基礎設施管理方式導致運維團隊往往是被動的響應研發團隊的需求,并且存在大量手動的操作環節導致時間和資源的浪費     平臺化,服務化   公有云,私有云,容器云 通過組織級別引入虛擬化或者容器化技術以及相應的管理平臺如OpenStack,Rancher,Ks8等工具可以大大減少Ops團隊的運維團隊,在過去需要大量手工操作的過程都可以通過虛擬化平臺或者容器化平臺完成,研發團隊或者資源的周期從之前的幾天縮短到幾分鐘。 基礎設施自服務 同時對于Ops團隊則專注于提供底層的基礎設施資源,包括網絡,安全等相關管理。并將相關的資源以服務的形式暴露給團隊,各個產品團隊管理自己的基礎設施環境,維護持續部署流水線,以及軟件運行環境的變更 平臺化服務 同時對于企業和組織而言通過引入統一的平臺化服務,可以完成對所有產品團隊的統一管理,和監控。這些關鍵的平臺化服務可能包括:統一的日志管理平臺,持續交付平臺,以及監控和運營平臺等。 ...

    Read More

    Build MicroService With Spring Cloud And Rancher

    分享人:鄭云龍 時間:2016-7-20   睿云智合持續交付產品負責人,在敏捷和DevOps領域有豐富經驗的實踐,過去作為敏捷和DevOps技術教練向多家大型企業提供咨詢和培訓服務。 ?   1, Aganda ? 今天給大家分享的內容是:《Build MicroService With Spring Cloud And Rancher》主要內容:我們將演示如何通過Spring Cloud和Rancher構建一個具有彈性的微服務應用。并且在這個過程中當中我們主要遇到的問題,以及最后如何解決。 對于一個最簡單的微服務應用而言,一個最基本的結構如上所示: 我們需要一個服務發現和注冊服務幫助我們管理和發現新的服務; 當我們從一個單體應用到幾個,幾十個微服務時,服務的配置也成了一個非常棘手的問題,統一的配置管理必不可少; 為了簡化我們的客戶端調用我們可能需要一個輕量級API Gateway來統一代理我們的所有請求,同時可以做統一的安全控制; 同時在微服務下我們應該遵循Build For Failure的原則,當服務發生失敗時我們能夠隔離這些失敗的服務,從而需要引入Circuit Breaker熔斷器; 除此之外,同一個服務可能有一個到多個實例,當我們訪問服務時,我們還需要一個負載均衡器,幫助我們合理的分發我們的API請求。   2, Build MicroService With Spring Cloud   而Spring Cloud項目正是幫助我們解決以上問題的利器,讓我們可以更加專注于我們服務本身業務邏輯的開發,而將服務治理所需的工作都統統交給框架來完成。 Eureka提供了統一的服務發現和注冊能力; Ribbon和Hystrix則在服務和服務之間引入了負載均衡以及熔斷的能力; Zuul則作為一個輕量級的路由和代碼服務讓我們可以快速建立一個API Gateway的能力。 3, Service Discovery With Spring Cloud Netflix: Eureka   以Eureka提供的服務注冊和發現能力為例,作為一個微服務實例,在啟動時我們將會主動向Eureka Server進行注冊。Eureka Server服務維護當前服務的實例列表以及狀態健康檢查。????????而作為服務的使用者,我們首先需要向eureka server請求當前的服務實例,之后再將請求發送給API的真正提供者。   4, Client Side...

    Read More

    持續交付與Rancher——相得益彰

    分享人:鄭云龍 時間:2016-11-06   睿云智合持續交付產品負責人,在敏捷和DevOps領域有豐富經驗的實踐,過去作為敏捷和DevOps技術教練向多家大型企業提供咨詢和培訓服務。 『活動現場留念照』   11月6日在成都?- Docker與持續交付?技術沙龍成功舉辦~現場虛無坐席。 我司開發攻城獅-鄭云龍作為分享嘉賓,首先引入敏捷,DevOps,持續交付幾個方面的理論知識,然后分享了睿云智合(Wise2C)基于Rancher的DevOps實踐經驗和實現持續交付過程中遇到的其他挑戰。     『活動現場照』...

    Read More