DevOps概念已經被越來越多的人所熟知，本文将從不同職能與DevOps的聯系，以及DevOps運動如何演變入手，希望可以幫助你對DevOps有更深刻的理解。

1

DevOps從哪來？

DevOps是敏捷軟件開發的産物，它是敏捷軟件開發的産物，是敏捷軟件開發為了跟上軟件開發速度和實現吞吐量而産生的。在過去的十年中，敏捷文化和方法的進步揭示了對端到端軟件交付生命周期更全面的方法的需求。

什麼是敏捷軟件開發？

敏捷開發是幾個疊代和增量軟件開發方法的總稱。最流行的敏捷方法包括Scrum、看闆、伸縮敏捷框架(安全)、精益開發和極限編程(XP)。

什麼是敏捷軟件開發？

雖然每一種敏捷方法在其特定的方法上都是獨特的，但它們都有共同的願景和核心價值(參見敏捷宣言)。它們都從根本上結合了疊代和疊代所提供的連續反饋，從而不斷地改進和交付軟件系統。它們都涉及到持續的計劃、持續的測試、持續的集成，以及項目和軟件的其他形式的持續發展。它們都是輕量級的，尤其是與傳統的瀑布式流程相比，并且具有固有的适應性。關于敏捷方法最重要的一點是，它們都集中于授權人們快速有效地協作并一起做出決策。

一開始，敏捷團隊主要由開發人員組成。随着這些敏捷團隊在生産軟件方面變得越來越高效，很明顯，将質量保證(QA)和開發作為單獨的團隊是低效的。敏捷發展到包括QA，以提高軟件交付的速度，現在敏捷再次發展到包括交付和支持成員，以将敏捷從構思擴展到交付。

DevOps理念通過在構建、驗證、部署和交付階段進一步簡化軟件變更的移動，從而擴展了敏捷開發實踐，同時賦予跨職能團隊從設計到生産支持對軟件應用程序的完全所有權。

DevOps是一種IT思維方式，它鼓勵軟件開發人員和IT操作人員之間的交流、協作、集成和自動化，以提高交付軟件的速度和質量。

DevOps團隊專注于标準化開發環境和自動化交付過程，以提高交付的可預測性、效率、安全性和可維護性。DevOps理念為開發人員提供了對生産環境的更多控制，以及對生産基礎設施的更好理解。DevOps鼓勵授權團隊自主構建、驗證、交付和支持他們自己的應用程序。

2

DevOps解決了哪些挑戰？

在開發DevOps應用程序之前，團隊負責收集軟件程序的業務需求并編寫代碼。然後，如果滿足需求，則由單獨的QA團隊在單獨的開發環境中測試程序，并發布操作要部署的代碼。部署團隊被進一步分割成孤立的組，比如網絡組和數據庫組。每當一個軟件程序被扔到一個獨立的團隊中，它就增加了瓶頸。這種範例的問題在于，當團隊分開工作時

• 開發人員通常不知道QA和Ops的障礙，這些障礙會阻止程序按照預期的方式工作。
• QA和Ops通常跨許多特性工作，很少涉及軟件的商業目的和價值。
• 每個小組都有相反的目标，當事情出錯時，就會導緻效率低下和相互指責。

DevOps通過建立協作的跨功能團隊來解決這些挑戰，這些團隊共同承擔維護運行軟件的系統的責任，并準備軟件在系統上運行，同時增加質量反饋和自動化問題。

一個常見的前Devops場景

開發團隊的目标是發布盡可能多的功能，他們會向QA提交一個新版本。然後測試人員的目标就是找到盡可能多的bug。當測試人員将他們的發現提交給開發人員時，開發人員會變得有戒心，并責怪測試環境中的測試人員。測試人員回答說，問題不在于他們的測試環境，而在于開發人員的代碼。

最終問題被解決了，QA把經過調試的新版本交給了Ops。Ops團隊的目标是限制對他們系統的更改，但是他們擔心發布代碼會導緻系統崩潰，互相指責。

Ops說Dev給他們提供了錯誤的工件。Dev說在測試環境中一切都運行良好。生産環境不是開發人員和質量保證人員的職責，所以當Ops花費整晚的時間來解決生産問題時，他們不會插手。

3

DevOps的目标是什麼？

改進所有涉衆之間的協作，從計劃到交付，以及交付過程的自動化

• 提高部署頻率
• 争取更快上市時間
• 降低新版本的失敗率
• 縮短修複時間
• 縮短平均恢複時間

根據2015年DevOps狀态報告，“高效能的IT組織部署頻率提高30倍，交貨時間縮短200倍；他們的故障減少了60倍，恢複速度提高了168倍。”

常見的Pre-DevOps場景軟件團隊在開始新的軟件項目之前會面。團隊包括開發人員、測試人員、操作人員和支持專業人員。該團隊計劃如何創建可用于部署的工作軟件。

每天，當開發人員完成代碼時，都會部署新的代碼。自動化測試确保代碼可以部署。在代碼通過所有自動化測試之後，它将被部署到少數用戶中。對新代碼進行短期監控，以确保不會出現無法預料的問題并且穩定。一旦監控顯示新代碼是穩定的，新代碼就會擴散到其他用戶。規劃和開發之後的許多(如果不是全部的話)步驟都無需人工幹預。

4

你在DevOps中處于什麼位置？

DevOps連續體是查看DevOps不同方面的一種有用的方法。底部的橫軸表示人們認為DevOps從根本上應該關注的内容。一些人堅定地認為DevOps應該更重視文化而不是工具，而另一些人則傾向于重視工具而不是文化。

縱軸描述了DevOps交付鍊的三個層次:持續集成、持續交付和持續部署。DevOps社區将位于DevOps連續體右上方的組織稱為粉色獨角獸，因為目前這種組織太少了.這些獨角獸公司中最流行的示例是Netflix、Etsy、亞馬遜、Pinterest、Flicker、IMVU和谷歌。在在最近的一次民意測驗中，參與者指出了他們的組織适合DevOps連續體的位置：

• 左下55％
• 右下角26％
• 14％左上
• 5％右上

思想領袖、博客作者經常在右上角描繪DevOps的願景，他們往往對DevOps文化或自動化工具有強烈的偏見。關于DevOps文化和工具哪個更重要的争論從未停止，但事實是沒有工具你就不能擁有DevOps，如果你沒有強大的支持文化，那麼世界上所有的工具都不會有幫助。

5

DevOps成熟的階段是什麼？

瀑布發展

在持續集成之前，開發團隊需要花三到四個月的時間編寫一組代碼。然後這些團隊會合并他們的代碼以發布它。不同版本的代碼會非常不同，并且更改太多，以至于實際的集成步驟可能要花費數月的時間這個過程非常低效。

持續集成

持續集成是将新開發的代碼與将要發布的代碼主體快速集成的實踐。當團隊準備發布代碼時，持續集成可以節省大量時間。

DevOps沒有提出這個術語。持續集成是一種源自極限編程方法的敏捷工程實踐。這些術語已經存在了一段時間，但是DevOps采用了這個術語是因為成功進行連續集成需要自動化。持續集成通常是實現DevOps成熟的第一步。

從DevOps的角度來看，持續集成過程包括檢入代碼，将其編譯成可用的(通常是二進制可執行的)代碼，并運行一些基本的驗證測試。

持續交付

持續交付是持續集成的擴展[DevOps階段2]。它位于持續集成之上。在執行持續交付時，通過添加自動化和測試，就不需要頻繁地将代碼與主代碼行合并，而是在幾乎沒有人工幹預的情況下部署代碼。這是一種讓代碼庫持續處于準備部署狀态的實踐。

持續部署

持續部署，不要和持續交付混淆，它是持續交付的最先進的進化。這是在沒有任何人工幹預的情況下将所有方式完全部署到生産中的實踐。

使用持續交付的團隊不會部署未經測試的代碼;相反，新創建的代碼在被推出生産之前通過自動化測試運行。代碼發布通常隻對一小部分用戶開放，在代碼進一步傳播之前，會有一個自動的反饋循環來監控質量和使用情況。

隻有極少數的公司真正實踐了持續部署。Netflix、Etsy、亞馬遜、Pinterest、Flicker、IMVU和谷歌都是進行持續部署的公司的成功示例。

6

DevOps的價值是什麼？

DevOps專注于建立協作文化并通過使用DevOps工具進行自動化來提高效率。雖然某些組織和人員傾向于彼此珍視，但事實是，要成功就需要文化和工具的結合。這是您需要了解的這兩個DevOps值的信息。

DevOps着重于建立一種協作文化，并通過使用DevOps工具的自動化來提高效率。

DevOps文化

DevOps文化的特點是增加協作、減少孤島、共享責任、自治團隊、提高質量、重視反饋和增加自動化。許多DevOps值都是敏捷值，因為DevOps是敏捷的擴展。

敏捷方法是一種更全面的軟件交付方式。敏捷開發團隊根據可工作的軟件來度量進展。産品負責人、開發人員、測試人員和用戶體驗人員為了相同的目标緊密合作。

DevOps隻是在敏捷團隊中加入了運維的思維模式，或許還會加入一名負責這些工作的團隊成員。在DevOps之前，進度是根據工作軟件來衡量的，而DevOps的進度是根據客戶手中的工作軟件來衡量的。

為了實現這一點，開發人員和運維人員必須打破孤島，彼此協作，共同維護運行軟件的系統，準備在系統上運行的軟件，并增加質量反饋和交付自動化。

DevOps工具

DevOps工具包括配置管理、測試和構建系統、應用程序部署、版本控制和監視工具。持續集成、持續交付和持續部署需要不同的工具。雖然這三種實踐都可以使用相同的工具，但是随着交付鍊的進展，将需要更多的工具。

7

DevOps中使用哪些工具？

前面我們簡要讨論了DevOps中使用的一些工具;下面是一些需要了解的關鍵工具和實踐。

源代碼庫

源代碼存儲庫是開發人員簽入和更改代碼的地方。源代碼存儲庫管理簽入的不同版本的代碼，因此開發人員不必重寫彼此的工作。

流行的源代碼存儲庫工具有Git、Subversion、Cloudforce、Bitbucket和TFS。

構建服務器

構建服務器是一種自動化工具，它将源代碼存儲庫中的代碼編譯為可執行代碼庫。流行的工具有Jenkins, SonarQube和Artifactory。

配置管理

配置管理定義服務器或環境的配置。流行的配置管理工具是Puppet和Chef。

虛拟基礎架構

AmazonWeb Services和Microsoft Azure就是虛拟基礎設施的例子。虛拟基礎設施由出售基礎設施或平台即服務(PaaS)的雲供應商提供。這些基礎設施具有api，允許您使用配置管理工具(如Puppet和Chef)以編程方式創建新機器。也有私有雲。例如，VMware有vCloud。私有虛拟基礎設施允許在數據中心的硬件上運行雲。

虛拟基礎架構與自動化工具相結合，使組織實踐DevOps的組織無需配置任何鍵盤即可配置服務器。如果要測試全新的代碼，則可以将其自動發送到雲基礎架構，構建環境，然後運行所有測試，而無需人工幹預。

測試自動化

測試自動化已經存在很長時間了。DevOps測試集中于構建管道中的自動化測試，以确保擁有可部署的構建時，已經準備好部署。在沒有任何人工幹預的情況下，不可能達到連續交付的結果，因為在沒有廣泛的自動化測試策略的情況下，代碼是可以部署的。最流行的工具是Selenium and Water。

管道編排

管道就像一條生産裝配線，從開發人員說“我想我已經完成”一直到代碼被部署到生産或後期預生産環境中為止一直發生。

,