ITパスポート試験 用語辞典
- 分野：
- マネジメント系 » ソフトウェア開発管理技術 » 開発プロセス・手法
- 重要度：
(Wikipedia DevOpsより)
DevOps（デブオプス）は、ソフトウェア開発手法の一つ。開発 (Development) と運用 (Operations) を組み合わせたかばん語であり、開発担当者と運用担当者が連携して協力する（さらに両担当者の境目もあいまいにする）開発手法をさす。厳密な定義は存在しておらず、抽象的な概念に留まっている。ソフトウェアのビルド、テスト、そしてリリースの文化と環境を以前よりも迅速に、頻繁に、確実に発生する確立を目指している。 また、DevOpsにビジネス部門を追加したBizDevOpsというワードも広がりつつある。
概要
従来の機能別に分離された組織では、このような開発部門とIT部門の部門間統合はほとんどない。しかし、DevOpsでは、開発部門、IT運用部門、あるいは品質保証（QA）部門が協力するプロセスと方法を推進している。
語源
2008年のアジャイルカンファレンスにおいて、アンドリュー・クレイ・シェーファーとパトリック・デボイス が「アジャイル・インフラストラクチャ」について議論した。そして、DevOpsという用語は2009年ベルギーで初めて開催された「DevOpsDays」から普及し、以後、世界中の多くの国々で「DevOpsDays」カンファレンスが開催されている。
DevOpsとアーキテクチャ
DevOpsは文化的な移行と（開発、運用、テストの部門間の）協力の概念であることから、単独での「DevOpsツール」というようなものはなく、複数のツールで構成される「DevOpsツールチェーン」となる。DevOpsツールは、主にソフトウェア開発とデリバリー・プロセスの側面を有しており、一般的には1つ以上のカテゴリに分類される。
- コード ： コードの開発とレビュー、バージョン管理ツール、コードのマージ
- ビルド ： 継続的インテグレーションのツール、ビルドステータス
- テスト ： パフォーマンスを決定するためのテストと結果
- パッケージ ： 案件リポジトリ、アプリの展開前ステージング
- リリース ： 変更管理、リリース承認、リリース自動化
- コンフィギュレーション ： インフラストラクチャの設定と管理、インフラストラクチャとしてのコードのツール
- モニター ： アプリの性能監視、エンドユーザーエクスペリエンス
利用可能なツールは多数あるが、会社・組織でDevOpsツールチェーンを利用するには、カテゴリの特定が必要となる。その基本的なツールを特定する方法は既存の文献で探すことができる。DevOpsの実現には構成管理ツールであるDocker（コンテナリゼーション）、Jenkins（継続的インテグレーション ）、Puppet（インフラストラクチャとしてのコード）、またはVagrant（仮想化プラットフォーム）などが用いられることもあり、DevOpsツールの検討で頻繁に参照される。DevOpsという語句からこうしたツールがイメージされることもある
アジャイルソフトウェア開発・継続的デリバリーとの関係
アジャイル
DevOpsの概念はアジャイルソフトウェア開発といった概念とも関連している。ただし似てはいるが、方法は異なる。アジャイルソフトウェア開発は考え方と学びを変えることが組織改革につながるという手法であり、DevOpsは組織改革を強化することで目標を達成する手法である。
小さな変更を頻繁にリリースすることの多いアジャイルソフトウェア開発においては、開発担当者と運用担当者の連携を密にする必要があり、こうした開発手法の普及とともにDevOpsの考え方が広まることとなった。アジャイルソフトウェア開発が拡がるにつれて、リリース回数が増加する傾向のなかでDevOpsが開発された。
DevOpsの目標の一つは、より信頼性の高いアプリがより早く頻繁にリリースされる環境を作ることである。この目標を達成するために、リリース管理者は継続的なデリバリー方法を取りながら、アプリケーションリリースの自動化や継続的な統合ツールなどを利用し始めている。
DevOpsに関わる多くの考え方や関係者は、エンタープライズシステムの管理とアジャイルソフトウェア開発の潮流のなかから生まれた。
継続的デリバリー
DevOpsと継続的デリバリーはともにアジャイルメソッドとリーン生産方式を背景としているため、間違われやすい。似てはいるが、異なる概念である
DevOpsはより広い範囲を対象にしており、主なポイントは：
- 組織改革：ソフトウェアデリバリーに関わるさまざまなチーム（開発、IT運用、品質保証・QA、管理など）の協力を育む
- 自動化：ソフトウェアデリバリー・プロセスを自動化する
継続的デリバリーはデリバリー・プロセスを自動化することを目的にしているだけで、主なポイントは：
- 異なるプロセスの組み合わせ
- プロセスの迅速かつ頻繁な実行
DevOpsと継続的デリバリーは共通の目標を達成するために、一緒に使用されることもある。社内に小さくて速い変化がよく伝達され、協力体制がある場合、リスクを低減しながら、迅速な市場投入を支援し、エンドユーザーの価値にフォーカスすることができる。
目標
DevOpsが特定する目標はデリバリー・パイプラインの全体にまたがる。例えば、展開頻度を改善する場合の目標は、
- 市場投入までの時間短縮
- 新しいリリース時の失敗率低減
- 修正の間にリードタイムを短縮
- （新しいリリースでクラッシュしたり、現在のシステムを無効にすることがある場合、）回復時間の短縮
DevOpsアプローチを使用することで、シンプルなプロセスであってもよりプログラムの可用性が高まり、ダイナミックなプロセスになる。DevOpsは運用プロセスの予測可能性、効率性、セキュリティ、又は保守性を最大化することを目指している。しばしば、自動化がこの目標を支援する。
また別の目標として、信頼性とセキュリティを改善しながら、迅速な開発と展開サイクルを提供することがある。そのために、DevOpsの統合は、製品の出荷、継続的なテスト、品質テスト、機能開発、又はメンテナンスリリースを対象としている。
開発環境を標準化することで、DevOpsは組織のソフトウェア・アプリケーション・リリース管理を支援する。リリースイベントを簡単に追跡することができ、文書化されたプロセス制御と細かいレポートの問題を解決できる。DevOpsアプローチにより、開発者は環境をより詳細に制御することができ、インフラストラクチャによりアプリケーション中心的な理解を反映することができる。DevOpsの利点
DevOpsを試している会社・組織からは、大きなメリットが報告されている。
- 市場投入までの時間の短縮
- 高い顧客満足度
- 改良された製品の品質
- 改良されて、信頼性の高いリリース
- 改良された生産性・効率
- 迅速な実験によって、適切な製品を構築する能力
文化の変化
DevOpsの実現には単なるツールやプロセスの変更だけではなく、本質的な組織文化の転換が必要となる。以下のように各部門の持つ役割と性質が相反するため、組織文化の変化は特に困難である。
- 運用担当者は組織の安定性を求めている。
- 開発者は変化を求めている。
- テスターはリスク削減を求めている。
DevOps文化を培う
DevOpsの原則は強力な部門間のコミュニケーションを要求するため、チームビルディングや他の従業員参加活動がしばしば利用される。チームビルディング活動にはボードゲーム、信頼活動、従業員参加セミナーなどがある。強力な部門間のコミュニケーションを育むことで、文化の変化を促進する環境を作り出すことができる。
展開
非常に多くのリリースを有する企業では、DevOpsの意識啓発プログラムが必要になる場合がある。例えば、DevOpsという単語は2009年のオライリー主催のイベント「Velocity 2009」において、画像ホスティングWebサイトFlickrのエンジニアにより初めて公の場で用いられた。このプレゼンテーションでは「開発と運用が協力することで、1日に10回以上のペースでのリリースが可能になる」という発表とともにDevOpsという単語が用いられた。毎日の展開サイクルは、マルチフォーカスまたはマルチファンクションアプリケーションを作成する組織では多いだろう。それは、継続的な展開又は継続的なデリバリーと呼ばれて、リーンスタートアップ方法論に関連付けられている。 2009年の会議以降、ワーキンググループ、プロフェッショナルな協会やブログ上で話題となっている。
DevOpsとアーキテクチャ
DevOpsを効果的に実践するためには、ソフトウェア・アプリケーションはアーキテクチャ上重大な要求（ASR）と呼ばれている要求を満たす必要がある。展開性、修正可能性、テスト容易性、と監視性などASRは高い優先度を必要とする
基本的には、どのようなアーキテクチャ・スタイルでも、DevOpsを実践することは可能である。しかし、展開されるシステムを構築する場合のマイクロ・サービスのアーキテクチャ・スタイルが標準になりつつある。各サービスのサイズが小さいため扱いやすくなり、そして、継続的な編集を通じて、各サービスのアーキテクチャが見えるようになる。そのため、大きな初期設計が不要となり、ソフトウェアを早期に継続的にリリースすることができる。
導入の範囲
DevOpsの文献には、組織のIT部門以外からのDevOpsイニシアチブへの重要な参加が必要だと勧めている記事がある。例えば、「DevOpsは、企業全体にもたらされたアジャイルの原則である」というメッセージがある。もう一つの広い範囲からの参加の例は、内部資金調達プロセスへの変更：「資金調達は通常滝のように提供される。しかし、継続的デリバリー・モデルには、適していない確定日付（月、四半期、会計年度、など）というゲートがあるので、資金調達も継続的でなければならない。」
DevOpsの導入は、以下のような多くの要素によって推進されている。
- アジャイルなどの開発プロセス・方法の使用
- （アプリケーションとビジネスユニットの利害関係者からの）生産リリースの増加に対する需要
- （内部と外部の提供者からの）仮想とクラウドインフラストラクチャの幅広い利用可能性
- データセンターの自動化と構成管理ツールの使用の増加
- テストの自動化と継続的な統合方法の重点
- 公開されている大量の最善の措置
増分導入
制約の理論は、DevOpsの導入に適用される。単一の制約とは、企業内の部門の変更に対する先天的な嫌悪感である。増分導入では、制約の理論の方法論を具現化し、「5つの焦点のステップ」として知られている制約を克服するためのステップを提供する。
増分導入のアプローチは、企業全体に広範な実装を成功させるために、必要な社内のスキルセットと勢いを構築しながら、DevOps導入のリスクとコストを最小限に抑えるという考えを中心にしている。ジーン・キムの「3 つの基本原則」は、さまざまな方法でDevOpsを増分的に導入している。
第1の原則：システムの考え方
特定のひとつの部門（または個人）のパフォーマンスではなく、システム全体のパフォーマンスに重点を置いている。重点はITを扱うすべてのビジネスバリューストリーム上にある。このプロセスは線形に流れるため、欠陥が通過しないことを保証する。
第2の原則：フィードバックループを増幅する
関係しているすべてのチームのフィードバックと理解の向上に重点を置いている。その結果として、顧客（内部と外部）へのコミュニケーションと応答を向上させ、フィードバックループを短縮、増幅し、知識を必要な場所に伝える
第3の原則： 継続的な実験と学習の文化
実験と実践が同様に重要である。リスクから学ぶこと、反復、又は練習を職場文化に組み込むことは、熟練への鍵である。リスクを取って実験したり、改善と習得を促進したりすることで、間違いを取り返すために必要なスキルを身につけることができる。
- オブジェクト指向
- データ中心アプローチ
- プロセス中心アプローチ
- UML
- DevOps
- ウォータフォールモデル
- スパイラルモデル
- プロトタイピングモデル
- RAD
- リバースエンジニアリング
- アジャイル
- XP
- テスト駆動開発
- ペアプログラミング
- リファクタリング
- スクラム
- 共通フレーム
- CMMI
このページのWikipediaよりの記事は、ウィキペディアの「DevOps」(改訂履歴)の記事を複製、再配布したものにあたり、このページ内の該当部分はクリエイティブ・コモンズ 表示 - 継承 3.0 非移植 ライセンスの下 に提供されています。