DevOps的領(lǐng)導(dǎo)力實(shí)踐
- 領(lǐng)導(dǎo)者表現(xiàn)出對組織方向和團(tuán)隊(duì)方向的長期愿景惹挟。
- 領(lǐng)導(dǎo)者通過鼓勵他們提出新問題并質(zhì)疑有關(guān)工作的基本假設(shè)搪花，從智力上激勵團(tuán)隊(duì)搓谆。
- 領(lǐng)導(dǎo)者提供鼓舞人心的溝通刁愿，激發(fā)加入團(tuán)隊(duì)的自豪感绰寞，對團(tuán)隊(duì)說積極的話，激發(fā)激情和動力铣口，并鼓勵人們看到變革帶來機(jī)遇滤钱。
- 領(lǐng)導(dǎo)者通過在行動前考慮他人的個(gè)人感受，考慮他人的個(gè)人需求并關(guān)心個(gè)人的利益來表示支持脑题。
- 領(lǐng)導(dǎo)者通過表彰團(tuán)隊(duì)做得比平均水平更好的工作件缸，表揚(yáng)工作質(zhì)量的提高，并稱贊個(gè)人的出色工作叔遂，從而提高個(gè)人知名度他炊。
DevOps的協(xié)作文化實(shí)踐
- 這種文化鼓勵跨職能的協(xié)作和共同的責(zé)任，并避免開發(fā)掏熬，運(yùn)營和質(zhì)量保證之間的孤島佑稠。
- 這種文化鼓勵從部門之間的失敗和合作中學(xué)習(xí)。
- 在適當(dāng)?shù)那闆r下旗芬，使用協(xié)作工具（例如Slack舌胶，HipChat，Yammer）在端到端跨職能團(tuán)隊(duì)之間進(jìn)行順暢的溝通疮丛。
- DevOps系統(tǒng)由一個(gè)專家團(tuán)隊(duì)創(chuàng)建幔嫂，并由包括Dev辆它，Ops和QA在內(nèi)的利益相關(guān)者聯(lián)盟進(jìn)行審核。
- 端到端DevOps工作流程的更改由一個(gè)專家團(tuán)隊(duì)領(lǐng)導(dǎo)履恩，并由包括Dev锰茉，Ops和QA在內(nèi)的利益相關(guān)者聯(lián)盟進(jìn)行審核。
- DevOps系統(tǒng)更改遵循分階段進(jìn)行的過程切心，以確保更改不會干擾當(dāng)前的DevOps操作飒筑。實(shí)施階段的示例包括：測試環(huán)境中的概念驗(yàn)證（POC）階段，有限的生產(chǎn)和部署到所有實(shí)時(shí)環(huán)境中绽昏。
- 整個(gè)團(tuán)隊(duì)設(shè)置并監(jiān)視關(guān)鍵性能指標(biāo)（KPI）协屡，以始終驗(yàn)證端到端DevOps管道的性能。KPI包括部署新變更的時(shí)間全谤，交付頻率以及變更未能通過DevOps管道中任何階段的測試的次數(shù)肤晓。
DevOps的針對DevOps的設(shè)計(jì)實(shí)踐
- 產(chǎn)品的架構(gòu)可支持模塊化的獨(dú)立包裝，測試和發(fā)布认然。換句話說补憾，產(chǎn)品本身被劃分為模塊，模塊之間的依賴性最小卷员。這樣盈匾，可以構(gòu)建，測試和發(fā)布模塊子刮，而無需一次全部構(gòu)建威酒，測試和發(fā)布整個(gè)產(chǎn)品。
- 應(yīng)用程序被設(shè)計(jì)為模塊化挺峡，不可更改的微服務(wù)葵孤，可以根據(jù)12要素應(yīng)用程序的宗旨，而不是整體橱赠，可變的架構(gòu)尤仍，隨時(shí)準(zhǔn)備在云基礎(chǔ)架構(gòu)中進(jìn)行部署。
- 在提交到集成分支之前狭姨，使用靜態(tài)分析工具預(yù)先檢查軟件源代碼的更改宰啦。靜態(tài)分析工具用于確保修改后的源代碼不會引起嚴(yán)重的軟件故障，例如內(nèi)存泄漏饼拍，未初始化的變量和數(shù)組邊界問題赡模。
- 在提交到Integration / trunk分支之前，使用對等代碼審閱對軟件代碼更改進(jìn)行預(yù)檢查师抄。
- 在提交給Integration / trunk分支之前漓柑，將使用動態(tài)分析測試對軟件代碼更改進(jìn)行預(yù)檢查，以確保軟件性能不會降低。
- 將軟件更改與最新的集成分支版本一起集成在專用環(huán)境中辆布，并在將軟件更改提交到集成/中繼分支之前使用功能測試進(jìn)行了測試瞬矩。
- 在簽入過程中使用軟件開關(guān)（即功能標(biāo)簽或切換按鈕）對軟件功能進(jìn)行標(biāo)記，以啟用選擇性功能級別的測試锋玲，升級和還原景用。
- 在檢入代碼更改的同時(shí)，將自動測試用例檢入到集成分支中惭蹂，同時(shí)還提供了證明在飛行前測試環(huán)境中通過了測試的證據(jù)伞插。
- 開發(fā)人員至少每天一次定期提交代碼更改。
DevOps的持續(xù)集成實(shí)踐
- 軟件版本管理（SVM）系統(tǒng)用于管理所有源代碼更改盾碗。（Git蜂怎，Perforce，Mercurial等）
- 軟件版本管理（SVM）系統(tǒng)用于管理構(gòu)建過程中使用的所有版本的代碼映像更改置尔。（Git，Perforce氢伟，Mercurial等）
- 軟件版本管理（SVM）系統(tǒng)用于管理在構(gòu)建過程中使用的工具榜轿，基礎(chǔ)結(jié)構(gòu)配置和測試的所有版本。（Git朵锣，Perforce谬盐，Mercurial等）
- 所有生產(chǎn)軟件更改都保存在代碼的單個(gè)主干或集成分支中。
- 用于支持每個(gè)客戶版本的軟件版本在單獨(dú)的版本分支中維護(hù)诚些，以支持針對每個(gè)版本更新的軟件飞傀。
- 每個(gè)軟件提交都會自動觸發(fā)代碼中該提交已更改的模塊所有組件的構(gòu)建過程。該系統(tǒng)經(jīng)過精心設(shè)計(jì)诬烹，因此資源始終足以執(zhí)行構(gòu)建砸烦。
- 一旦觸發(fā)，只要構(gòu)建時(shí)間檢查成功绞吁，軟件構(gòu)建過程將完全自動化并生成構(gòu)建工件幢痘。
- 自動構(gòu)建過程檢查包括單元測試。
- 構(gòu)建資源按需可用家破，并且從不阻止構(gòu)建颜说。
- CI構(gòu)建足夠快，可以在不到一個(gè)小時(shí)的時(shí)間內(nèi)完成增量構(gòu)建汰聋。
- 根據(jù)更改的復(fù)雜性门粪，構(gòu)建過程和構(gòu)建資源會自動按比例放大和縮小。如果需要完整構(gòu)建烹困，則CI系統(tǒng)會自動水平縮放以確保構(gòu)建盡快完成玄妈。
DevOps的連續(xù)測試實(shí)踐
- 在將開發(fā)變更集成到主干分支之前，需要在生產(chǎn)環(huán)境的克隆中進(jìn)行飛行前測試。（注：“生產(chǎn)環(huán)境”是指“產(chǎn)品的客戶配置變化”措近。）
- 測試軟件變更所需的新的單元和功能回歸測試與代碼一起創(chuàng)建溶弟，并同時(shí)集成到主干分支中代碼是。然后瞭郑，新測試將用于在集成后測試代碼辜御。
- 測試腳本標(biāo)準(zhǔn)用于指導(dǎo)測試腳本的創(chuàng)建，以確保腳本執(zhí)行預(yù)期的測試目的并且可維護(hù)屈张。
- 根據(jù)特定的軟件更改自動選擇測試擒权。動態(tài)地對CT進(jìn)行編排，從而可以根據(jù)軟件更改的復(fù)雜程度或風(fēng)險(xiǎn)來加速或完全跳過部分CT測試套件的執(zhí)行阁谆。
- 根據(jù)選擇的特定測試的資源要求和可用測試時(shí)間碳抄，自動縮放測試資源。
- 版本回歸測試是自動化的场绿。如果必須手動執(zhí)行部分測試剖效，則至少有85％的測試是完全自動化的，其余的則是自動輔助的焰盗。
- 發(fā)布性能測試是自動進(jìn)行的璧尸，以驗(yàn)證沒有發(fā)布不可接受的降級。
- 藍(lán)色/綠色測試方法用于在激活活動環(huán)境之前在臨時(shí)環(huán)境中驗(yàn)證部署熬拒。A / B測試方法與功能切換鍵一起使用爷光，可以在單獨(dú)的實(shí)時(shí)環(huán)境中與客戶一起嘗試不同版本的代碼。Canary測試方法用于在選定的實(shí)時(shí)環(huán)境中嘗試新的代碼版本澎粟。
- 整個(gè)測試生命周期（包括預(yù)檢蛀序，集成，回歸活烙，性能和發(fā)布驗(yàn)收測試）將在DevOps管道中自動進(jìn)行編排徐裸。每個(gè)階段的測試套件包括一組預(yù)定義的測試，可以根據(jù)預(yù)定義的標(biāo)準(zhǔn)自動選擇這些測試啸盏。
DevOps的彈性基礎(chǔ)架構(gòu)實(shí)踐
- 構(gòu)建和測試構(gòu)建所需的數(shù)據(jù)和可執(zhí)行文件會自動頻繁存檔倦逐，并可根據(jù)需要恢復(fù)。存檔包括所有發(fā)行和集成存儲庫宫补。如果需要更新版本的較舊版本檬姥，則可以根據(jù)需要檢索并恢復(fù)用于構(gòu)建和測試該版本的環(huán)境，并且可以在短時(shí)間內(nèi)（例如粉怕，幾分鐘到幾小時(shí)）完成該過程健民。
- 構(gòu)建和測試過程足夠靈活，可以優(yōu)雅地自動處理各種異常贫贝。如果某個(gè)組件的構(gòu)建或測試過程無法完成秉犹，則將報(bào)告該故障組件的過程并自動安排進(jìn)行分析蛉谜，但其他組件的構(gòu)建和測試過程將繼續(xù)。如果系統(tǒng)可以糾正故障原因崇堵，則會自動分析并重新計(jì)劃組件故障的原因型诚；如果不是，則將其報(bào)告并暫停鸳劳。
- 系統(tǒng)配置管理和系統(tǒng)清單存儲并維護(hù)在配置管理數(shù)據(jù)庫（CMDB）中狰贯。
- 使用可確保冪等的配置管理工具來管理和自動化基礎(chǔ)架構(gòu)更改。
- 自動化工具用于支持不變的基礎(chǔ)架構(gòu)部署赏廓。
- 人人享有平等的表現(xiàn)涵紊。不同團(tuán)隊(duì)在構(gòu)建和測試過程中的用戶性能體驗(yàn)對于所有用戶都是一致的，而不受位置或其他因素的影響幔摸。有SLA和監(jiān)視工具可確保所有用戶的用戶性能體驗(yàn)都是一致的摸柄。
- 提供了故障恢復(fù)機(jī)制。存在構(gòu)建和測試系統(tǒng)故障監(jiān)視既忆，故障檢測驱负，系統(tǒng)以及數(shù)據(jù)監(jiān)視和恢復(fù)機(jī)制。它們是自動化的患雇，并通過模擬故障條件進(jìn)行了持續(xù)驗(yàn)證电媳。
- 經(jīng)常測試基礎(chǔ)架構(gòu)故障模式。
- 災(zāi)難恢復(fù)過程是自動化的庆亡。
DevOps的連續(xù)監(jiān)視實(shí)踐
- 日志記錄和主動警報(bào)系統(tǒng)使檢測和糾正DevOps系統(tǒng)故障變得容易。對于大多數(shù)DevOps組件故障捞稿，都有日志和主動系統(tǒng)警報(bào)又谋，并且以快速識別最高優(yōu)先級問題的方式進(jìn)行組織。
- 來自每個(gè)DevOps管道階段的每個(gè)指標(biāo)的快照和趨勢結(jié)果（例如娱局，構(gòu)建彰亥，工件，測試）將在過程中自動計(jì)算衰齐，并且對于開發(fā)任斋，質(zhì)量保證和運(yùn)營團(tuán)隊(duì)的每個(gè)人都是可見的。
- DevOps基礎(chǔ)架構(gòu)組件的關(guān)鍵性能指標(biāo)（KPI）會自動收集耻涛，計(jì)算并顯示給訂閱它們的團(tuán)隊(duì)中的任何人废酷。示例指標(biāo)包括用于CI，CT和CD進(jìn)程的計(jì)算資源的可用性（正常運(yùn)行時(shí)間）抹缕，完成構(gòu)建的時(shí)間澈蟆，完成測試的時(shí)間，失敗的提交次數(shù)以及由于嚴(yán)重失敗而需要還原的更改次數(shù)卓研。
- DevOps基礎(chǔ)架構(gòu)組件的度量標(biāo)準(zhǔn)和閾值會自動收集趴俘，計(jì)算并顯示給訂閱它們的團(tuán)隊(duì)中的任何人睹簇。示例指標(biāo)包括用于CI，CT和CD進(jìn)程的計(jì)算資源的可用性（正常運(yùn)行時(shí)間）寥闪，完成構(gòu)建的時(shí)間太惠，完成測試的時(shí)間，失敗的提交次數(shù)以及由于嚴(yán)重失敗而需要還原的更改次數(shù)疲憋。
- 流程分析用于監(jiān)視和改進(jìn)集成凿渊，測試和發(fā)布流程。描述性的構(gòu)建和測試分析可推動流程改進(jìn)柜某。
- 預(yù)測分析用于動態(tài)調(diào)整DevOps管道配置嗽元。為了分析測試結(jié)果，數(shù)據(jù)可能表明需要將更多的測試集中在故障趨勢較高的區(qū)域喂击。
DevOps的持續(xù)安全性實(shí)踐
- 開發(fā)人員受權(quán)并受過培訓(xùn)剂癌，可以對安全性承擔(dān)個(gè)人責(zé)任。
- 組織采用安全保證自動化和安全監(jiān)視實(shí)踐翰绊。
- 所有正在使用的信息安全平臺都通過API公開了全部功能佩谷，以實(shí)現(xiàn)自動化功能。
- 成熟的版本控制實(shí)踐和工具可用于DevOps環(huán)境中使用的所有應(yīng)用程序軟件监嗜，腳本谐檀，模板和藍(lán)圖。
- 采用不變的基礎(chǔ)架構(gòu)思維方式裁奇，以確保生產(chǎn)系統(tǒng)處于鎖定狀態(tài)桐猬。
- 安全控制是自動化的，以免妨礙DevOps的敏捷性刽肠。
- 安全工具已集成到CI / CD管道中溃肪。
- 只有經(jīng)過驗(yàn)證的憑據(jù)的受信任用戶才能訪問構(gòu)建或測試計(jì)算機(jī)上關(guān)鍵知識產(chǎn)權(quán)的源代碼。構(gòu)建和測試腳本不包含用于訪問任何具有知識產(chǎn)權(quán)的系統(tǒng)的憑據(jù)音五。對知識產(chǎn)權(quán)進(jìn)行了劃分惫撰，使得并非所有知識產(chǎn)權(quán)都存在于同一檔案中，并且每個(gè)檔案都有不同的憑據(jù)躺涝。
DevOps的持續(xù)交付實(shí)踐
- 交付和部署階段是分開的厨钻。交付階段位于部署管道之前。
- 將所有通過交付指標(biāo)的可交付成果打包并準(zhǔn)備使用容器進(jìn)行部署坚嗜。
- 可交付使用的軟件包包括足夠的配置和測試數(shù)據(jù)夯膀，以驗(yàn)證每個(gè)部署。配置管理工具用于管理配置信息苍蔬。
- 一旦實(shí)現(xiàn)可接受的交付措施棍郎，則來自交付管道的可交付物會自動推送到部署管道。
- 根據(jù)預(yù)定指標(biāo)確定部署決策银室。整個(gè)部署過程可能需要幾個(gè)小時(shí)涂佃，但通常不到一天励翼。
- 分階段部署到生產(chǎn)環(huán)境，以便可以及早發(fā)現(xiàn)失敗的部署并迅速隔離對客戶的影響辜荠。
- 部署具有自動恢復(fù)和自我修復(fù)功能汽抚，以防部署失敗。
這是什么意思
DevOps是功能強(qiáng)大的工具伯病，可為使用它的組織帶來許多好處造烁。使用DevOps有效地實(shí)現(xiàn)性能取決于以下最佳實(shí)踐。通過遵循本博客中列舉的九個(gè)實(shí)踐支柱午笛，組織可以實(shí)現(xiàn)DevOps必須提供的性能潛力惭蟋。
