DevOps和它的朋友們——聊聊其他 “Ops”（一）

DevOps不僅僅是將敏捷開發概念與IT運維相結合，還簡化了在雲環境中開發和部署應用程式的過程，從而使開發生命週期大大縮短。這就是DevOps作為一種開發方法流行的原因。

即使在今天，DevOps仍然是大多數優化管道的核心。持續交付變成了規範，而不是要實現的目標。應用的開發是迭代的，新的更新被推送到雲端，用zero down代替部分或整個環境。因為有了DevOps，即使是大型的多部分更新也更加易於管理。

然而，就結合軟體開發和IT運維而言，DevOps這個術語並非唯一。它有著許多變體和子型別——以及概念的修改——它們被不同的軟體開發團隊廣泛採用。對於許多人來說，DevOps為跨團隊的良好流程（包括自動化）奠定了基礎。但是為了改進方法論，團隊可以採用下面的一種或多種主要方法——因為大多數被考慮的方法都是為了實現“更好的”DevOps文化而進行的調整。

那麼，其他需要考慮的“Ops”是什麼呢？它們與DevOps相比如何？

DevOps vs. NoOps

NoOps背後的方法是以一種不需要內部團隊進行操作的方式來自動化IT基礎設施。在這種方法中，操作團隊的所有維護和類似任務都是完全自動化的，這意味著不需要手動干預過程。

NoOps的意圖與DevOps相似，因為它專注於完全自動化工具和基礎設施，以改進軟體部署。然而，它較少關注敏捷和流程管理，因為它的工作假設是開發人員擁有自動化的工具和流程，他們不需要知道如何使用它們的具體細節。

為了實現這一目標，該方法的一部分“減輕”了開發人員的所有基礎設施顧慮，從而從雲端計算中獲得更多價值。與DevOps一樣，這是為了防止他們執行耗時的任務，這些任務涉及與IT運營團隊就基礎架構問題進行的所有互動。

在NoOps中，開發人員不需要為資源及其分佈操心，因為這正是雲的作用所在。在產品完成後，雲提供商還將執行進一步的運維、監視和維護。NoOps模型使用持續整合技術，允許開發人員只專注於應用程式開發。

當組織開始選擇NoOps時，許多人認為這將是DevOps的終結。但在現實中，DevOps已經發展了，NoOps並不是一個萬無一失的過程，儘管它加快了部署過程。我要警告不要孤立地採用NoOps，因為它缺乏流程和團隊管理，而開放的溝通通常會帶來更好的結果和生產力。

DevOps vs. DevSecOps

從這兩種方法的名稱來看，很容易相信這兩種方法有一個主要區別：將安全性整合到管道中。然而，我認為它們是同一個概念。如果DevOps是“在製品”（WIP）的減少，那麼自然的進展是在管道中進一步提高安全性。如果您需要提升或提升組織對多個因素的安全關注，那麼這種方法非常有用。

DevSecOps採用了傳統的DevOps方法，並在工作流程中新增了額外的安全檢查、程式碼驗證和深入測試。DevSecOps從流程的一開始就整合了安全性，而不是在週期結束時讓安全性成為一個問題。

兩者有相似之處，也有相似的主要優勢。DevOps和DevSecOps都允許CI/CD管道實現更大的自動化。只要速度和交付處於優先順序列表的頂端，DevOps和DevSecOps就會繼續在工作流的不同部分利用自動化。

兩者還依賴於在溝通和協作的幫助下持續執行的過程。團隊溝通是保持敏捷性和交付速度的關鍵部分。開發人員、安全專家和運維人員之間的協作也至關重要。

DevOps vs. GitOps

GitOps是DevOps的另一個廣受歡迎的分支，在過去的一年裡得到了廣泛的關注。顧名思義，GitOps更關注於使用Git作為一種方法來自動化其餘的持續交付管道。有了Git作為唯一的資料來源，從長遠來看，GitOps被認為更健壯、更可管理。

可以說，實施GitOps有一些潛在的優勢。對於初學者來說，每個開發人員都熟悉Git和pull請求，因此整合GitOps作為一種加快交付速度的方法是一種簡單的過程，不需要掌握複雜的工具，也不需要總是對工作流進行更改。

GitOps還得到了市場上一些最好的雲服務的支援。像AWS CodePipeline和AWS CodeBuild這樣的工具是為使用Git工具而設計的，這意味著自動構建更新、測試錯誤、審查程式碼以及將更新推送到生產環境的過程非常容易實現。

GitOps還提供了一套詳細的審計工具，並能夠隨時回滾更新。這是因為Git是每次更新的主要來源，這意味著整個管道也可以依賴Git日誌來進行簡單地審計。然而，由於Git是唯一的事實來源，有必要對Git儲存庫進行足夠的保護，以避免不必要的提交或請求。

簡而言之，GitOps是DevOps的一個子集，旨在利用Git的強大優勢。因此，大多數GitOps工作流嚴重依賴Kubernetes作為主要的容器化執行時。