継続的デリバリー

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

継続的デリバリーCD)は、チームが短いサイクルでソフトウェアを作成するソフトウェアエンジニアリングのアプローチであり、ソフトウェアをいつでも確実にリリースでき、ソフトウェアをリリースするときに手動でリリースする必要はありません。[1] [2]これは、より高速で頻繁なソフトウェアの構築、テスト、およびリリースを目的としています。このアプローチは、本番環境のアプリケーションに対してより段階的な更新を可能にすることで、変更を提供するコスト、時間、およびリスクを削減するのに役立ちます。継続的デリバリーには、単純で反復可能な展開プロセスが重要です。

CDは、継続的展開とは対照的です。これは、ソフトウェアも短いサイクルで作成されますが、手動展開ではなく 自動展開によって作成される同様のアプローチです。

DevOpsとの関係

継続的デリバリーとDevOpsは意味が似ており、しばしば混同されますが、2つの異なる概念です。[3] DevOpsはより広い範囲を持ち、[4]文化の変化、特にソフトウェア配信に関与するさまざまなチーム(開発者、運用、品質保証、管理など)のコラボレーション、およびプロセスの自動化を中心としています。ソフトウェア配信で。[4]一方、継続的デリバリーは、デリバリーの側面を自動化するアプローチであり、さまざまなプロセスをまとめて、より迅速かつ頻繁に実行することに重点を置いています。[5]したがって、DevOpsは継続的デリバリーの製品であり、CDはDevOpsに直接流れ込みます。

継続展開との関係

継続的デリバリーとは、手動リリースを通じていつでも展開できるソフトウェアをデリバリーする機能です。これは、自動展開を使用する継続的展開とは対照的です。[6] Martin Fowlerによると、継続的展開には継続的デリバリーが必要です。[7]学術文献は、展開方法に応じて2つのアプローチを区別しています。手動と自動。[2] [8]

原則

継続的デリバリープロセスdiagram.svg

継続的デリバリーは、デプロイメントパイプラインのありふれた概念[9]無駄 のないポカヨケとして扱います:[10]ソフトウェアの一部がリリースに至るまでに通過しなければならない一連の検証コードは必要に応じてコンパイルされ、変更がソース管理リポジトリにコミットされるたびにビルドサーバーによってパッケージ化され、リリース可能としてマークされる前に、さまざまな手法(手動テストを含む)でテストされます。

長いサイクルタイムに慣れている開発者は、CD環境で作業するときに考え方を変える必要があるかもしれません。コードコミットはいつでも顧客にリリースされる可能性があることを理解することが重要です。フィーチャートグルなどのパターンは、エンドユーザーがまだ使用できる状態になっていないコードを早期にコミットする場合に非常に役立ちます。NoSQLを使用すると、データ移行やスキーマ変更のステップ、多くの場合、継続的デリバリーワークフローの手動ステップや例外を排除できます。[11]コード​​の分岐など、コードを分離して開発するためのその他の便利な手法CDの世界では時代遅れではありませんが、CDの原則に合うように調整する必要があります。たとえば、リリース可能なアーティファクトは単一のコードブランチからCDプロセスの早い段階で構築する必要があるため、複数の長寿命のコードブランチを実行することは実用的ではありません。パイプラインのすべてのフェーズを通過する場合。[説明が必要]

デプロイメントパイプライン

継続的デリバリーは、デプロイメントパイプラインを通じて有効になります。デプロイメントパイプラインの目的には、可視性、フィードバック、および継続的なデプロイの3つのコンポーネントがあります。[12]

  • 可視性–コラボレーションを促進するために、構築、展開、テスト、リリースを含む配信システムのすべての側面がチームのすべてのメンバーに表示されます。
  • フィードバック–チームメンバーは、問題が発生したときにできるだけ早く問題を学習して、問題をできるだけ早く修正できるようにします。
  • 継続的な展開–完全に自動化されたプロセスを通じて、任意のバージョンのソフトウェアを任意の環境に展開およびリリースできます。

ツール/ツールタイプ

継続的デリバリーは、ソース管理から本番環境に至るまでの自動化を実現します。このプロセスの全部または一部を実行するのに役立つさまざまなツールがあります。[13]これらのツールは、継続的デリバリーを含むデプロイメントパイプラインの一部です。プロセスのさまざまな部分を実行するツールの種類には、継続的インテグレーションアプリケーションリリースの自動化ビルドの自動化アプリケーションのライフサイクル管理が含まれます。[14]

継続的デリバリーのための設計

継続的デリバリーを効果的に実践するには、ソフトウェアアプリケーションは、展開可能性、変更可能性、テスト可能性など、アーキテクチャ上重要な一連の要件(ASR)を満たす必要があります。[15]これらのASRは高い優先度を必要とし、軽くトレードオフすることはできません。

マイクロサービスは、継続的デリバリーを設計するときによく使用されます。[16]マイクロサービスを使用すると、ソフトウェアシステムの展開性と変更性を高めることができます。観察された展開性の改善には、展開の独立性、展開時間の短縮、展開手順の簡素化、およびダウンタイムのない展開が含まれます。観察された変更可能性の改善には、小さな増分機能変更のサイクルタイムの短縮、テクノロジ選択の変更の容易さ、品質属性の増分変更、および言語とライブラリのアップグレードの容易さが含まれます。[16]

実装と使用法

JezHumbleとDavidFarley(2010)によって書かれたCDブックはこの用語を広めましたが、その作成以来、定義は進歩し続け、今ではより発展した意味を持っています。今日の企業は、これらの継続的デリバリーの原則とベストプラクティスを実装しています。ドメインの違い、たとえば医療とWebは依然として重要であり、実装と使用法に影響を与えます。[17]このアプローチを採用している有名企業には、Yahoo![18] Amazon[19] Facebook[20] Google[21] Paddy Power [1]WellsFargo[22]

メリットと障害

継続的デリバリーのいくつかの利点が報告されています。[1] [17]

  • 市場投入までの時間の短縮:CDを使用すると、組織は新しいソフトウェアリリースに固有のビジネス価値をより迅速に顧客に提供できます。この機能は、会社が競争の一歩先を行くのに役立ちます。
  • 適切な製品の構築:頻繁なリリースにより、アプリケーション開発チームはユーザーフィードバックをより迅速に取得できます。これにより、便利な機能のみに取り組むことができます。機能が役に立たないことに気付いた場合、彼らはそれ以上の努力をしません。これは、彼らが適切な製品を構築するのに役立ちます。
  • 生産性と効率の向上:自動化により、開発者、テスター、運用エンジニアなどの時間を大幅に節約できます。
  • 信頼性の高いリリース:リリースに関連するリスクが大幅に減少し、リリースプロセスの信頼性が向上しました。CDを使用すると、本番環境に展開する前に、展開プロセスとスクリプトが繰り返しテストされます。そのため、展開プロセスとスクリプトのほとんどのエラーはすでに発見されています。より頻繁なリリースでは、各リリースでのコード変更の数は減少します。これにより、発生した問題の検出と修正が容易になり、影響が及ぶ時間を短縮できます。
  • 製品品質の向上:未解決のバグと本番環境のインシデントの数が大幅に減少しました。
  • 顧客満足度の向上:より高いレベルの顧客満足度が達成されます。

障害物も調査されています。[17]

  • 顧客の好み:一部の顧客は、システムの継続的な更新を望んでいません。これは、運用の重要な段階で特に当てはまります。
  • ドメインの制限:電気通信や医療などの一部のドメインでは、新しいバージョンが運用フェーズに入る前に、規制により広範なテストが必要になります。
  • テスト自動化の欠如:テスト自動化の欠如は、開発者の信頼の欠如につながり、継続的デリバリーの使用を妨げる可能性があります。
  • 環境の違い:開発、テスト、および本番環境で使用される環境が異なると、検出されない問題が本番環境に滑り込む可能性があります。
  • 人間のオラクルを必要とするテスト:すべての品質属性を自動化で検証できるわけではありません。これらの属性では、ループ内に人間が必要であり、配信パイプラインの速度が低下します。

Chenは、さらに8つの養子縁組の課題を提起し、詳しく説明しました。[6]これらの課題は、組織構造、プロセス、ツール、インフラストラクチャ、レガシーシステム、CDの設計、非機能要件の継続的テスト、およびテスト実行の最適化の分野にあります。

採用の課題を克服するための戦略

継続的デリバリーの採用の課題を克服するためのいくつかの戦略が報告されています。[6]

CD採用の課題を克服するための戦略
ストラテジー 説明
鎮痛剤としてのCDの販売 CDが解決できる各利害関係者の問題点を特定し、その利害関係者に鎮痛剤としてCDを販売します。この戦略は、CDの実装に必要な幅広い利害関係者からの賛同を得るのに役立ちます。
学際的なメンバーを持つ専用チーム 専任のチームがいなければ、従業員は他のバリューストリームに取り組むように割り当てられることが多いため、進歩するのは難しい場合があります。学際的なチームは、CDの実装に必要な幅広いスキルを提供するだけでなく、関連するチームとのコミュニケーションを円滑にします。
継続的デリバリーの継続的デリバリー できるだけ早く会社に価値を提供する方法でCDの実装を整理し、徐々に、少しずつ、より多くのプロジェクトをオンボーディングし、最終的には組織全体にCDを展開します。この戦略は、その過程で具体的なメリットを可視化することにより、必要な投資を正当化するのに役立ちます。目に見えるメリットは、CDへの長く困難な旅を乗り切るために必要な、持続的な企業サポートと投資を実現するのに役立ちます。
簡単だが重要なアプリケーションから始める CDに移行する最初のいくつかのアプリケーションを選択するときは、移行が簡単であるがビジネスにとって重要なアプリケーションを選択してください。移行が容易であると、CDの利点をすばやく示すことができ、実装イニシアチブが中断されるのを防ぐことができます。ビジネスにとって重要であることは、必要なリソースを確保するのに役立ち、明確で議論の余地のない価値を示し、組織内のCDの可視性を高めます。
ビジュアルCDパイプラインスケルトン チームに、完全なCDパイプラインビューを持ちながら、まだ実装できないステージが空のビジュアルCDパイプラインスケルトンを提供します。これは、CDの考え方を構築し、CD採用の勢いを維持するのに役立ちます。パイプラインスケルトンは、チームのCDへの移行に多大な労力が必要であり、長期間にわたって考え方を変える必要がある場合に特に役立ちます。
エキスパートドロップ CDエキスパートを割り当てて、開発チームのシニアメンバーとして困難なプロジェクトに参加します。チームに専門家がいることは、チーム内からCDに移行する動機と勢いを構築するのに役立ちます。また、移行に多大な労力と長期間が必要な場合にも、勢いを維持するのに役立ちます。

も参照してください

さらに読む

  • 謙虚、ジェズ; ファーリー、デビッド(2010)。継続的デリバリー:ビルド、テスト、および展開の自動化による信頼性の高いソフトウェアリリースアディソン-ウェスリー。ISBN 978-0-321-60191-9
  • Wolff、Eberhard(2017)。継続的デリバリーの実用ガイドアディソン-ウェスリー。ISBN 978-0-134-69147-3

参考文献

  1. ^ a b c Chen、Lianping(2015)。「継続的デリバリー:大きなメリットがありますが、課題もあります」。IEEEソフトウェア32(2):50–54。土井10.1109 /MS.2015.27S2CID1241241_ 
  2. ^ a b Shahin、Mojtaba; アリババラ、ムハンマド; 朱、石灰(2017)。「継続的インテグレーション、配信、および展開:アプローチ、ツール、課題、および実践に関する系統的レビュー」。IEEEアクセス5:3909–3943。arXiv1703.07019Bibcode2017arXiv170307019S土井10.1109 /ACCESS.2017.2685629S2CID11638909_ 
  3. ^ ハモンド、ジェフリー(2011年9月9日)。「DevOpsと継続的デリバリーの関係」ForresterResearchフォレスター。
  4. ^ a b 謙虚、ジェズ; ファーリー、デビッド(2011)。継続的デリバリー:ビルド、テスト、および展開の自動化による信頼性の高いソフトウェアリリースPearson Education Inc. ISBN 978-0-321-60191-9
  5. ^ Swartout、Paul(2012)。継続的デリバリーとDevOps:クイックスタートガイドPacktPublishing。ISBN 978-1849693684
  6. ^ a b c Chen、Lianping(2017)。「継続的デリバリー:採用の課題を克服する」ジャーナルオブシステムズアンドソフトウェア128:72–86。土井10.1016 /j.jss.2017.02.013
  7. ^ 「bliki:ContinuousDelivery」martinfowler.com 2015年10月29日取得
  8. ^ Shahin、Mojtaba; ババル、モハメド・アリ; Zahedi、Mansooreh; 朱、石灰(2017)。「継続的デリバリーを超えて:継続的展開の課題の経験的調査」。2017 ACM / IEEE International Symposium on Empirical Software Engineering and Measurement(ESEM)pp。111–120。土井10.1109 /ESEM.2017.18ISBN 978-1-5090-4039-1S2CID3479812 _
  9. ^ 謙虚な、J。; 読む、C。; North、D。(2006)「展開生産ライン」。アジャイル2006(Agile'06)pp。113–118。土井10.1109 /AGILE.2006.53ISBN 0-7695-2562-8S2CID16572138 _
  10. ^ フィッツジェラルド、ブライアン(2014-06-03)。継続的なソフトウェアエンジニアリングとその先:トレンドと課題(PDF)高速連続ソフトウェア工学に関する第1回国際ワークショップニューヨーク州ニューヨーク:Association for ComputingMachinery。pp。1–9。土井10.1145 /2593812.2593813hdl10344/3896ISBN  978-1-4503-2856-22014-10-25にオリジナル (PDF)からアーカイブされました2014年10月24日取得
  11. ^ Kluge、Lars(2013年9月12日)。「KitchensurfingでのMongoDBによる継続的デプロイ」slideshare.net 2014年1月3日取得
  12. ^ Duvall、Paul(2012)。「継続的デリバリー:ソフトウェアライフサイクルのパターンとアンチパターン」(PDF)Refcardz 2015年10月9日取得
  13. ^ フィリップス、アンドリュー(2014年7月29日)。「継続的デリバリーパイプライン–ソフトウェアの開発において、それが何であり、なぜそれが非常に重要であるか」DevOps.com2015年9月28日にオリジナルからアーカイブされました2015年10月9日取得
  14. ^ Binstock、Andrew(2014年9月16日)。「継続的な配信:アジャイルサクセサー」ドブ博士のソフトウェア開発の世界サンフランシスコ:UBM。
  15. ^ Chen、Lianping(2015)。継続的デリバリーの設計に向けてソフトウェアアーキテクチャに関する第12回ワーキングIEEE / IFIP会議(WICSA 2015)カナダ、モントリオール:IEEE。土井10.1109 /WICSA.2015.23
  16. ^ a b Chen、Lianping(2018)。マイクロサービス:継続的デリバリーとDevOpsの設計ソフトウェアアーキテクチャに関するIEEE国際会議(ICSA 2018)IEEE。
  17. ^ abcLeppänen M 。; Mäkinen、S。; Pagels、M。; Eloranta、VP; Itkonen、J。; Mäntylä、MV; Männistö、T。(2015-03-01)。「継続的な展開への高速道路と田舎道」。IEEEソフトウェア32(2):64–72。土井10.1109 /MS.2015.50ISSN0740-7459_ S2CID18719684_  
  18. ^ 「Yahoo!での継続的デリバリーの実装」confreaks.tv2013年10月23日。
  19. ^ 「Velocity2011:Jon Jenkins、「VelocityCulture」" 。youtube.com2011年6月20日。
  20. ^ 「大規模での迅速なリリース」2017-08-31。
  21. ^ 謙虚な、ジェズ(2014年2月13日)。「継続的デリバリーの場合」Thoughtworks.com 2014年7月16日取得
  22. ^ jFrog(2014年12月)。「2014年-継続的インテグレーション-革命」