DevOps

ウィキペディア

索引トップ用語の索引ランキングカテゴリー

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2023/03/18 01:12 UTC 版)

文化の変化

DevOpsの実現には単なるツールやプロセスの変更だけではなく、本質的な組織文化の転換が必要となる。以下のように各部門の持つ役割と性質が相反するため、組織文化の変化は特に困難である。

運用担当者は組織の安定性を求めている。
開発者は変化を求めている。
テスターはリスク削減を求めている。

DevOps文化を培う

DevOpsの原則は強力な部門間のコミュニケーションを要求するため、チームビルディングや他の従業員参加活動がしばしば利用される。チームビルディング活動にはボードゲーム、信頼活動、従業員参加セミナーなどがある。強力な部門間のコミュニケーションを育むことで、文化の変化を促進する環境を作り出すことができる。

展開

非常に多くのリリースを有する企業では、DevOpsの意識啓発プログラムが必要になる場合がある。例えば、DevOpsという単語は2009年のオライリー主催のイベント「Velocity 2009」において、画像ホスティングWebサイトFlickrのエンジニアにより初めて公の場で用いられた。このプレゼンテーションでは「開発と運用が協力することで、1日に10回以上のペースでのリリースが可能になる」という発表とともにDevOpsという単語が用いられた。毎日の展開サイクルは、マルチフォーカスまたはマルチファンクションアプリケーションを作成する組織では多いだろう。それは、継続的な展開又は継続的なデリバリーと呼ばれて、リーンスタートアップ方法論に関連付けられている。 2009年の会議以降、ワーキンググループ、プロフェッショナルな協会やブログ上で話題となっている。

DevOpsとアーキテクチャ

DevOpsを効果的に実践するためには、ソフトウェア・アプリケーションはアーキテクチャ上重大な要求（ASR）と呼ばれている要求を満たす必要がある。展開性、修正可能性、テスト容易性、と監視性などASRは高い優先度を必要とする^[11] 基本的には、どのようなアーキテクチャ・スタイルでも、DevOpsを実践することは可能である。しかし、展開されるシステムを構築する場合のマイクロ・サービスのアーキテクチャ・スタイルが標準になりつつある。各サービスのサイズが小さいため扱いやすくなり、そして、継続的な編集を通じて、各サービスのアーキテクチャが見えるようになる。そのため、大きな初期設計が不要となり、ソフトウェアを早期に継続的にリリースすることができる。

導入の範囲

DevOpsの文献には、組織のIT部門以外からのDevOpsイニシアチブへの重要な参加が必要だと勧めている記事がある。例えば、「DevOpsは、企業全体にもたらされたアジャイルの原則である」というメッセージがある。^[12]もう一つの広い範囲からの参加の例は、内部資金調達プロセスへの変更：「資金調達は通常滝のように提供される。しかし、継続的デリバリー・モデルには、適していない確定日付（月、四半期、会計年度、など）というゲートがあるので、資金調達も継続的でなければならない。」^[13] DevOpsの導入は、以下のような多くの要素によって推進されている。

アジャイルなどの開発プロセス・方法の使用
（アプリケーションとビジネスユニットの利害関係者からの）生産リリースの増加に対する需要
（内部と外部の提供者からの）仮想とクラウドインフラストラクチャの幅広い利用可能性
データセンターの自動化と構成管理ツールの使用の増加
テストの自動化と継続的な統合方法の重点
公開されている大量の最善の措置

増分導入

制約の理論は、DevOpsの導入に適用される。単一の制約とは、企業内の部門の変更に対する先天的な嫌悪感である。増分導入では、制約の理論の方法論を具現化し、「5つの焦点のステップ」として知られている制約を克服するためのステップを提供する。増分導入のアプローチは、企業全体に広範な実装を成功させるために、必要な社内のスキルセットと勢いを構築しながら、DevOps導入のリスクとコストを最小限に抑えるという考えを中心にしている。ジーン・キムの「3 つの基本原則」は、さまざまな方法でDevOpsを増分的に導入している。