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