隨著DevOps的普及，越來越多的人開始想要了解DEVOPS。DevOps是敏捷軟件開發為了跟上軟件開發速度和實現吞吐量而產生的，因此說DevOps敏捷開發的產物一點都不為過。那么到底什么是DEVOPS？DevOps工程師帶來了什么？本文將從DevOps的定義，以及DevOps工程師可以帶來什么，希望可以幫助你對DevOps有更深刻的理解。

　　什么是DEVOPS？

DevOps（英文Development和Operations的組合）是一組過程、方法與系統的統稱，用于促進開發（應用程序/軟件工程）、技術運營和質量保障（QA）部門之間的溝通、協作與整合。它的出現是由于軟件行業日益清晰地認識到：為了按時交付軟件產品和服務，開發和運營工作必須緊密合作。

對于DevOps的提出已經很多年，其主要的推動仍來自兩個方面：

1. 業務和需求驅動下，推動敏捷方法論，敏捷下需要更加短周期，更快的發布和交付。

2. 技術和運維部門需要銜接，在PaaS和容器技術發展下，進一步推動這部分陷阱的自動化。

雖然是三方交融地方為DevOps的內容，但是可以看到DevOps本身更多的是要解決兩大類協同和自動化的問題，其一是開發部門和QA協同，其二是開發部門和運維的協同。

1. 第一個問題的解決：已有的持續集成方法論；

2. 第二個問題的解決：當前由云平臺，微服務架構，容器技術發展推動的自動化發布和監控運維；

把上面思路理清楚后，對于DevOps要做或需要解決的事情也就更加明確的。

1. 實現軟件和硬件基礎設施（云平臺資源）的對接（自動部署，動態擴展）-PaaS，Docker；

2. 實現不同環境間的自動遷移 - 持續集成+自動化遷移；

3. 能夠滿足更加高頻率的發布節奏，單次發布更加快速 - 持續集成；

4. 能將QA和QC部分檢驗和審查工作自動銜接到發布和交付過程 - 自動化測試，自動化監控；

要做好DevOps基于上面的分析就可以從持續集成和PaaS平臺融合兩方面來談。

　　DevOps和持續集成

對于持續集成我前面已經專門有文章談到過，這個沒有提DevOps概念的時候也在做持續集成，通過持續集成真正實現了版本和配置管理，單元測試，自動構建，環境遷移和配置修改，集成順序規劃這些關鍵內容。

比如我們常說的一個工具組合：Jenkins，Maven，Ant , Junit，SubVersion 。 為了更好持續異地協同開發，以及后續和公有云PaaS融合，版本庫可以轉到GitLab或GitHub上面。

在持續集成里面我們經常會談一個重點，即業務系統是基于組件化架構的，即各個組件可以獨立管理和部署，組件之間通過服務接口松耦合。只有這樣才能將后續增量發布影響降低到最小。這個概念現在轉到微服務架構里面來進一步實現。

　　DevOps和PaaS平臺融合

對于和PaaS平臺融合是DevOps的第二個內容，我們希望的就是我們在測試態測試和驗證完成的部署包能夠自動的交付和遷移到生產環境的托管資源中。在這里就涉及到PaaS平臺提供的自動部署和托管，資源動態管理等方面的能力。

比較重的：Cloudfoundry或Cloudify能提供完整的解決方案。

比較輕的：我們可以基于Docker容器技術+Kubernetes+Puppets來實現自動化和動態資源管理。

在PaaS平臺下，由于部署和資源的動態管理都被PaaS平臺完全接管，因此更加需要整個平臺必須提供完整的日志管理，傳統IT網管，中間件資源池監控，包括到APM層性能分析的完整解決方案和工具集。要實現這些你可以在監控方面用Nagios或zabbix解決方案。日志管理和分析可以用ELK方案，整個過程中的自動化腳本用Puppet等。

一個DevOps是否執行的好基礎指導是敏捷和持續集成的方法論，難點在多版本管理和微服務架構設計（組件劃分是否合理）和后期的監控運維。

　　DevOps工程師帶來了什么？

傳統的軟件開發流程是軟件開發人員花費數周和數月編寫代碼，然后將代碼交給QA團隊進行測試，然后將最終的發布版交給運維團隊去布署。所有的這三個階段，即開發，測試，布署，之間缺乏協作。

開發者編寫代碼然后交給布署團隊。現在由布署團隊來解決代碼布署過程中出現的問題，或將代碼交給開發團隊以修復bug。所有這些都導致軟件開發過程變慢。

但是在DevOps模式下，這三個團隊將不再相互隔離。大多數時候，這三個團隊將合并成一個團隊，工程師會在整個應用程序生命周期中工作，從開發和測試到布署到操作，并開發出一系列不限于單一功能的技能。安全團隊也可以在整個應用程序生成周期中和開發和運維更緊密的合作。

以上就是關于什么是DEVOPS，以及DevOps工程師帶來了什么的全部內容，想了解更多關于DEVOPS的信息，請繼續關注中培偉業。