DevOpsの定義
DevOpsの定義は実践者によってまちまちだ。DevOpsを学術的に追求する開発者集団が運営するThe Agile Admin（TAA）というウェブサイトでは、DevOpsを「設計から開発プロセス、製品サポートに至るまでの（システムの）サービスライフサイクル全体を通じ、運用と開発のエンジニアが互いに協力しあうプラクティス」だと表現している。
同サイトは、ここから重要な帰結を導き出すとともに、これによって今までの手法に大きな変化が訪れると指摘している。
同ウェブサイトには「DevOpsの特徴として、開発者がシステムを開発するために使用しているテクノロジと同じものを多数、運用スタッフも使用するという点も挙げられる」と記されている。ここでの考え方は、職場でお互いが避け合うのではなく、運用と開発の担当者らが相互に協力し合って共に働くことを学ぶべきだというものだ。
ある意味において、これは斬新な考え方というわけではない。Opensource.comが「Busting 6 myths about DevOps」（DevOpsにまつわる6つの神話を論破する）という最近の記事で指摘しているように、DevOpsはアジャイル方法論の延長線上にあるものであり、「自己組織化された、クロスファンクショナルチーム（CFT）間での協力を通じて要件とソリューションを進化させていくという一連のソフトウェア開発手法」だと言える。2001年のアジャイルソフトウェア開発宣言でもそのことが明文化されている。
こういった発想はすべて、コードだけでは不十分だという信念から導き出されたものだ。テストを完遂し、本番環境で意図通りに動作して初めて、コードは完成したと言える。アジャイルソフトウェア開発宣言は、DevOpsを採用するうえで必須というわけではないが、「優れた出発地点」となっている。
DevOpsが何かを置き換える解決策でないのであれば、なぜ考慮する必要があるのだろうか？
その答えのヒントは、アジャイルソフトウェア開発宣言にも書かれている。DevOpsは何か、あるいはすべてのものに取って代わる解決策ではないかもしれないが、多くのIT分野で有益な補助になり得るのだ。その一例としてOpensource.comは、DevOpsがITSM（ITサービスマネジメント）やそのベストプラクティスをまとめた書籍群であるITIL（ITインフラのライブラリ）の反動だと捉える人もいるが、DevOpsとITILは互換性があるのだと主張している。
ITSMとITILは「IT運用を下支えするプロセスの最善の拠り所となり続け、IT運用がDevOpsスタイルの作業ストリームをサポートするうえで必要となる多くの能力を実際に述べたもの」になっているという。
また、人によってはDevOpsをNoOps（IT運用の除去）だと茶化す向きもある。DevOpsはIT運用すべてを消し去ろうとする、からめ手からの攻撃というわけだ。というのも、DevOpsによってしばしば開発側にコード配備の管理やサービスレベルの維持といったより多くの責任が課されることになるためだ。
