第一部分：實施DevOps的八個常見步驟
https://www.tuicool.com/articles/QbueymE
Gartner的研究主管George Spafford說：“由於缺少標準的定義和方法，處於不斷發展中，需要接受和管理風險，DevOps對傳統IT思維提出了挑戰。這個不確切的目標狀態導致許多IT部門猶豫不決、不敢實施DevOps策略。”
雖然沒有一系列具體的所需階段，但Spafford建議基礎設施及運營（I&O）領導人可以遵循這八個基本步驟來搞好DevOps項目。
1. 確定業務理由
DevOps項目要關注業務需求，而不是“純粹爲了DevOps搞DevOps”，避免方法和工具變得比客戶需求還重要。企業要避免這個常見的錯誤：還沒有明確搞DevOps項目的業務理由，就貿然上馬。
Spafford解釋到：“比如說，先從業務價值入手，問問DevOps能帶來什麼，而不是專注於發佈速度、更快地完成工作。理由可能是‘通過提升發佈速度，我們能夠更快地創新，從而支持銷售和營銷部門使用移動應用進行訂購。’最成功的企業希望通過DevOps獲得業務的好處。”
2. 爲所在企業定義DevOps
Gartner對DevOps下的定義是：這是一種使用敏捷方法、協作和自動化交付解決方案的業務驅動方法。能以所在企業易懂的措辭來定義目標狀態顯得很重要。爲項目挑一個標籤，提供員工認同和支持的一個“標語”，這有助於員工參與進來。這個定義應簡短、明確重點，並支持業務理由。
3. 選擇“先行者”應用軟件
別指望一個步驟就部署好DevOps。DevOps要迭代式部署，每次同時滿足這三個要素：
- 友好的環境：這意味着大家願意使用先行者應用軟件，真心嘗試項目。
- 可接受的價值：先行者應用軟件要提供足夠的價值以贏得信譽和批准，以便繼續下去。
- 可接受的風險：由於DevOps方面的不確定性，許多人認爲它風險很高，害怕開始入手。企業應指出風險可接受的機會，因爲IT、運營、開發、信息安全，法規遵從和審計等部門的每個人都要學習。
Spafford說：“DevOps主要用於敏捷開發以及不確定性相當大的場景（比如機器學習和物聯網），但由於DevOps理念可以廣泛應用，所以會有引入這套概念的其他機會。然而，最初運用於創新的系統通常比較好，因爲現有功能可能無法支持像大數據、機器學習和物聯網這些項目。”
4. 確定初始團隊
人員是成功的DevOps項目的主要因素。挑選初始團隊的成員時，要注重行爲而不是注重技能。教技術技能比教正確行爲來得容易――錯誤的行爲會使DevOps工作偏離正常進程。物色優秀的團隊成員，要聰明、有幹勁，瞭解風險，致力於終生學習，還能適應新的工作方式。
5. 確立目標和度量指標
因爲人員是DevOps項目中最重要的因素，瞭解和實施合適的激勵措施至關重要。Spafford說：“在許多傳統企業，目標由各部門確立，IT度量指標落實到位，以解決問題，獎勵解決問題的人員。”
“在DevOps項目中，目標要由團隊確立，並與下達給團隊的業務目標保持一致。DevOps團隊成員要認識到他們都有同一個目標，度量指標和激勵措施要鼓勵團隊合作以實現業務目標，而不是度量指標強化風險規避和解決個別問題。”
6. 專注於限制因素
I&O領導人應找出限制生產能力的最大瓶頸。開發新的和變更的系統，並轉移到生產環境中，這個生命週期會帶來最大的限制因素，因而限制生產能力。如果專注於這個最大的限制因素，DevOps團隊就能系統地識別什麼在阻礙所需的工作節奏，並克服這個瓶頸。
7. 開發工具鏈
實施DevOps的總體目標包括一套集成的工具鏈，支持合理地評估和選擇工具，以便每個工具都與應用程序生命週期中的相鄰工具鬆散耦合。連接所有的自動化接觸點和信息流可藉助工具鏈來加快版本的發佈，同時減少錯誤、缺陷、返工和停運。這將讓在每個階段使用的工具得以保持一致，便於瞭解在階段內和階段之間哪個地方需要實現自動化、集成和工具轉換。
8. 準備好後擴展
太多的公司犯這樣的錯誤：開始DevOps之前就需要擴展，以便獲得批准。這導致了惡性循環。因爲他們不知道如何擴展DevOps，所以無法開始。而由於他們無法開始，就無法摸索並搞清楚如何擴展。
Spafford建議：“切莫還沒有準備好就試圖擴展，結果讓靠譜的DevOps項目偏離正道。”
“相反，把團隊召集起來，開始朝着似乎最有意義的方向前進，克服遇到的限制因素。人員、技術和流程方面一定要循序漸進。帶來技術債務是不可避免的，而管理這種債務是新模式的一部分。”
第二部分：持續集成工作中的標準規範
https://www.tuicool.com/articles/QRfMrmB
01
概述
持續集成是軟件工程領域中的一種最佳實踐，即鼓勵研發人員頻繁的向主幹分支提交代碼，頻率爲至少每天一次。每次提交都觸發完整的編譯構建和自動化測試流程，縮短反饋週期，出現問題第一時間進行修復，從而保證軟件代碼質量，減少大規模代碼合併的衝突和問題，讓軟件 隨時處於可發佈狀態 。
02
成熟度評估
首先針對企業當前的持續集成（集成服務、集成頻率、集成方式、反饋週期）做一次成熟度評估，瞭解所處的持續集成階段，並有針對性的制定持續集成目標和改造計劃。
03
持續集成前提條件
在開始持續集成之前，需要先做好以下事情，以讓持續集成能夠更加有效。
1. 頻繁提交
研發人員至少每天一次的將代碼提交到主幹上。
2. 全面的自動化測試套件
單元測試用於單獨測試應用程序中某些小單元的行爲(比如一個方法、一個函數， 或一小組方法或函數之間的交互)。
單元測試應該運行得非常快，即使對於一個大型應用來說，整個單元測試套件也應該在十分鐘之內完成。
3. 保持較短的構建和測試過程
理想情況下，提交前的預編譯和測試過程，以及持續集成服務器上的編譯和測試過程應該都能在幾分鐘內結束。我們認爲，十分鐘是一個極限了，最好是在五分鐘以內，九十秒內完成是最理想的。
測試需要劃分階段，第一個階段用於編譯軟件，運行所有類級別的單元測試，並創建用於部署的二進制文件。這個階段叫做“提交階段”。
第二個階段應該利用第一個階段所生成的二進制文件進行驗收測試、集成測試。假如你有性能測試的話，也要一併運行。
4. 管理開發工作區
開發環境的管理目標：
當開發人員剛開始新任務時，應該總是從一個已知正確的狀態開始。
開發人員應該能夠運行構建、執行自動化測試，可以在開發機上部署其開發的應用程序。只有在特殊的情況下，才應使用共享環境開發。
在本地開發環境上運行應用程序時，應確保所使用的自動化過程與持續集成環境、測試環境、生產環境中一致。
達到這一目標，需要做以下事項：
第一個先決條件就是細心的配置管理，將源代碼、測試數據、數據庫腳本、構建腳本和部署腳本放在版本控制庫中。當編碼開始時，應該以它們“最新的正確版本”作爲起點。“最新的正確版本”是指那個在持續集成服務器上最近一次通過所有自動化測試的那個版本。
其次是確保第三方依賴的配置管理（開發中所用的庫文件和組件）的版本與正在開發的源代碼的版本是相互匹配的。對於大部分項目來說，其所依賴的第三方庫文件的版本不會經常發生改變，所以最簡單的方法就是將這些庫文件隨你的代碼一起提交到版本控制庫中。
最後就是確保自動化測試(包括冒煙測試)都能夠在開發機上運行。讓開發人員於每次提交前在自己的開發機上將應用程序運行起來，並在其上跑一遍冒煙測試，可以大大改善應用程序的質量。
04
持續集成時間理論
持續集成工作流一般是研發先進行提交前操作，然後提交變更代碼到版本管理庫。促發持續集成服務器拉取代碼後進行構建和測試，將構建和測試結果反饋回開發，最後促發自動部署（持續發佈的內容）。本章以工作流爲順序介紹持續集成中的最佳實踐。
1. 提交前工作
首先查看當前構建服務器上是否有構建在運行。如果有的話，你要等它運行完。如果它失敗了，你要與團隊中的其他人一起將其修復。
一旦當前構建完成且測試全部通過，開發人員需要從源碼管理系統裏簽出或者克隆最新的代碼到本地開發機器。隨後，開發人員繼續基於主幹分支創建出一個新的功能分支。該分支將專門用於引入僅在新功能範疇內的更改。
建議開發人員經常保持他們的代碼和主幹代碼分支的內容同步。該步驟將會把主幹分支的變更帶到功能分支，所以除了自己的功能代碼之外，開發人員總是使用主幹分支代碼的最新副本。一般來說，每個開發者至少每天將主幹分支同步一次到他們的功能分支。
開發人員開發新功能不僅僅有功能的變動，還應該包括新代碼的單元測試。
開發人員必須在在自己的開發機上執行構建腳本，運行測試，以確保在你機器上的所有代碼都工作正常。如果這些測試或者代碼本身編譯失敗的話，必須修復這些集成問題。
2. 提交變更
當開發人員準備提交時，應該從版本控制庫中籤出代碼，更新一下本地的項目副本，然後做一下本地構建，並運行提交測試。只有當全部成功以後，開發人員才能將代碼提交到版本控制庫中。
提交過程是一件輕量級的事兒，保證可以每隔二十分鐘左右提交一次。但同時爲保證新增的代碼的確是按期望的方式運行的，提交前需確保在本地運行一次提交測試，做一下健全性檢查(sanity check)。
提交前運行本地測試有以下兩個好處：
如果在你根據版本控制進行更新之前，其他人已經向版本控制庫中提交了新代 碼，那麼你的變更與那些新代碼合併後，可能會導致測試失敗。如果你自己先在本地更新代碼並運行提交測試的話，假如有問題，就會在本地提前發現，提前修復，從而不會令持續集成服務器上的構建失敗，不至於影響其他人及時提交。
在提交時經常犯的錯誤是，忘記提交那些剛剛新增加的東西到存儲庫中。如果遵守這個流程的話，當本地構建成功，而持續集成系統中的提交階段失敗了的話，那 麼你就知道要麼是由於別人與你同時提交了代碼，要麼就是你遺漏了一部分類或配置文件沒有提交到版本控制系統中。
遵循這樣的實踐可以確保狀態一直是正常的。
代碼提交入庫前可以通過添加代碼檢查來提高代碼質量。將靜態分析工具和人工審覈配合實施，自動化的審查工具擴展了以人爲之的複查，由於代碼變的越來越長，越來越複雜，所以自動化的審查就變得很有必要。自動化代碼審查的優點在於，當進行人工複查時，這個過程會變得更有效，因爲代碼的底層細節已經通過了掃描檢查。人工複查可以關注哪些自動化工具不能處理的方面，注入代碼時候滿足需求，是否從長遠來看易於維護等。
3. 代碼拉取
持續服務器會負責從源碼管理拉取最新的代碼。這可以藉助poll或者push機制實現。
使用poll機制的話，持續集成服務器會配置一個源碼管理服務器的位置，以及它的安全證書。它會根據一個時間間隔定期地輪詢指定位置，以檢測是否有發生任何新的簽入以及代碼變更。一旦檢測到有變更，它會從源碼管理服務器下載代碼最新的副本到本地磁盤。
使用push機制的話，源碼管理系統會配置一個“鉤子”指到持續集成服務器。當開發人員提交了一個變更到倉庫時，之前配置的鉤子將會被調起，而它會讓持續集成服務器知道，這裏發生了一次變更。
4. 構建
源代碼一般是自包含構建的，即持續集成流程所需的構建腳本是放在源碼倉庫裏的。正如在之前的步驟裏詳細介紹的那樣，一旦最新的代碼被拉取下來，一個捆綁好的腳本將會被用來觸發該次構建。
構建的類型分成三個層次：爲個人的、爲團隊的、爲用戶（客戶）的。開發者（或結對的開發者）執行私有構建，集成構建將整個團隊的工作成果集成起來，發佈構建爲用戶準備好軟件。
私有構建
如果在你根據版本控制進行更新之前，其他人已經向版本控制庫中提交了新代 碼，那麼你的變更與那些新代碼合併後，可能會導致測試失敗。如果你自己先在本地更新代碼並運行提交測試的話，假如有問題，就會在本地提前發現，提前修復，從而不會令持續集成服務器上的構建失敗，不至於影響其他人及時提交。
集成構建
在提交時經常犯的錯誤是，忘記提交那些剛剛新增加的東西到存儲庫中。如果遵守這個流程的話，當本地構建成功，而持續集成系統中的提交階段失敗了的話，那 麼你就知道要麼是由於別人與你同時提交了代碼，要麼就是你遺漏了一部分類或配置文件沒有提交到版本控制系統中。
發佈構建
發佈構建準備好發佈給用戶的軟件。持續集成的一個目標就是創建可以部署的軟件。發佈構建可能在一次迭代結束時進行，或在某個里程碑處進行，它可能包括更全面的性能測試和負載測試，並且必須包括所有的驗收測試。
並非所有的構建都是以同樣的方式觸發的。要根據構建的目標和頻率來選擇最合適的方式來觸發某種構建。觸發構建機制有以下4類思路：
用戶驅動： 由某人手工發起集成構建
定期執行： 定期執行的過程由時間驅動，不論是否發生了變更。定期執行的活動適合下班後執行的過程比較合適。
輪詢變更： 一個進程以固定的時間間隔喚醒，從版本控制庫中籤出變更。如果檢測到變更，它就執行集成構建。所有持續集成服務器都支持某種類型的“輪詢變更”機制。
事件驅動： 事件驅動與輪詢變更類似，但不同的是，構建不是由持續集成工具來觸發的，而是由版本控制庫觸發的，給予事先定義好的變更事件，如果版本控制庫檢測到變更，它將執行構建腳本。
5. 構建
在CI流程的這個階段裏，單元測試和集成測試將會被執行。一般來說，這些測試也會被打包到代碼裏。
針對基於Java ™實現的系統而言，這些測試會通過一個像JUnit這樣的測試框架來執行，從而可以輕鬆模擬它們的一些測試依賴。某些編程技術可能有它們自己的測試運行框架，Spring的Spring Junit Runner，Java EE的Arquillian等。
在CI服務器上運行測試主要有下面這些好處：
你曾經有沒有遇到過這樣的場景，這些測試在一臺機器上是通過的，但是在其他機器上卻失敗了？通過在一臺中央服務器上執行這些測試，我們可以消除一些測試環境方面的問題
針對每一次變更都會立即觸發執行測試，而且如果有任何新的代碼變更打破了預期的行爲的話，你能夠馬上知道
大多數團隊都是並行地在開發着許多功能，甚至可能一些團隊成員也是分佈在全球各地。每當開發人員提交代碼到倉庫時，任何故障都可以被識別出來並且立即修復。
6. 反饋和通知
在CI流程的最後，只可能存在兩種結果的其中一種，要麼構建和測試失敗了，要麼通過了。
每一次簽入都會被驗證並且確保它不會破壞現有的代碼。代碼在它被合併到主幹分支後不久會被構建和測試。這將可以降低主幹代碼崩潰的頻次。
一般來說，CI服務器會配置成在遇到故障時發送郵件（發給團隊裏的每一個人或者僅僅單獨抄送負責上一次簽入的相關人員）。通過這種方式，可以快速知曉故障並且儘快採取更正措施。
大多數CI服務器還會突出展示最近一些構建的狀態而且最近幾次構建的狀態還會用紅-綠-琥珀色指示燈來標明。舉個例子，Jenkins，使用的是如下指示燈來顯示構建的情況。
05
Java項目的持續集成實踐
1. 環境準備
easyops平臺搭建
系統版本：centos 6.5～6.9
推薦配置：
2. 項目目錄規範
以maven標準目錄結構爲依據
源代碼管理
源代碼統一放在src/main/java下。
遵循Java實踐，將文件放在以包名爲目錄名的目錄中，每個文件保存一個類。
生成的任何配置或圓數據都不應該放在src目錄下，而應該放在target中。
測試管理
將所有要測試的源代碼都放在src/test/java目錄中，單元測試應該放在與包名相對應的目錄中。
構建輸出管理
在用maven做構建的時候，會把生成的代碼、元數據文件都放在項目根目錄中一個叫target的文件夾中。這樣清除前一次構建結果只需要刪除整個目錄就可以了。
可以把測試報告存儲在/target/reports目錄下。
庫文件管理
庫文件的管理有幾種不同的方法。
· 完全交給工具來管理。
· 把庫文件（包括構建、測試和運行時必須的所有庫文件）都提交到版本控制庫，最常· · 見的是放在lib文件夾下。
· 建立組織級的第三方依賴庫，將所有項目需要的所有依賴庫文件都放在其中。
注意事項：
上述目錄，包管理系統前臺默認根據模板自動創建，無需人工創建。
若軟件包有特殊類型文件則請建立文件夾存放，不得與已有文件類型混放。
任何文件不得直接存放在軟件包頂層文件夾。
3. 版本控制服務器搭建
git搭建
4. 持續集成服務器搭建
使用easyops平臺一鍵部署java環境、maven環境和Jenkins到持續集成服務器。
Jenkins v2.73.3 ，用於 Linux 平臺，和 linux_jdk_1.8 搭配使用，默認啓動端口 8500 ，默認密碼admin:admin。
使用easyops平臺一鍵部署sonarqube（服務端）到持續集成服務器
使用easyops平臺一鍵部署sonarqube scanner（客戶端）到持續集成服務器和各開發機。
5. 流水線配置
配置持續集成流水線。
