DevOps如何正確的在企業內進行實踐

傳統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，以及市場上可用的更多工具。