デブオプス

DevOpsは、ソフトウェア開発およびIT業界における方法論です。一連のプラクティスとツールとして使用されるDevOpsは、システム開発ライフサイクルを改善および短縮する手段として、ソフトウェア開発（Dev）とIT運用（Ops ）の作業を統合および自動化します。^{[1] DevOpsは}アジャイルソフトウェア開発を補完するものであり、DevOpsのいくつかの側面はアジャイルな作業方法 に由来しています。

自動化はDevOpsの重要な部分です。ソフトウェアプログラマーとアーキテクトはソフトウェアを管理するために「フィットネス関数」を使用する必要があります。 ^[2]

「DevOps」は、「開発」と「運用」の用語と概念の多機能な組み合わせ（および混成語）であること以外には、学者や実務家は「DevOps」という用語の普遍的な定義を策定していません。 ^{[a] [b] [c] [d]}多くの場合、DevOps は、共有所有権、ワークフロー自動化、迅速なフィードバックという主要原則によって特徴付けられます。学術的な観点から、CSIROとSoftware Engineering Instituteの 3 人のコンピューター サイエンス研究者であるLen Bass、Ingo Weber、Liming Zhu は、DevOps を「システムへの変更をコミットしてから、その変更が通常の運用に適用されるまでの時間を短縮し、高品質を確保することを目的とした一連のプラクティス」と定義することを提案しました。^[6] ただし、この用語はさまざまなコンテキストで使用されています。最も成功した DevOps は、特定のプラクティス、文化の変化、およびツールの組み合わせです。^[7]

ソフトウェア開発方法論と展開および運用の概念を組み合わせる提案は、80年代後半から90年代前半にかけて現れ始めました。^[8]

2007年から2008年頃、ソフトウェア開発とITコミュニティの関係者から、ソフトウェアを開発・作成する側とソフトウェアを展開・サポートする側が完全に分離されているという2つの業界の分離が、業界内に致命的なレベルの機能不全を引き起こしているという懸念が提起されました。^[9]

2009年、DevOps Daysという最初のカンファレンスがベルギーのゲントで開催されました。このカンファレンスは、ベルギーのコンサルタント、プロジェクトマネージャー、アジャイル実践者のパトリック・デボアによって創設されました。^{[10] [11]}このカンファレンスは現在、他の国々にも広がっています。^[12]

2012年に、 Puppet LabsのAlanna Brownによって「State of DevOps」というレポートが初めて公開されました。^{[13] [14]}

2014年には、 Nicole Forsgren 、Gene Kim、Jez Humbleらによって年次のState of DevOpsレポートが発行されました。彼らは、DevOpsの導入が加速していると述べました。^{[15] [16]}また、2014年には、Lisa CrispinとJanet GregoryがMore Agile Testingという本を執筆し、テストとDevOpsに関する章を1つ含んでいます。^{[17] [18]}

2016年には、スループット（デプロイメント頻度、変更のリードタイム）と安定性（平均回復時間、変更失敗率）に関するDORA指標がState of DevOpsレポートで公開されました。 ^[13]しかし、研究方法と指標は専門家から批判されました。^{[19] [20] [21] [22]}これらの批判に応えて、2023年のState of DevOpsレポート^[23]では、安定性指標「平均回復時間」を「失敗したデプロイメント回復時間」に更新する変更が公開され、以前の指標が引き起こした混乱が認められました。^[24]

DevOps の実践の基盤となるアイデアの多くは、リーンやデミングの 計画・実行・評価・改善サイクルから、トヨタ方式、コンポーネントとバッチ サイズを細分化するアジャイルアプローチまで、他のよく知られた実践からヒントを得たり、反映したりしています。 ^{[25] 1990 年代の}ITILの「トップダウン」の規範的アプローチと厳格なフレームワークとは対照的に、DevOps は「ボトムアップ」で柔軟性があり、ソフトウェア エンジニアが独自のニーズに合わせて作成しました。^[26]

現代の DevOps となったものや、自動化されたビルドとテスト、継続的インテグレーション、継続的デリバリーなどのいくつかの標準的な DevOps プラクティスの動機は、（非公式には）1990 年代、正式には 2001 年にまで遡るアジャイルの世界に端を発しています。エクストリーム プログラミングなどの手法を使用するアジャイル開発チームは、アプリケーションの運用とインフラストラクチャの責任を負い、その作業の多くを自動化しない限り、「価値のあるソフトウェアを早期かつ継続的に提供して顧客を満足させる」ことはできませんでした^{[27] 。2000 年代初頭にアジャイル フレームワークとして主流となった}Scrumでは、多くのアジャイル チームの一部であったエンジニアリング プラクティスが省略されたため、運用とインフラストラクチャ機能を自動化する動きがアジャイルから分裂し、現代の DevOps となったものに拡大しました。今日、DevOps は、アジャイル指向の方法論を使用して開発されたか、他の方法論を使用して開発されたかに関係なく、開発されたソフトウェアの展開に重点を置いています。

ArchOpsは、運用展開のためにソースコードではなくソフトウェアアーキテクチャ成果物から始まるDevOps実践の拡張を提示します。 ^[28] ArchOpsは、アーキテクチャモデルがソフトウェア開発、展開、および運用における第一級のエンティティであると述べています。

自動化はDevOpsを成功させるための中核原則であり、CI/CDは重要な要素です。^[29]さらに、チーム間およびチーム内のコラボレーションとコミュニケーションの改善により、市場投入までの時間が短縮され、リスクが軽減されます。^[30]

モバイルDevOpsは、DevOpsの原則をモバイルアプリケーションの開発に特化して適用する一連のプラクティスです。従来のDevOpsは、一般的にソフトウェア開発プロセスの合理化に重点を置いていますが、モバイル開発には独自の課題があり、カスタマイズされたアプローチが必要です。^[31]モバイルDevOpsは、単にモバイルアプリ開発に特化したDevOpsの分野ではなく、モバイルの世界の非常に特殊な要件のためにDevOpsの哲学を拡張および再解釈したものです。

2003年、Googleはサイト信頼性エンジニアリング（SRE）を開発しました。これは、高品質のエンドユーザーエクスペリエンスを維持しながら、大規模な高可用性システムに新しい機能を継続的にリリースするアプローチです。^[32] SREはDevOpsの開発に先行していますが、一般的には互いに関連していると見なされています。この分野の元の著者の中には、SREをDevOpsの実装と見なす人もいます。^[33]

トヨタ生産方式はTPSとも呼ばれ、継続的な改善、カイゼン、フロー、小ロット生産に重点を置いたリーン思考のインスピレーションとなった。迅速なフィードバック、問題解決、集団化を生み出すアンドンコードの原理はTPSに由来する。^{[34] [35]}

DevSecOps は、DevOps を拡張したもので、DevOps アプローチにセキュリティ プラクティスを統合できるようにします。従来の集中型セキュリティ チーム モデルとは異なり、各配信チームは、ソフトウェア配信に適切なセキュリティ制御を組み込む権限を持っています。セキュリティ プラクティスとテストは開発ライフサイクルの早い段階で実行されるため、「シフト レフト」と呼ばれます。セキュリティは、静的、ソフトウェア構成、動的の 3 つの主要な領域でテストされます。

静的アプリケーション セキュリティ テスト(SAST)によるソフトウェアの静的チェックは、セキュリティに特に重点を置いたホワイト ボックス テストです。プログラミング言語に応じて、このような静的コード分析を行うにはさまざまなツールが必要です。ソフトウェアの構成、特にライブラリが分析され、各コンポーネントのバージョンがCERTやその他の専門家グループによって公開された脆弱性リストと照合されます。ソフトウェアをクライアントに提供する際には、ライブラリ ライセンスと配布されるソフトウェアのライセンスとの一致、特にコピーレフトライセンスが重要になります。

動的テストはブラックボックステストとも呼ばれ、ソフトウェアの内部機能を知らなくてもテストが行​​われます。DevSecOpsでは、この方法は動的アプリケーションセキュリティテスト（DAST）または侵入テストと呼ばれることがあります。クロスサイトスクリプティングやSQLインジェクションの脆弱性などの欠陥を早期に検出することが目標です。脅威の種類は、オープンウェブアプリケーションセキュリティプロジェクト（そのTOP10など^）[36]やその他の団体によって公開されています。

DevSecOpsは、セキュリティ教育、設計によるセキュリティ、セキュリティ自動化を統合することで、安全なソフトウェアを生み出すための総合的なアプローチを伴う文化的変化としても説明されています。^[37]

DevOpsの取り組みは、開発と配信のプロセス中に運用、開発者、テスト担当者が協力する方法を変えることで、企業に文化的な変化をもたらすことができます。[ ^{38 ] [ 39]}これらのグループが団結して作業できるようにすることは、企業のDevOps導入における重要な課題です。^{[40] [41]} DevOpsはツールチェーンと同じくらい文化に関するものです。^[42]

原理的にはどんなアーキテクチャスタイルでもDevOpsを実践することは可能ですが、マイクロサービスアーキテクチャスタイルは継続的にデプロイされるシステムを構築するための標準になりつつあります。小規模なサービスでは、継続的なリファクタリングを通じて個々のサービスのアーキテクチャを作り上げることができます。^[43]

また、組織内の一貫性、信頼性、効率性もサポートし、通常は共有コードリポジトリまたはバージョン管理によって有効になります。DevOps研究者のRavi Teja Yarlagaddaは、「DevOpsを通じて、すべての機能を単純なコードを使用して中央の場所で実行、制御、管理できるという前提があります。」と仮説を立てています。^[44]

多くの組織では、仮想マシン、コンテナ化（またはOSレベルの仮想化）、CI/CDなどのDevOps自動化テクノロジーを強化するためにバージョン管理を使用しています。論文「DevOps：銀行分野におけるツールチェーンの開発」では、同じプロジェクトに取り組んでいる開発者チームについて、「すべての開発者が同じコードベースに変更を加え、時には同じファイルを編集する必要があります。効率的に作業するには、エンジニアが競合を回避し、コードベースの履歴を保持するのに役立つシステムが必要です」と述べており、^[45] Gitバージョン管理システムとGitHubプラットフォームが例として挙げられています。

GitOps は DevOps から進化しました。デプロイメント構成の特定の状態はバージョン管理されています。最も人気のあるバージョン管理はGitであるため、GitOps のアプローチはGitにちなんで名付けられました。構成の変更はコードレビューの実践を使用して管理でき、バージョン管理を使用してロールバックできます。基本的に、コードへのすべての変更は追跡され、ブックマークされ、履歴の更新が容易になります。Red Hatの説明によると、「変更の可視性は、問題を迅速に追跡および再現する能力を意味し、全体的なセキュリティが向上します。」^[46]

• データオペレーション
• DevOps ツールチェーン
• 12 要素アプリの方法論
• インフラストラクチャをコードとして
• リーンソフトウェア開発
• サイト信頼性エンジニアリング
• バリューストリーム
• ビルド自動化ソフトウェアのリスト

• Davis, Jennifer; Daniels, Ryn (2016-05-30)。効果的な DevOps: 大規模なコラボレーション、親和性、ツールの文化の構築。セバストポル、カリフォルニア州: O'Reilly。ISBN 9781491926437. OCLC  951434424.

• Kim, Gene; Debois, Patrick; Willis, John; Humble, Jez; Allspaw, John (2015-10-07)。DevOpsハンドブック: テクノロジー組織で世界クラスの敏捷性、信頼性、セキュリティを実現する方法(初版)。オレゴン州ポートランド。ISBN 9781942788003. OCLC  907166314.{{cite book}}: CS1 メンテナンス: 場所が見つかりません 発行者 (リンク)

• ニコール・フォースグレン、ジェズ・ハンブル、ジーン・キム（2018 年 3 月 27 日）。『Accelerate: リーン ソフトウェアと DevOps の科学: 高業績テクノロジー組織の構築と拡張』（初版）。IT Revolution Press。ISBN 9781942788331。