作為一組概念，DevOps 融合了幾個突出的主題，包括持續軟件交付、自動化和配置管理 (CM)。這些不可或缺的部分通常構成組織 DevOps 工作的支柱，即使其他更大的部分（如總體最佳實踐和指南）仍在嘗試和測試中。由于 DevOps 是一種相對較新的范式 - 運動 - 方法論 - [在此處插入您自己的標簽]，圍繞它的標準尚未被編纂并一成不變。組織需要確定最適合其用例的工具和方法，并且會根據其成功程度對它們發誓或貶低它們。
就 CM 而言，一種特定的方法可能適用于一家公司，但不適用于另一家公司，這是一個假設。然而，很少有不同的方法會像 CM 的聲明式和命令式模型那樣產生如此多的異議。關于誰更勝一籌的反復辯論已經贏得了雙方的堅定支持者，值得仔細研究。
定義聲明式和命令式模型
聲明式和命令式模型之間的差異可以用一句話來概括：命令式側重于如何，而聲明式側重于什么。在軟件工程上下文中，聲明式編程意味著編寫代碼來描述程序應該做什么，而不是它應該如何做。一個描述需要發生的事情；讓它如此的細節留給系統。相比之下，命令式編程涉及編寫遵循明確步驟來解決問題、完成任務或達到預期結果的代碼。它具體告訴系統如何做某事，以期達到預期的結果。
命令式/聲明式構造也延續到 IT 領域，例如 CM。事實上，一個特定的 CM 工具的方法很大程度上受其構建的基礎語言的影響（反過來，它本質上是命令式的或聲明式的）。
例如，Puppet 是聲明性的：系統管理員描述了所需的最終狀態，并且工具會嘗試達到它。它的領域特定語言 (DSL) 用于創建所需服務器狀態的高級描述，而不是要執行的指令和操作。清單——包含配置信息的 Puppet 文件——可以多次使用以達到相同的結果。如果已達到所需的最終狀態，Puppet 會簡單地忽略相關項目。用戶只需擔心要配置的系統所需的最終狀態，而不是到達那里所需的步驟順序。
該條目描述了一個結束狀態，其中包含一個名為 /tmp/test123 的文件，其內容為“這是一個測試”。如果在目標系統上找到匹配的文件（和內容），Puppet 假定已經達到所需的結束狀態。隨后，無需擔心 Manifest 會多次執行此部分。
相比之下，Chef（Puppet 的宿敵）勢在必行。用戶在稱為食譜的配置指令中定義命令及其執行順序，這些指令又可以組織成食譜，以便于管理。
此配方檢查目標節點上的 JDK 7——如果存在，Chef 將安裝 OpenJDK 7。如果不存在，則會發出警告。請注意，Chef Recipes 的結構是順序的命令列表，而不是 Puppet Manifests，后者僅包含對所需最終狀態的描述。
CM 供應商的一個增長趨勢是讓他們的產品對任一模型開放，從而贏得兩個陣營的心。即使是像 Chef 這樣本質上必不可少的工具也可以以聲明方式設置。
與前面的示例相比，上述配方描述了所需的結束狀態，而不是列出要執行的一系列命令。
那么哪個型號更適合CM呢？要解決這個問題，需要有資格獲得誰和什么。此外，考慮到 DevOps 的當前流行程度和采用率，專家們的復雜程度不斷提高也就不足為奇了：圍繞 DevOps 的對話已經從它是什么發展到如何去做。怎么做取決于你問的是誰。
因此，讓我們從三個角度分析這場爭論：程序員、系統管理員和全棧開發人員。
熱衷于編寫高效、結構化和易于理解的代碼的程序員并不是采用笨拙抽象的聲明性模型的最大粉絲。他習慣于用 for 循環、條件語句、變量等來規定事情應該如何發生。他所從事的軟件的業務邏輯本質上是必不可少的。
最適合：像 Chef 這樣的命令式 CM 工具
系統管理員 喜歡經營一家緊湊的商店，這是有充分理由的：如果基礎設施出現故障，公司就會急剎車。他是一個 Bash 向導，精通 Python 和 Perl，并且更喜歡使用它們而不是學習像 Ruby 這樣的新語言。他更喜歡聲明式而不是命令式模型，但他意識到前者在管理動態云基礎架構方面所面臨的挑戰。
最適合： 混合 CM 工具，如 Ansible 或 SaltStack
全棧開發人員 可以輕松地遍歷堆棧，并且喜歡將基礎架構抽象為代碼的想法。Ruby/RoR 忍者，她是 Chef 和 Puppet 的粉絲。她可以欣賞每個模型的優點；對她來說，任何一種工具都可以讓她更快、更高效、更不容易出錯地持續構建和發布高質量的軟件。
最適合：任一型號。Puppet、Chef 和 SaltStack 是可行的選擇。
請注意，我們的程序員很可能是 Python 專業人士，因此非常精通 Ansible（其模塊是用 Python 編寫的）。無論如何，將組織的 IT 技能構成與適當的模型/工具相匹配是確定哪個更合適的實用方法。如果一家公司從事由程序員掌舵的傳統軟件開發，那么命令式工具可能是最合適的。一個按計劃持續推出的快速發展的 SaaS 將欣賞一個實施良好的聲明式 CM 解決方案的靈活性和可擴展性。一個對 Ruby 發誓并擁有專業知識的商店可能會選擇使用某些工具“烹飪”，從而完全推翻模型辯論。
要記住的關鍵點是聲明式和命令式模型都是易錯的：前者需要相信已達到所需狀態（幾乎沒有驗證手段），而后者則需要在出現問題時進行復雜的故障排除。在某些邊緣場景中，這兩種模型都可能存在問題；隨后，無論采用哪種方法，都不應將單個工具實施為 CM 的全部和最終目標。所選擇的解決方案應該只包含 CM 工具鏈的一部分，而另一個將其作為監督工具，確保所有 CM 和自動化工具都按預期執行。
服務于這個目的：通過強大的掃描、監控和比較功能提供全面的系統可見性，我們的平臺彌合了期望您的系統/環境以某種方式與實際驗證它是否滿足這些期望之間的關鍵差距。
簡而言之，爭奪思想和市場份額的競爭供應商將熱情地擁護他們的產品各自的方法。盡管圍繞聲明式/命令式模型的辯論在商業 CM 領域呈現出新的強度和熱情，但事實是，許多工具兼具兩者的品質——盡管它們可能更多地基于一種模式。因此，將聲明式和命令式模型視為一系列可能性，各自的解決方案更接近任一端，這可能更有用。
