DevOpsは、開発者がインフラストラクチャとリリースの責任を負うことを意味しますが、この変更の背後にある推進要因は何ですか？
DevOpsは、開発者がインフラストラクチャとリリースの責任を負うことを意味しますが、この変更の背後にある推進要因は何ですか？
カードをテーブルに載せます。私は開発者であり、「DevOps」と非文化の両方で働いています。インフラストラクチャとリリース、QAとそれに関連するセレモニーについて心配する必要があることは、優れたコードを作成する上での大きな注意散漫です。
しかし、業界はこの方向に向かっているので、その理由は何ですか？役割専門化の「古い」モデルはどのような問題を引き起こしましたか？
主な理由はクラウドです。
以前は、コードがフロッピーディスクで出荷され、次にCDで出荷されてから、サーバーに配置され、2つのサーバーに配置されました（回復力のため）...そして、その配置はすべて手動で行うことができました人間によって、それで人間はそれをするために訓練されました。
今日、コードは多くの場合、数十または数百のサーバーに配置されます。これらのサーバーへのプロビジョニング、構成、および展開は、人間が実際に手動で行うことはできません。現在Chefまたはその類縁を使用しているため、システム管理者はそのプロセスを自動化するのに十分なスクリプトを知っている必要があります。しかし率直に言って、それを行うことができる十分なシステム管理者がいませんでした。そのため、開発者はスラックを拾うために引き込まれました。
ええ、開発者の増え続ける要件にスキルを追加すると、当然、他の場所での能力が低下します。 ideaは、ビルド/リリースプロセスに対する開発者の洞察を可能にすることで、問題をより適切に予測したり、自律性を向上させたりすることができます。アイデアは、リリースの勝利がコードライティングの損失を追い越すため、すべての品質が向上するということです。
トレードオフは、人々がそうであるとするのと同じくらい頻繁にそれを価値があると私は懐疑的です。
さまざまな組織がDevOpsに移行する理由はたくさんあります。
私は頻繁に出てくるものをリストアップしようとします。
サイクルを変更する時間を短縮
変更を要求してから、実際に組織で展開および使用されるまでに長い時間がかかることがよくあります。最初に、開発者による開発サイクルの1つで計画され、それが提供された後、運用のリリースサイクルの1つで計画されます。どちらのサイクルにもテストが含まれ、問題が見つかった場合は両方のサイクルがリセットされます。開発部門と運用部門を統合することで、両方のプロセスを合理化できます。
ソフトウェアとハードウェアの問題
バグとダフィーがアヒルの季節なのかウサギの季節なのかを論じているバグズバニーの漫画を覚えていますか？代わりに、開発者とオペレーションを使用して、ハードウェアの問題であると開発者が主張し、ソフトウェアの問題であるとオペレーションが主張していると想像してください。エンドユーザーにとって、これは違いのない区別です。彼らはそれを修正したいだけです。
開発者とオペレーションを一緒にすることで、問題を修正する必要があります。そして、それはソフトウェアとハードウェアの問題であることが判明するかもしれません。
私たち対彼ら
多くの企業では、テスターと開発者が別々の部署であり、開発サイクルがますます形式化および標準化されているため、テスターと開発者の間の距離が広がっています。
アジャイルの登場により、開発者とテスターはより緊密に連携し、開発サイクルに関するお互いの視点を確認し始め、それを尊重するようになるかもしれません。
両方のフィールドが成熟し、プロセスがさらに形式化および標準化されるにつれて、これらの部門間の距離が拡大するため、開発者と運用の間で同様の何かが発生する必要があります。したがって、従来のモデルの問題の1つは、開発者と運用のどちらにとっても「私たち」対「それら」のように見えることです。どちらも相手の責任の難しさを完全には理解していません。
期待/メリット
DevOpsを使用することで、両方の専門分野は、他の専門家が従来行ってきたスキルのいくつかを学びます。システム管理者がソフトウェアエンジニアになることや、開発者がネットワークエンジニアになることを期待する人は誰もいませんが、どちらも他の責任の一部を担うことが期待されています。これは、本当に追加のハンドが必要なときに、そこにあることを意味します。
また、開発者にとって明確な長所もあります。テスト環境をより詳細に制御できるようになり、ユーザーにソフトウェアを展開し、組織内の多くの人が技術への愛情を共有することが容易になります。
高品質のコードを書くだけでは十分ではありません。あなたは問題の一部か解決策の一部です。
多くのプログラマーにとって、あなたはソフトウェアを書いているのですが、それはエンドユーザーからの支払いを受けています。質の高いコードを書くことは良いことですが、クライアント/マネージャーが常にしなければならないことと、速く作業することを想定していることでもあります。それは大工が板を正確に切ると言っているようなものですが、実際に誰かがお金を払いたいものを作っていますか？
DevOpsを使用すると、開発者はより細かく制御でき、できればコードを最終結果と一致させることができます。運用プロセスの自動化に最適なのは誰ですか？エンドユーザーの満足度が主要な測定基準です。高品質のコードを記述する必要があるだけでなく、顧客を満足させる必要があります。申し訳ありませんが、コード行の使用に戻る人はいません。普通の住宅購入者がツリーを切り刻んで独自のボードを作成したかどうかと同じように、独自のORMフレームワークを最初から構築したかどうかは関係ありません。 「アップグレード」によりデフォルトに戻されるため、すべての構成ファイルをやり直したいですか？
開発者のチョップを自慢したいですか？ユーザーが購入したいものを構築します。これには、ユーザーエクスペリエンス全体が含まれます。高品質のコードを作成していることは素晴らしいことですが、残念ながら、有料のクライアントが満足できるようにリリースされていない場合は、ボーナスを得られない可能性があります。 QAのせいにして自由に感じてください。しかし、あなたの会社にはまだあなたにもっと支払うための十分なお金がありません。
これは、アジャイルとスクラムと連携しているものです。明確に定義された職種はなくなりました-誰もが「開発者」です。
そして、それは単なる運用ではありません。多くの場合、開発者はビジネス分析、テスト、データベース管理、ビルドマネージャーの役割を担う必要があります。
問題の中心は、チャーンと呼ばれるものでした。プロジェクトに関与するさまざまな役割の数が増えるにつれ、会議、誤解、リソースの衝突が増えました。ソフトウェアをユーザーの前にすばやく配置することは最終的なゲームであり、それを妨げる可能性のあるものはすべて、道端でいくらか進んでいます。
これは全体的に悪いことではありません。ジャムは今非常に薄くなっていますが、平均的な開発者はスキルを伸ばしています。また、デプロイメントがナシの邪魔をするときに問題がどこにあるかについて、コーダーとサーバー管理者の間の議論の先頭に立ちます。開発者は、最先端のテクノロジーを使用してソリューションをプッシュアウトすることを望み、サーバー管理者は、インストールセットが提示されるまで、管理者のPOVからこれが何を意味するのかわからないことがよくあります。
より明るく前向きな企業は、ようやく T字型の人々 が良いことであることに気づき始めています。しかし、thinkingには違いがあり、伝統的な文化が以前に採用されていた場所でこれが魔法のように起こることを期待しています。
「インフラストラクチャとリリース、QAとそれに関連する式典について心配する必要があることは、優れたコードを書くことからの大きな注意散漫です。」
根本的には、DevOpsはインフラストラクチャとリリースとQAについて心配していると言っていると思いますIS良いコードを書くこと。
DevOps以外のカルチャーで運用していた以前の役割では、間違いなくDevOpsカルチャーで防止できた可能性のある多くの問題がありました。代表的でないプラットフォームで開発されたコードに関連するパフォーマンスの問題、開発者がクライアントが使用する文字エンコーディングを知らない場合の文字エンコーディングの問題、手作業でコーディングされ、ある程度の推測なしに運用チームに不十分な導入手順-作業。
これで、開発側と運用側の両方で専門化が進んだことで、これらの一部を克服できると主張することができますが、それでも多くのことは、チーム間で知識と作業を共有することによってのみ解決できます。
DevOpsは、「DevはOpsも行う」という意味である必要はありません。この用語は、もともと「DevandOpsの人々が1つのチームで緊密に連携する」という意味でした。これはdoesは、Opsの人々がDevsのようになる必要があることを意味します。自動化には何らかのプログラミングが必要であり、古い手動の方法ではうまくいかないためですそれについて（この点についての詳細は、他の回答を参照してください）。
Wikipedia から：
DevOps（開発と運用のクリップされた複合体）は、ソフトウェア開発とインフラストラクチャ変更のプロセスを自動化しながら、ソフトウェア開発者と他の情報技術（IT）専門家の両方のコラボレーションとコミュニケーションを強調する文化、運動、または実践です
だから私の意見では、Devとしてあなたが同じ古い責任とに加えて、今や運用の責任を持っている場合、それは管理部分の誤算のようです。物事を自動化することで、運用担当者が少なくてすむ可能性が非常に高いため、実際にはコストを節約できます。しかし、DevOpsが「すべてのOps担当者を排除して、Devsに追加の作業を任せよう」という意味ではありません。
流行語で頻繁に Semantic Diffusion が発生し、突然人々は「DevsにもOpsを実行させましょう、そして私たちはお金を節約できると思います...」と突然思います。
開発者が操作と品質管理を（ときどき）またに管理することには、いくつかの正当な理由があると確信しています。以下はそのうちの3つです。
- 利息
一部の開発者は、実際に製品のすべての側面を機能させたい。彼らが良いであり、チームの空白を埋めるか、他の役割の既存のチームメンバーに良いサポートを提供している場合は、それらを止める理由にはならないかもしれません。 - コスト
大企業は専門の従業員を雇うことができます。中小企業はできない場合があります。これらの場所のいくつかは、1つまたはたぶん2または3の開発者を雇うことができます。 - プロジェクトサイズ
すべてのプロジェクトが多人数のプロジェクトであるとは限りません。 「小さな」アプリケーションを作成している場合、複数の人がそれを完成させるまで作業するのは単純にやり過ぎかもしれません。さらに、多くの個人が特定の役割を果たしている小さなプロジェクトは怖いです。 affordして6か月間親指をいじるようにすべてを維持することができるとしても、だれにも十分な仕事がありません。良いものは、滞在します。彼らが退屈しないと、彼らは怖くなるでしょう、またはあなたはあなたが無料でかなりのお金を払っていることに気づくでしょう。どちらにしても、あなたのgood従業員は去り、全員にあなたから離れるように言います。
...そして、他の理由は確かです。