本以為DevOps與Docker無關了，沒想到Docker在這個領域也是神一樣的存在。Docker支援持續整合/持續互動(CI/CD)，Docker的目標是讓我們的環境構建變得簡單，讓開發人員更關注自己的程式碼，同時也不需要運維介入，每一次程式碼的提交都可以實時地釋出到對應的測試環境，提前驗證程式碼的正確性。這之中持續整合最經典的案例當屬Docker+Jenkins+Github的持續整合方案了，下一篇會詳細描述實踐過程。本文還是先來看看到底什麼是DevOps,以及它的核心理念。

什麼是DevOps

DevOps（Development和Operations的組合詞）是一種重視“軟體開發人員（Dev）”和“IT運維技術人員（Ops）”之間溝通合作的文化、運動或慣例。透過自動化“軟體交付”和“架構變更”的流程，來使得構建、測試、釋出軟體能夠更加地快捷、頻繁和可靠。--

提到DevOps不得不提到的就是持續整合：

持續整合是一種軟體開發實踐，團隊成員經常整合他們的工作，通常每個人至少每天整合 - 每天都會進行多次整合。 每個整合都通過自動構建（包括測試）進行驗證，以儘可能快地檢測整合錯誤。 許多團隊發現，這種方法導致了大大降低的整合問題，並允許團隊更快地開發連貫的軟體。

為什麼會有DevOps?

DevOps這個新理念的出現，是為了應對IT環境中普遍面臨的一些挑戰。


敏捷的出現縮小了上圖所示的第一個隔閡，也就是商業需求和開發之間的隔閡，有效的加快了產品開發的週期和效率。那麼這無疑為運營團隊增加了很多壓力。

於是上圖中第二個隔閡，也就是開發和運維之間的隔閡需要解決，於是DevOps的理念應運而生。

與DevOps相關的概念

持續整合（Continuous Integration ，CI）

在傳統軟體開發過程中，整合通常發生在每個人都完成了各自的工作之後。在專案尾聲階段，通常整合還要痛苦的花費數週或者數月的時間來完成。持續整合是一個將整合提前至開發週期的早期階段的實踐方式，讓構建、測試和整合程式碼更經常反覆地發生。

持續整合意味著一個在家用筆記本編寫程式碼的開發人員（嘿，程式設計師A）和另一個在辦公室程式設計的開發人員（嘿，程式設計師B）可以為同樣的產品分別地編寫軟體，將其改動整合在一個叫做源儲存庫的地方。他們可以從各自編寫的部分構建出組合的軟體，並且按照他們期望的方式來測試軟體。

開發人員通常使用一種叫做IC Server 的工具來做構建和整合。持續整合要求程式設計師A和程式設計師B能夠自測程式碼。分別測試各自程式碼來保證它能夠正常工作，這些測試通常被稱為單元測試（Unit tests）。

程式碼整合以後，當所有的單元測試通過，程式設計師A和程式設計師B就得到了一個綠色構建（green build）。這表明他們已經成功地整合在一起，程式碼正按照測試預期地在工作。然而，儘管整合程式碼能夠成功地一起工作了，它仍未為生產做好準備，因為它沒有在類似生產的環境中測試和工作。在下面持續交付部分你可以瞭解到持續整合後面發生了什麼。

考慮到實踐持續整合，程式設計師A和程式設計師B必須頻繁地登記主程式碼倉庫、整合和測試他們的程式碼。通常一小時很多次，並且每天最少一次。

持續整合的好處是，整合不再是個頭疼事。軟體在一直被編寫和整合。在持續整合之前，整合發生在建立過程的結尾階段，一次性完成，並且不知道要耗時多久。而現在持續整合，每天都融入到了工作方式當中。

持續交付（Continuous Delivery，CD）

讓我們說回到我們的兩位開發人員，程式設計師A和程式設計師B。持續交付意味著每次程式設計師A或程式設計師B修改、整合和構建程式碼時，也同時在類似於生產環境中自動測試了這段程式碼。我們通常將這個在不同環境釋出和測試的過程叫做部署流水線。通常部署流水線有一個開發環境，一個測試環境，一個準生產環境，但是這些階段會根據不同的團隊、產品和組織而變化。例如，Mingle團隊有一個階段叫做“紙杯蛋糕”的準生產環境，而Etsy的準生產環境叫做“公主”。


在不同的環境下，程式設計師A和程式設計師B寫的程式碼被分別進行測試。當代碼部署到生產環境它就開始了工作，這給予了他們更多的信心。並且只有當代碼通過前一個環境的測試才會進入到下一個部署流水線的環境當中去。通過這種方式，程式設計師A和程式設計師B將會從每個環境中測試並得到新的反饋，如果有失敗，他們也可以在程式碼被應用到生產環境之前更加容易地發現問題並且修正它。

將 DevOps 整合到軟體生命週期中

IBM DevOps 方法簡介

IBM DevOps 方法加快並維持您在規劃、開發、測試和交付方面的軟體推動的創新。無論您的關注點是移動開發、雲託管、大資料分析還是社交商務、您都可以更快地持續釋出更好的軟體和服務，而且成本更低，風險也更小。

IBM DevOps 通過吸引並協調軟體交付生命週期中的所有參與者來完成其工作，這些參與者包括業務團隊、架構師、開發人員和測試人員、還有 IT 運營和生產人員，他們都有一個共同的目標：持續創新，通過持續交付來支援持續創新，並通過持續反饋來改進創新。

採用 IBM DevOps 的前提條件

包含 IBM DevOps 方法的組織遵循 4 個指導原則。

• 協作學習文化非常重要
• 敏捷開發和自動化可加速創新
• 反饋迴圈可縮短反饋的時間
• 整個系統成為了目標

敏捷方法和自動化可加速創新

IBM DevOps 在整個軟體開發生命週期中擴充套件了敏捷的、迭代的開發實踐（開發、測試、部署、驗證和調整）以及精益思想原則。

開發和測試類似生產的系統 與使用可重讀的、可靠的流程執行可迭代的、頻繁的部署 的敏捷特徵是 DevOps 採用中的主要部分。敏捷實踐提供了一些結構和規則，根據使用者的需求，始終如一地向用戶交付寶貴的軟體。

系統化地消除一些行為和易錯活動也是加速軟體交付的關鍵。最大程度地減少引入的手動誤差的一種方法就是部署自動化，自動化可加快測試和交付流程，同時確保滿足法規需求。

自動部署有助於軟體更快地到達生產伺服器（物理、虛擬或雲），從而加快上市時間。您可以建立可重複、無差錯、可擴充套件的應用程式部署流程，並獲取版本所在位置的可見性。相反，如果進行手動部署，那麼部署、測試和生產環境中的差異（以及不連貫的部分流程）可能造成部署失敗。

通過使用電腦自帶的功能來處理重複的任務，團隊可以進行一些批判性的思考，並提供一些有創造性的問題解決方案。

DevOps 的技術棧與工具鏈

Everything is Code，DevOps 也同樣要通過技術工具鏈完成持續整合、持續交付、使用者反饋和系統優化的整合。Elasticbox 整理了 60+ 開源工具與分類，其中包括版本控制&協作開發工具、自動化構建和測試工具、持續整合&交付工具、部署工具、維護工具、監控，警告&分析工具等等，
補充了一些國內的服務，可以讓你更好的執行實施 DevOps 工作流。

•     版本控制&協作開發：GitHub、GitLab、BitBucket、SubVersion、Coding、Bazaar
•     自動化構建和測試:Apache Ant、Maven 、Selenium、PyUnit、QUnit、JMeter、Gradle、PHPUnit
•     持續整合&交付:Jenkins、Capistrano、BuildBot、Fabric、Tinderbox、Travis CI、flow.ci Continuum、LuntBuild、CruiseControl、Integrity、Gump、Go
•     容器平臺: Docker、Rocket、Ubuntu（LXC）、第三方廠商如（AWS/阿里雲）
•     配置管理：Chef、Puppet、CFengine、Bash、Rudder、Powershell、RunDeck、Saltstack、Ansible
•     微服務平臺：OpenShift、Cloud Foundry、Kubernetes、Mesosphere
•     服務開通：Puppet、docker Swarm、Vagrant、Powershell、OpenStack Heat
•     日誌管理：Logstash、CollectD、StatsD
•     監控，警告&分析：Nagios、Ganglia、Sensu、zabbix、ICINGA、Graphite、Kibana

順便再分享一個 DevOps BookMarks，涉及了DevOps方方面面的工具和內容，有興趣可以去學習下。

參考資料