DevOpsは、開発者がインフラストラクチャとリリースに責任を持つようになったことを意味しますが、この変更の背後にある要因は何ですか？

DevOpsは、開発者がインフラストラクチャとリリースに責任を持つようになったことを意味しますが、この変更の背後にある要因は何ですか？

私は自分のカードをテーブルに置きます。私は開発者であり、「DevOps」と非文化の両方で働いていました。インフラストラクチャとリリース、QA、および関連するセレモニーを心配することは、優れたコードを書くことに対する大きな注意散漫です。

しかし、業界はこの方向に向かっています。その理由は何ですか？役割の専門化の「古い」モデルはどのような問題を引き起こしましたか？

主な理由はクラウドです。

以前は、コードがフロッピーディスク、CDの順に出荷され、サーバーに展開され、その後2つのサーバーに展開されました（復元力のため）。そして、その展開はすべて手動で行うことができました。人間であるため、人間はそれを行うための訓練を受けました。

今日、あなたのコードはしばしば数十または数百のサーバーに送られます。これらのサーバーへのプロビジョニング、構成、および展開は、人間が実際に手動で行うことはできません。Chefまたはその同族を使用しているため、システム管理者がそのプロセスを自動化するのに十分なスクリプトを知っている必要があります。しかし、率直に言って、それを行うことができるシステム管理者が十分ではありませんでした。そのため、開発者たちはスラックを拾い上げるために引き寄せられました。

そして、ええ、開発者の増え続ける要件にスキルを追加すると、当然、他の場所で彼らの能力が低下します。アイデアは、ビルド/リリースプロセスへのdevの洞察を可能にし、彼らはより良い問題を予測、またはそれを改善するための自律性を持つことができるということです。アイデアは、リリースがコード記述の損失を上回るため、すべての品質が向上するということです。

私は、トレードオフは人々がそうするように頻繁にそれの価値があると懐疑的です。

さまざまな組織がDevOpsに移行する理由はたくさんあります。
私は頻繁に出てくるものをリストしようとします。

変更サイクルの時間を短縮する
多くの場合、変更の要求を行ってから実際に組織で展開して使用するまでに長い時間がかかります。最初に、開発者が開発サイクルの1つで計画し、配信後、運用のリリースサイクルの1つで計画します。両方のサイクルにはテストが含まれ、問題が見つかった場合は両方のサイクルがリセットされます。開発部門と運用部門を統合することにより、両方のプロセスを合理化できます。

ソフトウェアとハ​​ードウェアの問題
バグとダフィーがアヒルの季節かウサギの季節かを議論しているバグバニーの漫画を覚えていますか？今度は、開発者がハードウェアの問題であると主張し、操作がソフトウェアの問題であると主張する開発者と操作で作成したと想像してください。エンドユーザーにとって、これは違いのない区別です。彼らはそれを直したいだけです。
開発者と運用を結び付けることで、問題を修正する必要があります。そして、それはソフトウェアとハ​​ードウェアの問題であることが判明するかもしれません。

米国対それら
多くの企業では、テスターと開発者が別々の部門であり、開発サイクルがますます正式化および標準化されていたため、テスターと開発者の間の距離は拡大していました。
アジャイルの登場により、開発者とテスターはより緊密に連携して作業を進め、開発サイクルに関する互いの視点を見始め、それを尊重するようになりました。
両方の分野が成熟し、プロセスがさらに形式化および標準化されるにつれて、これらの部門間の距離が拡大しているため、開発者と運用の間で同様のことが必要です。したがって、従来のモデルの問題の1つは、開発者と運用のどちらにとっても「私たち」対「彼ら」のように見えることです。どちらも相手の責任の難しさを完全に理解していない。

期待/利点
DevOpsを使用すると、両方の専門分野が、他の人が伝統的に実行していたスキルの一部を学習します。システム管理者がソフトウェアエンジニアになることや開発者がネットワークエンジニアになることは誰も期待しませんが、両方が他の責任を引き受けることが期待されます。これは、あなたが本当に余分な手を必要とするとき、彼らがそこにいることを意味します。

また、開発者にはいくつかの明確な利点があります。テスト環境をより細かく制御できるようになり、ユーザーにソフトウェアを展開しやすくなり、組織内のより多くの人々がクラフトの愛を共有できるようになります。

高品質のコードを書くだけでは不十分です。あなたは問題の一部であるか、解決策の一部です。

多くのプログラマーにとって、あなたはエンドユーザーから金を払われているソフトウェアを書いています。品質の高いコードを書くことは良いことですが、クライアント/マネージャーは、常に高速で実行する必要があると考えています。大工が正確に板を切ると言っているようなものですが、実際に誰かが支払いたいものを作っていますか？

DevOpsを使用すると、開発者はコードをより詳細に制御でき、コードが最終結果と一致するように強制できます。運用プロセスの自動化に最適なのは誰ですか？エンドユーザーの満足度が主要な測定基準です。高品質のコードを記述する必要があるだけでなく、顧客を満足させる必要があります。申し訳ありませんが、コード行の使用に戻るユーザーはいません。通常の住宅購入者が木を切り倒して独自のボードを作成しても気にしないのと同じように、ゼロから独自のORMフレームワークを構築しても、彼らは気にしません。「アップグレード」によってデフォルトに戻されるため、すべての構成ファイルをやり直しますか？

開発者のチョップを披露したいですか？ユーザーが購入したいものを構築します。これにはユーザーエクスペリエンス全体が含まれます。高品質のコードを書いているのは素晴らしいことですが、残念ながら、支払いを行っているクライアントの満足のいくところまでリリースされていない場合、ボーナスを受け取れないかもしれません。QAを非難しても構いませんが、あなたの会社にはまだあなたにもっと支払う十分なお金がありません。

これは、アジャイル＆スクラムと密接に関係しているものです。明確に定義された職務はもはやありません。誰もが「開発者」です。

そして、それは単なるopsではありません。開発者は、多くの場合、ビジネス分析、テスト、データベース管理、およびビルドマネージャーの役​​割を引き受ける必要があります-リストは続きます。

問題の中心にあるのは解約と呼ばれるものでした。プロジェクトに関与するさまざまな役割の数が増えるにつれて、会議、誤解、リソースの衝突が増えました。ソフトウェアをユーザーの目の前ですばやく取得することは、最終ゲームであり、邪魔になる可能性のあるものは何でも道の脇を通り過ぎています。

これは完全に悪いことではありません。現在、ジャムは非常に薄くなっていますが、平均的な開発者はスキルを伸ばしています。また、デプロイがナシの道を行くときに問題がどこにあるかについて、コーダーとサーバー管理者の間の議論を避けます。開発者は多くの場合、最先端のテクノロジーを使用してソリューションをプッシュしたいと考えており、サーバー管理者は、インストールセットが提示されるまで、管理POVからこれが何を意味するのか分からないことがよくあります。

より明るくより先進的な企業は、T字型の人々が良いことであることについに気付き始めています。しかし、彼らが良いことだと考えていることと、これが伝統的な文化が以前に採用されていた場所で魔法のように起こることを期待することとの間には違いがあります。

私は確かにするために、開発者のためのいくつかの良い上の理由よりも多くありますよまた、業務や品質管理を（時々 ）を管理します。それらの3つは次のとおりです。

• 興味
  一部の開発者は、実際には製品のすべての面で働きたいと思っています。彼らが得意であり、チームの空白を埋めている場合、または他の役割の既存のチームメンバーに適切なサポートを提供している場合、それらを停止する理由はありません。
• コスト
  大企業は専門の従業員に余裕があります。中小企業ではできない場合があります。これらの場所のいくつかは、1つまたは2つまたは3つの開発者を雇うことができます。
• プロジェクトサイズ
  すべてのプロジェクトが多人数プロジェクトであるとは限りません。「小さな」アプリケーションを作成している場合、1人以上で作業を完了するのは単純にやり過ぎかもしれません。さらに、多くの個人が特定の役割を担っている小さなプロジェクトは怖いです。誰が行うのに十分な仕事を持っていない-あなたができる場合であっても余裕が 6ヶ月間、彼らの親指をひねりするすべての周りにそれらを保つために、良いものは残りません。彼らが退屈しなければ、彼らは怖くなります。いずれにせよ、あなたの優秀な従業員は去り、あなたに近づかないよう皆に告げます。

...そして、他の理由、私は確信しています。

「インフラストラクチャとリリース、QA、および関連するセレモニーを心配することは、優れたコードを書くことに対する大きな注意散漫です」

本質的に、DevOpsはインフラストラクチャとリリースの心配、QAは良いコードを書いていると言っていると思います。

DevOps以外のカルチャで動作する以前の役割では、DevOpsカルチャが防ぐことができたと思われる多くの問題がありました。非代表的なプラットフォームで開発されたコードに関連するパフォーマンスの問題、開発者がクライアントが使用する文字エンコーディングを知らない文字エンコーディングの問題、手作業でコーディングされ、ある程度の推測なしではOpsチームにとって不十分な展開手順-作業。

開発側と運用側の両方で専門性を高めることでこれらのいくつかを克服できると主張することができますが、多くのことはチーム間で知識と作業を共有することによってのみ解決できます。

DevOpsは「DevがOpsも行うようになった」という意味ではありません。元々、この用語は「Dev と Opsの人々が1つのチームで緊密に連携する」ことを意味していました。それはない、物事を自動化することは、プログラミングのいくつかの並べ替えを必要とし、古いマニュアルの方法は、（この点について、より詳細な精緻化のための他の回答を参照してください）それをカットしていませんので、オプスの人々は、より多くのDevようになるために必要があることを意味します。

ウィキペディアから：

DevOps（開発と運用のクリップされた化合物）は、ソフトウェア開発とインフラストラクチャ変更のプロセスを自動化しながら、ソフトウェア開発者と他の情報技術（IT）プロフェッショナルの両方のコラボレーションとコミュニケーションを重視する文化、運動、または実践です

私の意見では、実際、開発者としてのあなたが同じ古い責任を持ち、さらに現在はオペレーションの責任を持っている場合、それは管理側の誤算のようです。物事を自動化することにより、必要なOpsの人員が少なくなる可能性が非常に高いため、実際にコストを節約できます。しかし、DevOpsは確かに「すべてのOpsの人々を排除して、開発者に追加の作業をさせましょう」という意味ではありません。

Buzzwordsでよくあることですが、セマンティック拡散が起こり、人々は突然「開発者にもOpsを作らせて、お金を節約できると思います...」と考えます。