5．總結(jié)一些DevOps最佳實踐

持續(xù)集成的原則

? 鼓勵開發(fā)人員在開發(fā)分支上頻繁的提交代碼，隨后觸發(fā)CI流程，在CI過程中可以加入單元測試和代碼質(zhì)量檢查等動作，這樣產(chǎn)生代碼沖突的幾率會下降，并且代碼質(zhì)量也會提高的；

? 在下班之前，構(gòu)建必須處于成功狀態(tài)，原因是你的代碼在第二天有可能是其它同事開發(fā)工作的基礎，如何無法保證構(gòu)建成功，會影響其它的人工作質(zhì)量和效率，團隊氛圍也會產(chǎn)生壞的影響；

? 讓開發(fā)環(huán)境上快速體現(xiàn)最新程序包

? 讓程序、配置、數(shù)據(jù)分離，其實現(xiàn)在好多的單體應用開發(fā)時，是將程序、配置、數(shù)據(jù)裹在一起的，改一處，要解決一堆的依賴，改一處，牽扯到很多地方都要做更新，這些降低了版本迭代的效率，并且很可能會出現(xiàn)遺漏

? maven模式下，pom依賴盡量不要用system本地依賴模式，而是將二方庫和三方庫依賴到統(tǒng)一的類似Nexus介質(zhì)庫，整個組織一份，來屏蔽本地jar依賴差異導致的編譯錯誤。

持續(xù)集成的最佳實踐

? 構(gòu)建過程，建議等待構(gòu)建的結(jié)果，不要同時做其它的事情，尤其是構(gòu)建失敗之后不要提交新代碼，這樣很可能會錯上加錯，最后不知道到底是誰的錯，這些錯誤的回溯會產(chǎn)生很大的成本。

? 提交之前在本地運行所有的提交測試

? 提交之前請更新本地代碼，保證代碼是最新的，沖突解決了，再提交

? 記得更新數(shù)據(jù)庫、配置文件等

? 等構(gòu)建成功后再繼續(xù)其他工作

? 下班之前，構(gòu)建必須處于成功狀態(tài)

? 以十分鐘為界限，如果代碼提交后構(gòu)建錯誤，十分鐘之內(nèi)無法解決問題，需要將新代碼撤回，否則可能會影響其它同事的工作。

自動化部署的原則

? 原則1：確保從開發(fā)、各類測試到生產(chǎn)，使用相同版本的中間件和操作系統(tǒng)，保證從操作系統(tǒng)、到補丁包、到應用運行環(huán)境基線是一致的

? 原則2：同一套腳本，解決各類環(huán)境的部署問題，不要試圖通過腳本來解決環(huán)境的差異性，因為環(huán)境的差異性本應該是不存在的，否則改了腳本，之前的各個環(huán)境還需要做腳本的回歸測試

? 原則3：部署之前，事先設計回滾與零停機發(fā)布的策略

? 原則4：全量發(fā)布優(yōu)先，盡量不要用增量發(fā)布，因為引入增量發(fā)布，就會引入手工操作，人工去選擇哪些做增量

? 原則5：詳細記錄部署活動的整個過程

自動化部署的最佳實踐

要做到自動化部署，要確保自動化部署的成功，最最重要的關(guān)鍵為：保障一致性！將要部署的各個環(huán)境一致；在各個環(huán)境執(zhí)行的部署腳本一致；要部署的安裝包也要一致！

? 從提測之后，所有環(huán)境運行的是同一個介質(zhì)包，不要在SIT、UAT、準生產(chǎn)和生產(chǎn)等環(huán)節(jié)重復的打包

? 保證各個環(huán)境的操作系統(tǒng)、補丁和軟件運行環(huán)境的基線一致；

? 保證使用同一的二方和三方庫依賴，推薦Nexus

? 關(guān)于配置文件，建議：配置文件與代碼的版本保持一致

○ 配置項清晰、規(guī)范、統(tǒng)一命名

○ 配置項模塊化、且封閉

○ 每個配置項都是唯一的，避免顧此失彼

○ 避免過分設計，盡量簡單

○ 建議逐步過渡到Apollo這樣的統(tǒng)一配置中心，以key/value的形式管理各環(huán)境的配置項