継続的インテグレーションと継続的デリバリーと継続的デプロイメント
これら3つの用語の違いは何ですか？私の大学は以下の定義を提供しています：
継続的インテグレーション 基本的には開発者の作業コピーが1日に数回共有メインラインと同期されることを意味します。
継続的納入 は継続的統合の論理的進化として説明されています。常に製品を生産に投入することができます。
継続的導入 は継続的配信後の論理的な次のステップとして説明されています。
また、警告が表示されます。テストシステムに継続的に展開できる場合は、 "継続的展開"という用語も使用されることがあります。
これらすべてが私を混乱させます。もう少し詳細な（または例が付いている）説明は大歓迎です！
質問も答えもどちらも私の単純な考え方には合いません。私はコンサルタントであり、これらの定義を多数の開発チームやDevOpsの人々と同期させていますが、業界全体とどのように一致するのかについて興味があります。
基本的に、私は連続配信のアジャイルプラクティスを連続体のように考えます。
継続的ではない（すべて手動）0％----> 100％継続的な価値の提供（すべて自動化）
連続配達へのステップ：
ゼロ。開発者がコードをチェックインするときに自動化されるものは何もありません...チェックイン前にテストをコンパイル、実行、または実行したことがあるのはラッキーです。
連続ビルド： チェックインごとに自動ビルド。これは最初のステップですが、新しいコードの機能統合を証明するものではありません。
継続的インテグレーション（CI）： 既存のコードと新しいコードのインテグレーションを証明するための少なくとも単体テストの自動ビルドと実行。ただし、インテグレーションテスト（エンドツーエンド）が望ましいです。
Continuous Deployment（CD）： CIでテストする場合、または手動テストの後で品質が低い環境をPASSEDとしてマークすることによって品質が証明される場合はコードをCIに渡すときの自動配置。 I.E.、テストは手動で行われる場合もありますが、次の環境への昇格は自動的に行われます。
継続的配達： 自動化されたシステムの本番へのリリース。これは製品版のCDに加えて、A/Bテストのためのセットアップ、新機能のユーザへの通知、新バージョンのサポートの通知、変更ノートなどのようなその他の設定変更です。
編集：私はアジャイルマニフェストの最初の原則（ http://agilemanifesto.org/principles.html ）で言及されている「連続配信」の概念と実践の間に違いがあることを指摘したいと思います。質問の文脈で参照されるように、連続配達の。連続配達の原則は、無駄のない思考（ http://www.miconleansixsigma.com/8-wastes.html ）に記載されているように、在庫廃棄物の削減に努めることの原則です。アジャイルチームによるContinuous Delivery（CD）の実践は、2001年にアジャイルマニフェストが作成されて以来、長年にわたって登場してきました。このアジャイル実践は、原則が直接異なるため、明らかに混乱しています。
私はAmazonの定義を理解するのは簡単で簡単だと思います。
"連続配信は、リリースプロセスが自動化されたソフトウェア開発方法論です。ソフトウェアの変更はすべて自動的に構築され、テストされ、運用環境に展開されます。ビジネスルールによって、最終的なプッシュをいつ実行するかが決定されます。
継続的インテグレーションは、チームのメンバーがバージョン管理システムを使用して、マスターブランチなどの同じ場所に頻繁に作業を統合するソフトウェア開発方法です。各変更は、統合エラーをできる限り迅速に検出するために、テストおよびその他の検証によって構築および検証されています。 継続的な統合は、ソフトウェアのリリースプロセス全体を本番まで自動化する継続的な配信と比較して、コードの自動構築とテストに重点を置いています "
http://docs.aws.Amazon.com/codepipeline/latest/userguide/concepts.html をチェックしてください。
アトラシアンは、 継続的インテグレーションvs.継続的デリバリーvs継続的デプロイメントについての良い説明を投稿しました 。
手短に：
継続的インテグレーション - は新しいコミットがブランチにプッシュされるたびにアプリケーションを構築しテストするための自動化です。
連続配信 - は継続的統合 + 「ボタンをクリックする」ことによってアプリケーションをプロダクションにデプロイします（顧客へのリリースはよくありますが、要求に応じて）。
継続的展開 - は継続配信ですが、人手を介さずに（顧客へのリリースが進行中です）。
継続的インテグレーションは基本的には開発者の作業コピーが1日に数回共有メインラインと同期されることを意味します。
または一日に数回以上。基本的には、与えられた任意の個別のタスクが完了するのと同じくらい頻繁に。たとえば、単一のビジネスアプリケーションで作業している開発者のチームを考えてみましょう。多くの環境では、次のことが起こります。
- 「まだ準備ができていない」ので、1人か2人の開発者が数日間ローカルの変更を続けます。
- 1人か2人の開発者がソース管理でブランチを作成して、彼らが「他の人の変更に悩まされることなく」自分たちの機能に取り組むことができるようにします。
これらは問題を引き起こす可能性があります。貧弱なコード/タスク編成は分岐につながり、分岐はマージにつながり、マージします...苦しみにつながります。実践としての継続的統合は、全員が同じ共有ソースから作業することを奨励することによってこれに対処します。個々の作業項目は、短時間（最大で数時間）で完了するのに十分な程度に離散している必要があります。
基本的な考え方は、小さな変更を小さな作業に統合するというものです。大きな変更を統合するのは、非常に大きな作業です。統合作業の総計は、一定の小さなステップで行われると小さくなります。これにより、開発者は開発プロセスのオーバーヘッドではなく、ビジネスに見える機能に多くの時間を費やすことができます。
Continuous Deliveryは、継続的統合の論理的進化として説明されています。常に製品を生産に投入できるようにすること。
これは、個別の明確に定義された作業項目の同じ考え方に従います。完全にテストされた既知の作業機能によって少しずつ調整されるマスターコードベースが1つしかない場合、そのコードベースは常に安定しています。自動テストは、ボタンを押すだけでその安定性を証明できるという点で重要です。
実行する必要がある安定化作業が少なければ少ないほど（これもまた開発プロセスのオーバーヘッドであり、排除する必要があります）、コードベースを任意の特定の環境にプッシュできることが多くなります。多くの企業では、展開は非常に困難なプロセスになる可能性があります。 1週間の実戦でも可能です。これは高価であり、ビジネス上の価値はありません。優れた作業項目定義、効果的な自動テスト、および継続的な統合を採用することで、チームは特定の環境へのコードベースの配信を自動化することができます。
継続的導入は、継続的納入後の論理的な次のステップとして説明されています。
あなたはめったにこれがビジネス環境で起こるのを見ないでしょう、そしてそれが遭遇したときそれはかなりの喜びです。コードベースが自動的にテストされ、特定の環境に自動的にデプロイされるのであれば、本番環境は他の環境と同じです。そのため、チームがこの時点までにビルドアップしていれば、常に更新をプロダクションに展開することができるため、ビジネスに大きな価値がある可能性があります。
不具合修正はより早く顧客に送られ、新機能はより早く市場に届き、新しいアイデアは優先度のリダイレクトなどを可能にするために少しずつ市場に対してテストされます。
たとえば、ある会社がソフトウェアベースの製品やサービスの新機能について大きなアイデアを持っているとしましょう。彼らはいくつかの研究を行ってきました、彼らは市場を知っています、そして彼らはこの考えが強い新たな収益のラインをもたらすと信じています。その機能を提供するための2つのオプションを考えてみましょう。
- 一回限りのブランチで全部を開発するのに数ヶ月を費やしてください。それをメインのコードベースに統合するのに何週間もかけてください。それをテストする日を過ごしてください。それを展開する一日を過ごします。そして その後 生産システムの実際の収益を追跡し始めます。
- 機能の小さな部分を一度に1つずつ実装します。毎週それの新しい部分をリリースします。毎週実際の収入に関するより多くのデータを得ます。
最初のシナリオでは、機能が望ましい市場効果を持たない場合、顧客は実際には望んでいないものに 多くの - お金が浪費されます。 2番目のシナリオでは、顧客がそれを望んでいないという事実がはるかに早く決定され、残りの作業は優先順位が低くなります。
最終的にこれらの「継続的なこと」はすべて開発プロセスのオーバーヘッドを取り除くことに関するものです。会社の収益のラインが特定のサービス提供であるならば、理想的には彼らのコストの全てがその提供に入るべきです。開発プロセスのオーバーヘッド（コードのマージ、マージ後の同じ機能の再テスト、手動展開タスクなど）は実際にはサービスの価値には寄与しないため、これらの概念はプロセスからこれらのコストを排除しようとします。
1つのグラフで多くの単語を置き換えることができます。
楽しい！ :-)
＃正しい画像を更新しました...
継続的インテグレーション、継続的デリバリー、および継続的導入の違い
私たちは分析し過ぎて「連続的な」一連の単語を多少複雑にしていると思います。これに関連して、連続とは自動化を意味します。 "continuous"に付いている他の単語は翻訳ガイドとして英語を使ってください。事を複雑にしないでください！ "継続的ビルド"では、アプリケーションを特定のプラットフォーム/コンテナ/ランタイム/ etc用に実行可能なものに自動的にビルド（書き込み/コンパイル/リンク/ etc）します。 「継続的統合」とは、新しい機能が他のエンティティと対話するときに意図したとおりにテストおよび実行されることを意味します。明らかに、統合が行われる前に、ビルドが行われなければならず、徹底的なテストも統合を検証するために使用されるでしょう。したがって、「継続的統合」では、既存の機能を悪影響を与えずに全体的に知覚される値を追加しながら、既存の機能に価値を追加するために自動化を使用します。統合は、その単なる英語の定義では、物事が調和して活気を帯びていることを意味しているので、コード・トークで私の追加コンパイル、リンク、テスト、そして完全に実行されます。それが最終製品に合格しなかった場合、統合されたものとは呼ばないでしょうか。私たちの文脈では、「継続的な展開」は「継続的な配信」と同義です。それは、一日の終わりに私たちが顧客に機能を提供してきたからです。しかし、これを過度に分析することによって、何かを展開することが必ずしも私たちが配信したことを意味するわけではないので、deployは配信のサブセットであると私は主張できます。私たちはコードをデプロイしましたが、私たちはステークホルダーと効果的にコミュニケーションを取っていないので、ビジネスの観点から提供することができませんでした！私たちは軍を配備しましたが、約束された水と食料を近くの町に届けていません。 「継続的移行」という言葉を追加するとしたら、それ自体にメリットがありますか。結局のところ、環境を通じたコードの移動を記述するのに適しているのかもしれません。永続的に1つの場所だけを意味する可能性があるデプロイメントや配信よりも「from/to」の意味があるからです。私たちが常識を適用しないならば、これは私たちが得るものです。
結論として、これは説明するのが簡単なことです（それを行うのはもう少し複雑です！）。常識を使用して、英語を使用すれば大丈夫です。
継続的インテグレーション： コードをできる限り頻繁にテストして問題を早期に発見できるように、開発作業とメインブランチを常にマージするという慣習。
継続的配信： コードの出荷準備が整ったら、環境へのコードの継続的配信。これはステージングまたはプロダクションの可能性があります。アイデアは、製品がユーザーベースに配信されることです。ユーザーベースは、レビューや検査のためにQAや顧客になることができます。
継続的インテグレーション段階での単体テストでは、すべてのバグやビジネスロジック、特にQAが必要な設計上の問題、またはテストのためのステージング環境を把握できません。
継続的な展開： 準備ができ次第コードの展開またはリリースを行います。継続的導入には継続的統合と継続的デリバリーが必要です。そうしないと、リリースでコードの品質が保証されません。
継続的な展開~~継続的な統合+継続的な配信
継続的統合
- 自動化（チェックインの構築+単体テスト）
連続配信
- 継続的統合
- 自動化（テスト環境への展開+負荷テスト+統合テスト）
- 手動（運用環境への展開）
連続展開
- 継続的配信、自動化（本番への展開）
CI/CDは旅です。宛先ではありません。
これらの段階は提案です。ビジネスニーズに基づいてステージを調整できます。複数のタイプのテスト、セキュリティ、およびパフォーマンスのために、いくつかの段階を繰り返すことができます。プロジェクトの複雑さとチームの構造に応じて、いくつかの段階を異なるレベルで数回繰り返すことができます。たとえば、あるチームの最終製品が次のチームのプロジェクトの依存関係になる可能性があります。これは、最初のチームの最終製品が、次のチームのプロジェクトの成果物としてその後ステージングされることを意味します。
脚注：
DevOpsは3Cの - 継続的な 、 コミュニケーション 、 コラボレーション の組み合わせであり、これがさまざまな業界での主な焦点となります。
IoTに接続されたデバイスの世界では、製品の所有者、Web、モバイル、QAなどの複数のスクラム機能がスクラムのスクラムサイクルでアジャイルな方法で機能し、製品をエンドユーザーに提供します。
継続的インテグレーション： 複数のエンドポイントで同時に機能する複数のスクラム機能
継続的配達： 統合と展開により、同時に取り扱う複数の顧客への商品配達。
継続的な展開： 複数のプラットフォームで複数の顧客に展開されている複数の製品。
DevOpsがどのようにIoT接続世界を可能にするか知るためにこれを見てください： https://youtu.be/nAfZt2t4HqA