<b>說明：關于oops的寫法，oops在英文中用在犯錯了時發出“哎喲”聲，剛開始提到devops，大家覺得是一個很先進的方式，可以提升開發和運維之間的效率，但是實踐中，發現devops做的不恰當就會變成dev “oops”，也就是“做不好的devops就會被調侃為dev oops”，此為技術圈的黑幽默。</b>
在雲栖大會開源專場，來自阿裡雲的進階開發工程師莫源為現場聽衆帶來了題為《dev oops ? no , devops！》的分享。在分享中，莫源從持續傳遞之禅、持續傳遞系統jenkins以及derrick助力開發者輕松容器化三個方面由淺入深地講述了devops是如何通過選擇合适的工具降低等待和技術成本，提高企業自動化。
以下内容根據現場分享和幻燈片整理而成。
devops的趨勢
devops越發被開發者所提及，尤其在與docker相關的領域，devops被認為是開發者快速部署的最佳實踐。從2016年統計結果來看，74%的開發者已經開始使用devops，而這一資料在15年隻有66%；企業界已有81%的企業已采用devops，而這一資料在15年隻有70%。然而，統計資料表明62%的開發者在使用devops時需要他人指導；44%的開發者仍處于調研和測試devops的初級階段。由此可見，devops是一種勢不可擋的趨勢，但同時也是“屍橫遍野”的戰場。
大家口中的devops
為了更好地了解devops，下面分别來看一下兩個常見的最簡化持續傳遞流程——傳統應用的持續傳遞流程和容器化應用持續傳遞流程。
傳統應用的持續傳遞流程是從代碼開發送出代碼到代碼倉庫；代碼倉庫觸發建構後，由持續內建系統測試、預發并正式環境部署。
容器化應用持續傳遞流程如上圖所示，相比于傳統應用的持續傳遞流程，容器化應用在持續內建系統中新增了鏡像建構與推送，之後再通過分發編排模闆完成部署。
很多開發者從各類演講或者社群中拿到上述類似的方案後就回到公司開始進行devops實踐。然而，在企業實作過程中，devops的實施變得越加複雜，有的企業在實施devops時引入了新的架構、新的部署環境（paas、docker、serverless）；有的企業引入了新的工具鍊、新的流程以及新的“職位”。這新引入的一切給企業帶來了更多生産營運的成本。但這并不是devops想要的結果！
devops不是讓你成為全能忍者（既懂開發又懂運維，還能兼顧測試），而是消除“等待”與“浪費”。在傳統的服務流開發模式中，從前期的需求分析、設計、實作、驗證到後期的運維部署，每一個流程都是由不同的角色負責，例如産品經理負責需求分析和設計、開發工程師負責實作、驗證是由測試工程師負責，而後期的維護是運維工程師的職責。是以，也就産生了“等待”與“浪費”，“等待”與“浪費”出現在項目流轉過程中，不同角色交替職責時，比如說等待基礎架構的設計、等待應用程式部署、等待其他團隊的回報，甚至有時需要等待漫長的稽核流程。
那麼devops是怎樣消除這些“等待”造成的“浪費”呢？首先一點是消除不必要的流程；第二消除不必要的特性；第三消除不必要的人工；第四消除不必要的返工。
devops之禅
那麼devops到底是怎麼解決上述提到的等待和浪費呢？答案就是分而治之，将大的目标分成不同的、小的目标，每一個子類目标可以進行快速的設計、開發、測試和傳遞。利用分而治之分方式讓每一個步驟可驗證、可傳遞。先分而治之，讓一個大的開發周期變成小的開發周期再進行快速開發是devops之禅，一味地追求自動化部署反而違背了持續傳遞的初心。
<b>devops熱門的領域</b>
devops最近幾年的熱門領域主要是cloud native、microservices、docker和serverless，這四個領域經常和devops結合在一起。devops的本身并不是一個技術問題（而是業務問題），但是技術的變革需要devops來填平帶來的技術成本。devops實作是一個擴充卡，封裝了本地開發與遠端傳遞之間的實作。
近年來，devops的工具鍊變得越發繁多和複雜。是以，選擇适合企業業務的工具鍊尤為重要。傳統應用和容器化應用傳遞的過程中，其核心都是持續內建伺服器。換句話說，持續內建伺服器是devops最重要的一環，是傳遞流程的發動機。在開源領域，持續內建伺服器最為有名的是jenkins，也是最适合的持續內建産品。
<b>jenkins</b>
jenkins可以在非常多的場景中和其他的持續傳遞工具進行內建。
上圖展現了jenkins的幾大特性，首先jenkins具有非常強大的插件支援，目前大概有1000左右的插件可用；第二，可以與100多個devops工具無縫集合使用；第三，它還可以和devops的工具鍊內建；最後，它還可以和devops的pipeline內建，上圖也給出了不同階段下，jenkins可以內建的工具。
jenkins固然很好，但其也存在自身的問題。大家對jenkins1.0有所诟病，主要是jenkins1.0其老派的設計和功能。
而在今年新釋出的jenkins2.0版本中，我們可以看到如下5個方面的更新：
（1） ui 更新，新版的ui界面如上圖所示。
（2） pipeline as code (pausable,durable)
（3） servlet3.1 and websocket
（4） docker support in pipeline
（5） blue ocean beta
為了讓開發者更好地使用jenkins，阿裡雲在在jenkins相關的領域做了一系列的增強：
（1）目前，阿裡雲提供一鍵部署jenkins及slaves的能力:
·提供go、java、python、php、node.js的slave鏡像；
·基于docker-compose一鍵部署master與slave叢集；
·基于容器服務的運作時管理，可以動态生成任務建構容器。
（2）提供更多針對阿裡雲環境的部署插件（容器服務）：
·阿裡雲容器服務插件。
（3）提供jenkins基于阿裡雲場景的devops方案（ecs、容器服務）：
·惠及雲計算的能力，實作cloudops、containerops；
·藍綠無當機釋出、彈性擴容應對尖峰流量等。
jenkins容器服務解決方案
阿裡雲結合雲服務的管理能力、docker的标準化傳遞能力與jenkins的強大的插件系統與任務分發引擎，為開發者提供雲原生的jenkins containerops解決方案。
devops改造例子
下面分享一個客戶利用devops改造docker的真實案例。
該客戶原來的結構分為本地開發、測試環境測試、內建環境、預發部署測試、線上部署、運維與報警。其中前兩個過程是開發感覺，中間兩個過程是測試感覺，最後兩個過程是運維感覺，而整體過程是由架構師感覺。
當其進行devops改造之後，中間的步驟基本都采用自動化的方式，自動化整體設計是由架構師負責完善地。改造完成之後，devops節約了大量時間和成本，讓架構師更多的感覺架構的改造；讓開發專注在本地的開發上；運維更專注于線上運維與部署。
基于docker的devops的難點從來不是如何搭建持續內建伺服器，也不是如何通過容器管理平台進行運維。而是docker帶來的學習成本（dockerfile是第一大門檻）。從四個角色來講，運維工程師和架構師是不可能不感覺docker的，那麼我們是否可以讓開發者盡量少的感覺docker的存在？
答案是必須的——derrick！
derrick主要解決的就是讓開發者專注本地開發，降低docker的學習成本；它通過獨特的機制自動生成dockerfile，讓開發者無感覺docker的情況下在本地調試容器化的應用；此外，derrick現已支援node.js、python、java等多種語言，并将于近期開源，敬請期待。