傳統IT技術團隊中通常都有多個獨立的組織-開發團隊、測試團隊和運維團隊。開發團隊進行軟件開發、測試團隊進行軟件測試，運維團隊致力於部署，負載平衡和發布管理。 他們之間的職能有時重疊、有時依賴、有時候會沖突。
因為銜接與溝通問題，有時會導致開發-測試-發布的周期太長了，特別是對於互聯網公司，時間就是生命。從而需要建立一支由開發，質量保證和運營組成的混合專業知識的團隊的需求，並引入了DevOps來彌合團隊之間的鴻溝，幫助他們快速而可靠地操作和開發應用程序。
一、什么是DevOps？
顧名思義，Devops是“開發”與“運維”的縮寫。它定義了一組流程，這些流程通過在開發和運維團隊之間進行協作帶來組織文化上的轉變。它包含四個關鍵組件：協作，實踐，文化和工具。
二、為什么我們需要DevOps？
DevOps帶來更高水平的協作和速度，使組織提高生產力，降低運營成本以有效地為客戶提供服務並保持市場競爭力。它還有助於更快地發布產品，管理計划外的工作，更快地捕獲和解決關鍵問題。
三、DevOps實踐
獨立devops團隊
DevOps使用各種工具，例如docker、k8s、Jenkins，Terraform，Nagios，Grafana，Prometheus或Splunk等，組織應建立一個集中部門來創建和操作這些工具。這個集中管理部門負責開發團隊中的敏捷實踐設置，該團隊將研究新的工具並堅持使用，並提供指導程序和培訓以實施DevOps。該部門核心工作內容是追求測試、集成、部署的自動化，減少人員參與、降低溝通成本、彌合技術團隊之間的鴻溝。
持續集成（CI）
CI是一種軟件開發實踐，可改善團隊之間的協作並有助於構建高質量的軟件。開發團隊會定期檢入存儲庫中的代碼更改，CI會執行自動構建和測試以驗證代碼質量。持續集成所采用的實踐可以在早期階段快速檢測出軟件開發生命周期（SDLC）的挑戰，從而有助於開發團隊在開發階段本身解決問題。
持續交付/部署（CD）
部署過程具有不同的階段，例如開發→構建→驗證→構建版本控制→部署→后部署等。持續部署過程的思想是，在構建通過QA階段的所有階段后，將已開發的代碼自動部署到生產環境中。 -beta，Integration，UAT等。有一些可用的工具，例如Spinnaker，Jenkins，Harness，Ansible，Chef，Puppet等，使DevOps團隊可以建立自動化管道，以最少的人工干預就可以在多個環境中進行部署。
持續交付是DevOps的一種實踐，其中新的代碼庫由QA團隊在自動和手動QA周期的不同階段進行測試。如果代碼庫通過了QA周期並得到QA團隊的批准，則它將部署到生產環境中。通過這種方式，DevOps將團隊划分為較短的周期，從而使團隊能夠更快，更頻繁地構建，測試和發布代碼庫。這使組織能夠提供更多版本，減少手動部署，並將生產中的故障風險降至最低。
配置管理（CM）
配置和變更管理是DevOps周期的重要組成部分。配置管理是對基礎結構和系統的所有實體（例如服務器，應用程序，存儲，網絡和所有托管服務）進行配置，監視，管理和維護的自動化。也有許多的集中配置管理工具可以使用，比如：nacos、apollo等。
配置管理帶來了許多優勢，例如簡化了新環境的設置，降低了生產配置的風險，並節省了軟件開發的大量時間，而無需花費時間和精力來使用基礎結構即代碼實踐從頭開始新服務。
變更管理
變更管理是一個請求，計划，實施和評估滿足新要求所需的變更的過程。在配置管理過程中，如果現有系統和基礎架構中需要進行任何更改，那么此時就要考慮更改管理。運營團隊需要提供他們的意見，更改的原因，以及可能在更大范圍內產生的后果，包括可能受到新更改影響的其他系統。
測試自動化
每個代碼庫的自動測試有助於運行更多測試，提高測試頻率，並節省手動QA上花費的時間。此過程可及早發現錯誤，修復錯誤，並提高整體軟件質量。有幾種工具可以與DevOps工具集成，例如Selenium，RobotFramework，Appium，XCUITest，JUnit等，以實現自動化的測試。
持續監控（CM）
持續監控建議使用幾種工具，儀表板和警報來監視所有系統和基礎架構，包括對影響軟件的不同指標的實時洞察，例如系統性能，測試次數，成功和失敗率，部署狀態，錯誤日志以及所有信息以圖形，表格和詳細報告格式顯示。為了完成這樣的監視，DevOps團隊可以設置一些工具，例如Prometheus，Grafana，Nagios，Appdynamics，NewRelic，Splunk，Logstash，以及市場上可用的更多工具。
歡迎關注我的博客，里面有很多精品合集
- 本文轉載注明出處（必須帶連接，不能只轉文字）：字母哥博客。
覺得對您有幫助的話，幫我點贊、分享！您的支持是我不竭的創作動力！ 。另外，筆者最近一段時間輸出了如下的精品內容，期待您的關注。