DevOps是近幾年非常流行的系統研發管理模式，很多公司都或多或少在踐行DevOps。那麽，今天就說說特來電雲平臺在DevOps方面的實踐吧。

說DevOps，不得不說DevOps的具體含義。那麽，DevOps是什麽呢？是開發+運維麽？每個人都DevOps的理解都不盡相同，下面是一組對DevOps的定義，通過這組定義，我們基本可以看清DevOps是幹啥的。在這眾多的解釋中，我認為有一種解釋可以更貼切：DevOps是一種能力，具備此能力的團隊可以高質量、快速的交付軟件產品或服務。這個總結定義道出了DevOps的精神和根本內涵。

• 一組過程、方法與系統的統稱。用於促進開發、運維和質量保障部門之間的溝通、協作與整合。
• DevOps是一種文化轉變，或者說是一個鼓勵更好地交流和協作（即團隊合作）以便於更快地構建可靠性更高、質量更好的軟件的運動。
• DevOps 是一種工程模式，本質上是一種分工，通過對開發、運維、測試，配管等角色職責的分工，實現工程效率最大化，進而滿足業務的需求。
• DevOps主要解決兩個方面的問題：
• 按時、快速、高質量的交付軟件產品和服務
• 通過流程的自動化，節省成本

說到這裏，我們不僅要問到：DevOps與敏捷開發什麽關系？看上去，他們是如此的相似呢。那麽再要說說敏捷。敏捷開發到底什麽意思？這僅僅意味著快速嗎？簡單來說，敏捷開發意味著更多的叠代：更早更頻繁地發布產品更新。先把東西做出來，而不是像過去那樣過於憂慮產品是否完美。這就是那個“

在DevOps

• 更早、更頻繁地發布產品更新,永遠beta版,更快速的響應變化。
• 依托自動化工具（測試、部署），把開發、測試、發布、部署的過程整合，實現即時交付。

如要具備此能力，就要求DevOps的涉眾：開發、測試、運維，求同存異，為組織目標共同擔當，緊密配合，提升產品交付能力。啟用DevOps會對我們的帶來各種變革，總體來說主要有三個方面。DevOps的核心是角色的分工，而不是組織架構變化，垂直化的組織架構不代表可以實現DevOps所需要的分工模式，橫向的組織架構也不代表傳統的分工模式。DevOps的目標是工程效率最大化，它本身也只是一種方法論，是為了實現工程效率最大化的目標而存在的。

特來電雲平臺在實踐DevOps時，核心思路是通過無人值守的、全過程的自動化（自動構建、自動打包、自動部署、自動測試、自動發布），實現軟件研發、部署的流水線式作業。

當開發人員CheckIn代碼後，會觸發相關應用的自動構建，構建的過程會編譯源代碼並執行單元測試。單元測試是控制產品質量的第一道大閘，我們要求所有的單元測試必須100%通過，並且所有應用程序要從下面五個方面編寫單元測試腳本：內部核心類的公共方法、服務方法（HSF、SG）、符合場景測試、性能測試、破壞性測試。當單元測試執行通過後，會對產出物進行自動打包。因為特來電雲平臺采用了微軟.net技術路線，整個持續集成的過程，我們全部是基於微軟的TFS搭建。當然，TFS中沒有自動打包的特性，此特性是基於自主開發的補丁管理平臺實現的。通過補丁平臺不僅僅能制作補丁，還能夠為服務器安裝補丁。下面是一個公共技術部持續集成的面板。

持續集成結束產出的補丁包，會依次、自動部署到普通測試環境、準生產測試環境、壓測環境中進行各類自動化測試。普通測試環境，主要進行接口的自動化測試；準生產測試環境，主要進行接口自動化測試和UI的自動化測試；壓力測試環境主要進行性能測試和破壞性測試。當三類測試環境的自動化全部通過，管理員審批通過後， 補丁包首先會在上海數據中心灰度發布上線，24H後在北京數據中心發布上線。持續交付也是基於微軟TFS中的Release搭建，但是集成了很多特來電自主研發的系統。三類測試環境和生成環境都部署了特來電自主研發的分布式運維管理平臺、補丁安裝工具。通過分布式運維管理平臺，可以調動500+臺服務按照一定的規則更新補丁，此過程也是無人值守的。另外，三類測試環境分別部署了特來電服務治理平臺，通過此平臺實現接口測試、UI測試、壓力測試，並自動出具測試結果和測試報告。限於篇幅，分布式運維管理平臺和服務治理平臺，後續給大家詳細介紹。

下面是基於TFS搭建的持續交付的運行效果圖：

在搭建CI、CD的過程中，有非常多的坑需要踩，有技術方面的，也有管理方面的。曬一下重要的建議，希望可以幫助到大家。

1.要有清晰的產品分層結構。

2.清晰、明確的程序集引用關系：nuget、公共目錄

3.較全面的自動化測試代碼

4.全面的接口測試、UI自動化測試，否則持續集成就變成補丁發布工具

魏亮 2017-6-29

基於TFS的.net技術路線的雲平臺DevOps實踐