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做爲主要的容器化運行時。