これら 3 つの用語の違いは何ですか? 私の大学では、次の定義を提供しています。
継続的インテグレーションとは、基本的に、開発者の作業コピーが共有メインラインと 1 日に数回同期されることを意味します。
継続的デリバリーは、継続的インテグレーションの論理的進化として説明されます。つまり、常に製品を本番環境に投入できるということです。
継続的デプロイメントは、継続的デリバリーの後の論理的な次のステップとして説明されています。つまり、製品が QA に合格するたびに、自動的に本番環境にデプロイされます。
また、次のような警告も表示されます: テスト システムに継続的にデプロイできる場合は、「継続的デプロイ」という用語も使用されることがあります。
これらすべてが私を混乱させます。もう少し詳しい説明（または例付き）があればありがたいです。
ベストアンサー1
継続的インテグレーション
あなたの大学の定義に同意します。継続的インテグレーションとは、開発者がコードを頻繁ではなく継続的にメインラインに統合する方法に関する戦略です。
これは単にバージョン管理システムにおけるブランチ戦略に過ぎないと主張するかもしれません。
これは、開発者に割り当てるタスクの規模に関係します。タスクに 4 ～ 5 人日かかると見積もられた場合、開発者はまだ何も終わっていないため、次の 4 ～ 5 日間は何も提供しようとは思わないでしょう。
つまりサイズが重要なのです:
small task = continuous integration
big task = frequent integration
理想的なタスク サイズは、1 日の作業よりも大きくありません。こうすることで、開発者は自然に 1 日に少なくとも 1 つの統合を行うことになります。
継続的デリバリー
継続的デリバリーには基本的に 3 つの流派があります。
継続的デリバリーは継続的インテグレーションの自然な延長である
この学校は、アディソン・ウェスリー「マーティン・ファウラー」シグネチャーシリーズ2007 年のリリースは「継続的インテグレーション」と呼ばれ、それに続く 2011 年のリリースは「継続的デリバリー」と呼ばれていたため、これらはおそらく継続的な何かに関係する同じ概念的なアイデアの第 1 巻と第 2 巻であると想定されます。
継続的デリバリーはアジャイルソフトウェア開発と関係がある
この流派は、継続的デリバリーとは、単なる概念的なアイデアや意向書としてではなく、実際に、つまり現実の生活の中で、アジャイル運動の原則をサポートできることがすべてであるという考えに基づいています。
第一原理で相殺するアジャイル宣言ここで「継続的デリバリー」という用語が実際に初めて使用されます。
当社の最優先事項は、価値あるソフトウェアを早期かつ継続的に提供することで顧客を満足させることです。
この学派は、「継続的デリバリー」は、自動化された検証を実装するために必要なすべてを網羅するパラダイムであると主張しています。「完了の定義」。
この学校は「継続的デリバリー」と流行語やメガトレンドを受け入れています「DevOps」これらは同じコインの裏表であり、どちらも単なる技術ではなく、この新しいパラダイムやアプローチを取り入れたり、包含したりしようとしているという意味です。
継続的デリバリーは継続的デプロイメントと同義である
3 番目の学派は、継続的デプロイメントと継続的デリバリーは同じ意味で互換的に使用できると主張しています。
開発者の手元に何か準備ができたら、それはすぐにエンドユーザーに配信されます。ほとんどの場合、それは実稼働環境にデプロイされることを意味します。したがって、「デプロイ」と「配信」は同じ意味です。
どの学校に入学するか
あなたの大学は明らかに最初の学校に加わっており、私たちが同じ出版シリーズの第 1 巻と第 2 巻について言及していると主張しています。これは継続的デリバリーという用語の誤用であるというのが私の意見です。
私は個人的に、継続的デリバリーは、アジャイル運動によって述べられたアイデアや概念を実際にサポートすることに関連しているという理解を主張しています。そのため、私は、この用語が「DevOps」のようなパラダイム全体を包含していると主張する学派に加わりました。
デリバリーをデプロイの同義語として使用する流派は、主にデプロイメント コンソールを作成するツール ベンダーによって提唱されており、継続的デリバリーという用語のより広範な使用から少しばかりの誇大宣伝を得ようとしています。
継続的デプロイメント
継続的デプロイメントに重点を置くのは、エンド ユーザーのソフトウェア更新へのアクセスが、この情報の中央ソースの更新に依存しており、この中央ソースがモノリシックであるか、本質的に (Web、SOA、データベースなど) 一貫性が (高すぎる) ために更新が必ずしも容易ではないドメインに最も関連します。
集中化された情報源がないソフトウェア (デバイス、消費者向け製品、クライアントのインストールなど) や、集中化された情報源を簡単に更新できるソフトウェア (アプリ ストアの成果物管理システム、オープン ソース リポジトリなど) を生産する多くのドメインでは、継続的デプロイメントという用語がほとんど宣伝されていません。単にデプロイするだけです。大したことではなく、特別な注意を必要とする面倒なことではありません。
継続的デプロイメントが一般的に誰にとっても興味深いものではないという事実は、「配信」と「展開」が同義語であると主張する学派が完全に間違っているという議論でもあります。継続的デリバリーは、デバイスに組み込みソフトウェアを作成する場合や、フレームワーク用のオープンソース プラグインをリリースする場合であっても、実際には誰にとっても完全に理にかなっているからです。
継続的デプロイメントは継続的デリバリーの自然な次のステップであるというあなたの大学の定義は、QA されたすべてのデリバリーがエンド ユーザーにすぐに利用可能になる必要があることを暗黙的に想定しており、私の部族が「継続的リリース」という用語を説明するために使用する定義に近いものですが、これもまた、一般的には誰にとっても意味をなさない別の概念です。
リリースは非常に戦略的または政治的なものであり、誰もが常にリリースを行いたいと考える理由はありません (オンライン書店やストリーミング サービス タイプの会社でない限り)。とはいえ、盲目的に常にすべてをリリースするわけではない会社でも、デプロイメントの達人になりたい理由はいくつもあるため、そのような会社でも継続的デプロイメントを行います。リリースから本番環境へのデプロイメントではなく、リリース候補から本番環境のような環境へのデプロイメントです。
もう一度言いますが、あなたの大学は間違っていると思います。彼らは「継続的デプロイメント」を「継続的リリース」と勘違いしています。
継続的デプロイメントとは、開発プロセスの結果を、機能テストを本格的に実行できる実稼働環境に継続的に移行できるようにする規律です。
継続的デリバリーのストーリー
写真ではすべてが生き生きとしています。
オリジナル写真（アーカイブ）：http://web.archive.org/web/20160315190327/http://www.code-conf.com/osl15/images/cdstoryline.png
継続的インテグレーション プロセスは、状態遷移図の最初の 2 つのアクションです。これが成功すると、完了の定義を実装する継続的デリバリー パイプラインが開始されます。デプロイメントは、このパイプラインで継続的に実行する必要がある多くのアクションの 1 つにすぎません。理想的には、開発者が VCS にコミットする時点から、パイプラインが有効なリリース候補があることを確認する時点まで、プロセスは自動化されます。