継続的インテグレーション
私はあなたの大学の定義に同意します。継続的インテグレーションは、開発者がコードをメインラインに継続的に統合する方法です。頻繁ではありません。
これはバージョン管理システムの分岐戦略に過ぎないと主張するかもしれません。
開発者に割り当てるタスクのサイズに関係しています。タスクに4〜5人日かかると見積もられた場合、開発者はまだ何もしていないため、次の4〜5日間は何も提供する意欲がありません。
したがって、サイズが重要です：
small task = continuous integration
big task = frequent integration
理想的なタスクサイズは、1日の作業よりも大きくありません。このようにして、開発者は当然、1日あたり少なくとも1つの統合を行います。
継続的デリバリー
継続的デリバリーには基本的に3つの学校があります。
継続的デリバリーは継続的統合の自然な拡張です
この学校では、Addison-Wesleyの「Martin Fowler」シグネチャーシリーズを調べ、2007年のリリースは「継続的インテグレーション」と呼ばれ、2011年以降は「継続的デリバリー」と呼ばれていたため、おそらくボリューム1 + 2であると想定しています。継続的な何かに関係しているのと同じ概念的なアイデアの。
継続的デリバリーはアジャイルソフトウェア開発と関係があります
この学校は、継続的デリバリーとはアジャイルムーブメントの原則をサポートすることであり、概念的なアイデアや意向の手紙としてだけでなく、現実の生活においても成り立ちます。
「継続的デリバリー」という用語が実際に初めて使用されるアジャイル宣言の最初の原則でオフセットを取る：
私たちの最優先事項は、貴重なソフトウェアの早期かつ継続的な提供を通じて顧客を満足させることです。
この学校は、「継続的デリバリー」は「完了の定義」の自動検証を実装するために必要なすべてを包含するパラダイムであると主張しています。
この学校は、「継続的デリバリー」と流行語またはメガトレンド「DevOps」は、技術だけでなく、この新しいパラダイムまたはアプローチを採用またはカプセル化しようとするという意味で、同じコインの裏返しであることを受け入れます。
継続的デリバリーは継続的デプロイメントの同義語です
3番目の学校は、継続的導入と継続的デリバリーを同じ意味で使用することができることを主張しています。
何かが開発者の手に届くと、すぐにエンドユーザーに配信されます。これは、ほとんどの場合、本番環境に展開する必要があることを意味します。したがって、「デプロイ」と「配信」は同じ意味です。
参加する学校
あなたの大学は明らかに最初の学校に参加しており、同じ出版物シリーズのボリューム1 + 2を指していると主張しています。私の意見では、これは継続的デリバリーという用語の誤用です。
私は個人的に、継続的デリバリーはアジャイル運動によって述べられたアイデアと概念に対する実際のサポートの実装に関連しているという理解を主張しています。それで、私はこの用語が「DevOps」のようなパラダイム全体を包含すると言う学校に参加しました。
展開の同義語として配信を使用する学校は、展開コンソールを作成するツールベンダーが主に提唱しており、継続的配信という用語のより広範な使用から少し誇大宣伝を得ようとしています。
継続的な展開
継続的な展開への焦点は、ソフトウェア更新へのエンドユーザーのアクセスがこの情報の一部の集中ソースの更新に依存し、この集中ソースがモノリシックであるか、または（あまりに）一貫性が高いため、常に更新が容易ではないドメインに関連します。本質的に（ウェブ、SOA、データベースなど）。
一元化された情報ソース（デバイス、コンシューマー製品、クライアントインストールなど）がない、または情報の一元化されたソースを簡単に更新できる（アプリストアアーティファクト管理システム、オープンソースリポジトリなど）ソフトウェアを生成する多くのドメイン向け。 ）、継続的展開という言葉については誇大宣伝はほとんどありません。彼らはただ展開します。それは大きなことではありません-それは特別な焦点を必要とする痛みではありません。
継続的な展開が一般的に誰にとっても興味深いものではないという事実は、「配信」と「展開」は同義語であると主張する学校がすべて間違っているとする議論でもあります。継続的デリバリーは、デバイスに埋め込まれたソフトウェアを実行している場合や、フレームワーク用のオープンソースプラグインをリリースしている場合でも、実際には誰にとっても完全に理にかなっているためです。
継続的導入が継続的デリバリーの自然な次のステップであるというあなたの大学の定義は、QAされたすべてのデリバリーがエンドユーザーにすぐに利用可能になるはずであることを暗黙的に想定しており、部族が「継続的リリース」は、一般的に誰にとっても意味のないもう1つの概念です。
リリースは非常に戦略的または政治的なものになる可能性があり、誰もが常にこれをしたいと思う理由はありません（彼らがオンライン書店であり、ストリーミングサービスの会社である場合を除きます）。それにもかかわらず、常にすべてを盲目的にリリースしない企業は、とにかくデプロイメントのマスターになりたいと思う理由がいくつもある可能性があるため、継続的デプロイメントも行います。実稼働へのリリースではなく、実稼働のような環境へのリリース候補です。
もう一度私はあなたの大学がそれを間違っていると思います。彼らは「継続的デプロイメント」を「継続的リリース」と間違えています。
継続的な展開とは、機能テストをフルスケールで実行できる本番環境のような環境に開発プロセスの結果を継続的に移行できるようにするための規律です。
継続的デリバリーのストーリー
写真ではそれがすべて生きています：
継続的統合プロセスは、状態遷移図の最初の2つのアクションです。成功すると、doneの定義を実装する継続的デリバリーパイプラインが開始されます。デプロイは、このパイプラインで継続的に実行する必要がある多くのアクションの1つにすぎません。理想的には、開発者がVCSにコミットした時点から、有効なリリース候補があることをパイプラインが確認した時点まで、プロセスは自動化されています。
