DevOps

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

DevOpsは、ソフトウェア開発Dev)とIT運用Ops )を組み合わせた一連のプラクティスですこれは、システム開発ライフサイクルを短縮し、品質のソフトウェアを継続的に提供することを目的としています[1] DevOpsはアジャイルソフトウェア開発を補完します。いくつかのDevOpsの側面は、アジャイル手法に由来します。

定義

「開発」と「運用」の用語と概念の機能横断的な組み合わせ(およびかばん語も)であることを除けば、学者や実務家は「DevOps」という用語の普遍的な定義を開発していません。[a] [b] [c] [d]ほとんどの場合、DevOpsは、共有所有権、ワークフローの自動化、迅速なフィードバックという主要な原則によって特徴付けられます。

学術的な観点から、 CSIROソフトウェアエンジニアリングインスティテュートの3人のコンピューターサイエンス研究者であるLen BassIngo WeberLiming Zhuは、 DevOpsを「システムに変更をコミットするまでの時間を短縮することを目的とした一連のプラクティスと高品質を確保しながら、変更は通常の生産に移されます。」[5]

ただし、この用語は複数のコンテキストで使用されます。最も成功しているのは、DevOpsは特定のプラクティス、文化の変化、およびツールの組み合わせです。[6]

歴史

1993年に、電気通信情報ネットワーキングアーキテクチャコンソーシアム(TINA-C)は、ソフトウェア開発と(電気通信)サービス運用を組み合わせたサービスライフサイクルのモデルを定義しました。[7]

2009年、devopsdaysという名前の最初の会議がベルギーのゲントで開催されましたこの会議は、ベルギーのコンサルタント、プロジェクトマネージャー、アジャイル実践者のPatrickDeboisによって設立されました。[8] [誰?] [9]会議は今や他の国々にも広がっています。[10]

2012年、State of DevOpsレポートは、PuppetのAlanna Brownによって考案され、発表されました。[11] [12]

2014年の時点で、DevOpsの年次レポートは、ニコールフォースグレン、ジーンキム、ジェズハンブルなどによって発行されました。彼らは、DevOpsの採用が加速していると述べました。[13] [14]また、2014年に、リサクリスピンとジャネットグレゴリーは、テストとDevOpsに関する章を含む本More AgileTestingを執筆しました。[15] [16]

2016年に、スループット(展開頻度、変更のリードタイム)および安定性(平均回復時間、変更の失敗率)のDORAメトリックが、State ofDevOpsレポートで公開されました。[11]

ツールチェーン

DevOpsは機能横断的な作業モードを目的としているため、方法論を実践する人は、単一のツールではなく、「ツールチェーン」と呼ばれるさまざまなツールのセットを使用します。[17]これらのツールチェーンは、開発および配信プロセスの重要な側面を反映して、次の1つ以上のカテゴリに適合することが期待されています。

  1. コーディング–コードの開発とレビュー、ソースコード管理ツール、コードのマージ。
  2. ビルド–継続的インテグレーションツール、ビルドステータス。
  3. テスト–ビジネスリスクに関する迅速かつタイムリーなフィードバックを提供する継続的テストツール。
  4. パッケージング–アーティファクトリポジトリ、アプリケーションの展開前のステージング。
  5. リリース–変更管理、リリース承認、リリース自動化
  6. 構成–インフラストラクチャの構成と管理、コードツールとしてのインフラストラクチャ。
  7. 監視–アプリケーションのパフォーマンス監視、エンドユーザーエクスペリエンス。

他のアプローチとの関係

DevOpsプラクティスの基本となるアイデアの多くは、リーン生産方式とデミング方式の Plan-Do-Check-Actサイクルから、Toyota Wayコンポーネントとバッチサイズを分解するアジャイルアプローチに至るまで、他のよく知られたプラクティスに触発されています。[18] 1990年代のITILの「トップダウン」の規範的アプローチと厳格なフレームワークとは対照的に、DevOpsは「ボトムアップ」であり、ソフトウェアエンジニアのニーズを念頭に置いてソフトウェアエンジニアによって作成された柔軟なプラクティスです。[19]

アジャイル

現代のDevOpsと、自動ビルドとテスト、継続的インテグレーション継続的デリバリーなどのいくつかの標準的なDevOpsプラクティスの動機は、(非公式に)1990年代、正式には2001年にさかのぼるアジャイルの世界に端を発しています。Extreme Programmingなどの方法では、アプリケーションに関連する運用/インフラストラクチャの責任を包含しない限り、「価値のあるソフトウェアを早期かつ継続的に提供することで顧客を満足させる」ことはできません。その多くは自動化されていますスクラムだから2000年代初頭に主要なアジャイルフレームワークとして登場し、多くのアジャイルチームの一部であったエンジニアリング手法を省略しました。これは、アジャイルから分離され、最新のDevOpsに拡張された運用/インフラストラクチャ機能を自動化する動きです。今日、DevOpsは、アジャイルまたは他の方法論を介して開発されているかどうかにかかわらず、開発されたソフトウェアの展開に焦点を合わせています。

ArchOps

ArchOpsは、運用展開のために、ソースコードではなく、ソフトウェアアーキテクチャアーティファクトから開始する、DevOpsプラクティスの拡張機能を提供します。[21] ArchOpsは、アーキテクチャモデルは、ソフトウェアの開発、展開、および運用における一流のエンティティであると述べています。

CI / CD

自動化はDevOpsの成功を達成するためのコア原則であり、CI / CDは重要なコンポーネントです。[22]

CI / CDは、継続的インテグレーション(CI)と継続的デリバリー(CD)、または継続的デプロイメント(CD)で構成されます。3つのプロセスを一緒に使用すると、ビルド、テスト、デプロイが自動化されるため、DevOpsチームはコードの変更をより迅速かつ確実に送信できます。CI / CDを指す場合、参照される「CD」は通常、継続的展開ではなく継続的デリバリーです。継続的デリバリーおよびその他のCI / CDプロセスは、ソフトウェアデリバリータスクの自動化に重点を置いていますが、DevOpsは、関連する多くの機能間の優れたコラボレーションをサポートするための組織変更にも重点を置いています。どちらもアジャイル手法リーン思考の共通の背景を共有しています、エンドカスタマーに焦点を当てた価値のある小規模で頻繁な変更を優先します。これにより、2つのことが保証されます。ソフトウェアはライフサイクル全体を通じて常にリリース可能な状態にあるため、ソフトウェアの提供がより安価でリスクが低くなります。

さらに、チーム間およびチーム内のコラボレーションとコミュニケーションの改善により、リスクを軽減しながら、市場投入までの時間を短縮できます。[23]

DataOps

データ分析への継続的デリバリーとDevOpsの適用は、DataOpsと呼ばれています。DataOpsは、データエンジニアリング、データ統合、データ品質、データセキュリティ、およびデータプライバシーを運用と統合することを目指しています。リーン生産方式で使用されるDevOps、アジャイル開発統計的プロセス制御の原則を適用して、データ分析から価値を抽出するサイクルタイムを改善します。

サイト信頼性エンジニアリング

2003年、Googleサイト信頼性エンジニアリング(SRE)を開発しました。これは、高品質のエンドユーザーエクスペリエンスを維持しながら、新機能を大規模な高可用性システムに継続的にリリースするためのアプローチです。[24] SREはDevOpsの開発よりも前から存在しますが、一般的には相互に関連していると見なされています。

トヨタ生産方式、リーンシンキング、カイゼン

頭字語TPSで知られるトヨタ生産方式は、継続的改善、改善、フロー、および小ロットに焦点を当てたリーンシンキングのインスピレーションでした。迅速なフィードバックを作成し、群れを作り、問題を解決するためのアンドンコードの原則は、TPSに由来します。[25] [26]

DevSecOps、セキュリティを左にシフト

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

静的アプリケーションセキュリティテスト(SAST)を介してコードを静的にチェックすることは、セキュリティに特に重点を置いたホワイトボックステストです。プログラミング言語に応じて、このような静的コード分析を行うにはさまざまなツールが必要です。ソフトウェア構成が分析され、特にライブラリとそのバージョンが、 CERTおよびその他の専門家グループによって公開された脆弱性リストと照合されます。クライアントにソフトウェアを提供する場合、ライセンスと、配布されているソフトウェアの1つとの一致、特にコピーレフトライセンスに焦点が当てられます。動的テストは、ブラックボックステストとも呼ばれます。ソフトウェアは、その内部機能を知らなくてもテストされます。DevSecOpsでは、一方で動的に呼び出されます(DAST)、または侵入テスト。目標は、とりわけ、クロスサイトスクリプティングSQLインジェクションなどのエラーを早期に発見することです。脅威の種類は、たとえば、TOP10などのオープンWebアプリケーションセキュリティプロジェクトによって公開されます。[27]一方、特にマイクロサービスのインタラクティブアプリケーションテスト(IAST)は、自動機能テストの実行時に実行されるコードを確認するのに役立ちます。焦点は、アプリケーション内の脆弱性を検出することです。SASTおよびDASTとは異なり、IASTはアプリケーション内で機能します。

IASTと非常によく似ており、ランタイムアプリケーション自己保護(RASP)はアプリケーション内で実行されます。そのインストルメンテーションは、テストサイクルではなく、生産的な実行時に攻撃を検出することに重点を置いています。攻撃は、監視とアラートを介して報告するか、積極的にブロックすることができます。RASPアラートは、セキュリティ情報とイベント管理(SIEM)に役立ちます。

文化の変化

DevOpsイニシアチブは、開発および提供プロセス中に運用開発者、およびテスターがコラボレーションする方法を変革することにより、企業に文化的変化をもたらすことができます[28] 。[1]これらのグループを連携して機能させることは、エンタープライズDevOpsの採用における重要な課題です。[29] [30] DevOpsは、ツールチェーンに関するものであると同時に、文化に関するものでもあります。[31]

DevOpsカルチャーの構築

組織文化は、ITと組織のパフォーマンスの強力な予測因子です。情報の流れ、コラボレーション、責任の共有、失敗からの学習、新しいアイデアなどの文化的慣行は、DevOpsの中心です。チームビルディングやその他の従業員エンゲージメント活動は、組織内でこのコミュニケーションと文化的変化を促進する環境を作り出すためによく使用されます。サービスとしてのDevOpsアプローチにより、開発者と運用チームは、速度を妨げることなく、アプリケーションとインフラストラクチャをより細かく制御できます。また、問題を所有する責任を開発チームに移し、開発チームの歩みをより慎重にします。

2015年のStateof DevOps Reportは、組織文化と最も強い相関関係がある上位7つの指標が次のとおりであることを発見しました。

  1. 組織投資
  2. チームリーダーの経験と有効性
  3. 継続的デリバリー
  4. Win-Winの結果を達成するためのさまざまな分野(開発、運用、およびinfosec)の能力
  5. 組織の業績
  6. 導入の苦痛
  7. リーン管理の実践

展開

リリースが非常に頻繁な企業では、DevOpsに関する知識が必要になる場合があります。[要出典]たとえば、画像ホスティングWebサイトFlickrを運営している会社は、1日に10回の展開をサポートするDevOpsアプローチを開発しました。マルチフォーカスまたはマルチ機能のアプリケーションを作成している組織では、毎日の展開サイクルがはるかに長くなります。[要出典]毎日の展開は継続的展開と呼ばれます

アーキテクチャ上重要な要件

DevOpsを効果的に実践するには、ソフトウェアアプリケーションは、展開可能性、変更可能性、テスト可能性、監視可能性など、 アーキテクチャ上重要な一連の要件(ASR)を満たす必要があります。

マイクロサービス

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

DevOps自動化

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

バージョン管理による自動化

多くの組織は、バージョン管理を使用して、仮想マシン、コンテナ化(またはOSレベルの仮想化)、CI / CDなどのDevOps自動化テクノロジーを強化しています論文DevOps:バンキングドメインでのツールチェーンの開発では、開発者のチームが同じプロジェクトに取り組んでいる場合、「すべての開発者は同じコードベースに変更を加え、場合によっては同じファイルを編集する必要があります。効率的に作業するには、エンジニアが競合を回避し、コードベースの履歴を保持するのに役立つシステムであること」[34]、例として参照されているGitバージョン制御システムとGitHubプラットフォームを使用します。

採用

DevOpsの実践と採用

DevOpsプラクティスとその依存関係には、潜在的なメリットを実践の順序付けられたチェーンに接続する依存関係ネットワークが含まれます。このネットワークを使用して、組織は目標の達成を可能にするパスを選択できます。

DevOpsの採用は、次のような多くの要因によって推進されています。

  1. アジャイルおよびその他の開発プロセスと方法の使用。
  2. アプリケーションおよびビジネスユニットの利害関係者からの本番リリースの増加率に対する要求
  3. 内部および外部プロバイダーからの仮想化およびクラウドインフラストラクチャの幅広い可用性。
  4. データセンターの自動化および構成管理ツールの使用の増加。
  5. テスト自動化継続的インテグレーション手法への注目が高まっています。
  6. 公開されているベストプラクティスのクリティカルマス。

も参照してください

メモ

  1. ^ Dycket。al(2015)「私たちの知る限り、リリースエンジニアリングとDevOpsという用語の統一された定義はありません。その結果、多くの人が独自の定義を使用したり、他の人に依存したりして、これらの用語について混乱を招きます。」[2]
  2. ^ Jabbariet。al(2016)「この調査の調査結果は、個々の調査が一貫してDevOpsを定義していないため、定義の必要性を示しました。」[3]
  3. ^ Erichet。al(2017)「DevOpsの研究にはさまざまなギャップがあることに気づきました。DevOpsがカバーする概念やDevOpsの定義方法についてのコンセンサスはありません。」[4]
  4. ^ Erichet。al(2017)「学術文献におけるDevOpsの特性についてはほとんど合意がないことを発見しました。」[4]

参考文献

  1. ^ a b Loukides、マイク(2012年6月7日)。「DevOpsとは何ですか?」オライリーメディア
  2. ^ Dyck、Andrej; ペナーズ、ラルフ; リヒター、ホルスト(2015年5月19日)。「リリースエンジニアリングとDevOpsの定義に向けて」。リリースエンジニアリングに関する2015IEEE / ACM第3回国際ワークショップの議事録IEEE: 3。doi 10.1109 /RELENG.2015.10ISBN 978-1-4673-7070-7S2CID4659735 _
  3. ^ Jabbari、Ramtin; ビンアリ、ナウマン; ピーターセン、カイ; タンビア、ビニッシュ(2016年5月)。「DevOpsとは何ですか?:定義と実践に関する体系的なマッピング研究」。2016年科学ワークショップの議事録コンピューティングマシナリー協会
  4. ^ a b Erich、FMA; アムリット、C。; Daneva、M。(2017年6月)。「実際のDevOps使用法の定性的研究」。Journal of Software:Evolution andProcess29(6):e1885。土井10.1002 /smr.1885S2CID35914007_ 
  5. ^ バス、レン; ウェーバー、インゴ; 朱、石灰(2015)。DevOps:ソフトウェアアーキテクトの視点ISBN 978-0134049847
  6. ^ ムニョス、ミルナ; マリオのネグレテ・ロドリゲス(2021年4月)。「組織でDevOpsアプローチを実装または強化するためのガイダンス:ケーススタディ」。 {{cite journal}}: Cite journal requires |journal= (help)
  7. ^ Chapman、M.、Gatti、N:サービスライフサイクルのモデル、Proceedings of TINA '93、pp。I-205–I-215、1993年9月。
  8. ^ Mezak、Steve(2018年1月25日)。「DevOpsの起源:名前には何が含まれていますか?」devops.com 2019年5月6日取得
  9. ^ デボア、パトリック。「アジャイル2008トロント」十分な文書化された情報2015年3月12日取得
  10. ^ デボア、パトリック。「DevOpsDays」DevOpsDays 2011年3月31日取得
  11. ^ ab アラナ ブラウン; ニコールフォースグレン; ジェズハンブル; Nigel Kersten; ジーン・キム(2016)。「2016年のDevOpsレポートの状態」(PDF)Puppet Labs、DORA(DevOpsResearch 。 2019年5月6日取得
  12. ^ 「人形-アラナブラウン」PuppetLabs 2019年4月27日取得
  13. ^ ニコールフォースグレン; ジーン・キム; Nigel Kersten; ジェズハンブル(2014)。「2014Stateof DevOps Report」(PDF)Puppet Labs、IT Revolution Press、ThoughtWorks 2019年4月27日取得
  14. ^ 「2015年のDevOpsレポートの状態」(PDF)Puppet Labs、Pwc、ITレボリューションプレス。2015 2019年5月6日取得
  15. ^ 「よりアジャイルなテスト」(PDF)2014年10月2019年5月6日取得
  16. ^ クリスピン、リサ; グレゴリー、ジャネット(2014年10月)。よりアジャイルなテストISBN 97801337495712019年5月6日取得
  17. ^ Gartnerの市場動向:DevOps –市場ではなく、継続的デリバリーのバリューチェーンをサポートするツール中心の哲学(レポート)。ガートナー。2015年2月18日。
  18. ^ Klein、Brandon Thorin(2021年5月1日)。「DevOps:DevOpsの哲学と科学への簡潔な理解」土井10.2172 / 1785164OSTI1785164_ S2CID236606284_   {{cite journal}}: Cite journal requires |journal= (help)
  19. ^ 「DevOpsの歴史と進化| TomGeraghty」2020年11月29日取得
  20. ^ 「アジャイルマニフェストの背後にある原則」agilemanifesto.org 2020年12月6日取得
  21. ^ Castellanos、Camilo; コーリアル、ダリオ(2018年9月15日)。ビッグデータ分析のためのアーキテクチャモデルの実行コンピュータサイエンスの講義ノート11048. pp。364–371。土井10.1007 / 978-3-030-00761-4_24ISBN 978-3-030-00760-7
  22. ^ 謙虚、ジェズ; ファーリー、デビッド(2011)。継続的デリバリー:ビルド、テスト、および展開の自動化による信頼性の高いソフトウェアリリースPearson Education Inc. ISBN 978-0-321-60191-9
  23. ^ Chen、Lianping(2015)。「継続的デリバリー:大きなメリットがありますが、課題もあります」。IEEEソフトウェア32(2):50–54。土井10.1109 /MS.2015.27S2CID1241241_ 
  24. ^ Beyer、Betsy; ジョーンズ、クリス; ペトフ、ジェニファー; マーフィー、ニール・リチャード(2016年4月)。サイト信頼性エンジニアリングオライリーメディア。ISBN 978-1-4919-2909-4
  25. ^ DevOpsのDNAの分析、Brent Aaron Reed、Willy Schaub、2018-11-14。
  26. ^ DevOpsハンドブック:テクノロジー組織で世界クラスの俊敏性、信頼性、セキュリティを作成する方法、Gene Kim、Patrick Debois、John Willis、Jezz Humble、2016年
  27. ^ OWASP TOP10、オープンWebアプリケーションセキュリティプロジェクト、2021-11-25にアクセス。
  28. ^ エマージングテクノロジー分析:DevOpsはテクノロジーではなく文化の変化(レポート)。ガートナー。
  29. ^ 「GartnerIT用語集–devops」ガートナー2015年10月30日取得
  30. ^ ジョーンズ、スティーブン; ノッペン、ジョースト; レティック、フィオナ(2016年7月21日)。品質を意識した開発オペレーションに関する第2回国際ワークショップの議事録-QUDOS2016 (PDF)pp。7–11。土井10.1145 /2945408.2945410ISBN  9781450344111S2CID515140 _
  31. ^ マンディウォール(2015年9月25日)。「DevOpsカルチャーの構築」オライリー。
  32. ^ チェン、リアンピン; アリババール、ムハンマド(2014)。「アジャイルソフトウェア開発における継続的なリファクタリングによるアーキテクチャの出現の証拠に基づく理解に向けて」。ソフトウェアアーキテクチャに関する第11回IEEE / IFIP会議(WICSA 2014)IEEE。土井10.1109 /WICSA.2014.45
  33. ^ Teja Yarlagadda、Ravi(2021年3月9日)。「DevOpsとその実践」。SSRN3798877_ 
  34. ^ モリシオ、マウリツィオ(2021年4月16日)。DevOps:銀行ドメインでのツールチェーンの開発Politecnico di Torino(ラウレア)2021年8月16日取得

さらに読む

  • デイビス、ジェニファー; ダニエルズ、リン(2016年5月30日)。効果的なDevOps:コラボレーション、アフィニティ、ツールの文化を大規模に構築します。セバストポル、カリフォルニア州:オライリー。ISBN 9781491926437OCLC951434424 _
  • キム、ジーン; デボア、パトリック; ウィリス、ジョン; 謙虚、ジェズ; オールスパウ、ジョン(2015年10月7日)。DevOpsハンドブック:テクノロジー組織で世界クラスの俊敏性、信頼性、セキュリティを作成する方法(初版)。オレゴン州ポートランド。ISBN 9781942788003OCLC907166314 _
  • フォースグレン、ニコール; 謙虚、ジェズ; キム、ジーン(2018年3月27日)。加速:リーンソフトウェアとDevOpsの科学:高性能テクノロジー組織の構築とスケーリング(初版)。ITレボリューションプレス。ISBN 9781942788331