質問

この3つの用語の違いは何ですか？私の大学では次のように定義しています。

継続的インテグレーション は、基本的に、開発者の作業コピーが1日に数回、共有のメインラインと同期されることを意味します。

継続的デリバリー は、継続的インテグレーションの論理的進化と説明されています。常に製品を本番稼動させることができるようにすることです。

継続的デプロイメント は、継続的デリバリーの論理的な次のステップと説明されています。QAに合格したらいつでも製品を自動的に本番環境にデプロイするのです!

また、警告も出しています。テストシステムに継続的にデプロイできる場合、「継続的デプロイメント」という言葉も使われることがあります。

これだけだと、よくわからない。もう少し詳しい説明（または例付き）があればありがたいのですが。

どのように解決するのですか？

継続的インテグレーション

貴大学の定義に同意します。 継続的インテグレーション は、開発者がコードをメインラインに継続的に統合する方法（頻繁に統合するのではなく）についての戦略です。

バージョン管理システムにおける単なるブランチ戦略だと主張する人もいるかもしれませんね。

もし、あるタスクが4～5人日かかると見積もられていたら、開発者は4～5日先まで何も提供する気が起きないでしょう、だってまだ何も終わっていないんですから。

つまり、サイズが重要なのですね。

small task = continuous integration
big task   = frequent integration

理想的なタスクのサイズは、1日分の仕事より大きくない。そうすれば、開発者は1日に最低でも1つのインテグレーションを自然にこなすことができます。

継続的デリバリー

基本的には以下の3つです。 学校 継続的デリバリーの中で

継続的デリバリーは、継続的インテグレーションの自然な延長である

この学校では アディソンウェスリー社 マーティンファウラーシリーズ という仮説を立て、2007年に発売されたものから Continuous Integration" と呼ばれ、2011年に続くものは 継続的デリバリー（Continuous Delivery）" この2つは、おそらく同じコンセプトの1巻と2巻で構成されています。 何か .

継続的デリバリーはアジャイルソフトウェア開発と関係がある

この学校は、継続的デリバリーとは、アジャイル運動における原則をサポートできるようにするためのものであり、単にアジャイルのためのものではないという考えから出発しています。 概念的なアイデア または 意思表示 しかし、リアルに、現実の世界で。

の第一原則でオフセットを取る。 アジャイルマニフェスト ここで初めて「継続的デリバリー」という言葉が使われました。

価値あるソフトウェアを早期に、継続的に提供することで、お客様に満足していただくことを最優先しています。

この学校では、「継続的デリバリー」とは、自動的な検証を実施するために必要なすべてを包含するパラダイムであると主張しています。 "完了の定義" .

この学校は、"Continuous Delivery"とバズワードまたはメガトレンドを受け入れています。 "デブオプス" は、どちらも単なるテクニックではなく、この新しいパラダイムやアプローチを包含しようとするという意味で、同じコインの裏表です。

Continuous DeliveryはContinuous Deploymentと同義語です。

第三派が提唱するのは 継続的デプロイメント と 継続的デリバリー は、同じ意味として使い分けることができます。

開発者の手元で準備が整ったものは、すぐにエンドユーザーに届けられる。それは、ほとんどの場合、本番環境にデプロイされることを意味する。したがって、デプロイとデリバーは同じ意味です。

どの学校に入るか

あなたの大学は明らかに第1派に属し、私たちは同じ出版シリーズの1巻と2巻を参照していると主張しています。私の考えでは、これはContinuous Deliveryという用語の誤用だと思います。

私自身は、以下のような理解を提唱しています。 継続的デリバリー は、アジャイルムーブメントで述べられたアイデアやコンセプトを現実的にサポートするための実装に関連しています。ですから、私は、この用語はパラダイム全体を包含していると言う派に入りました。

を使う派 配信 の対義語として 配備 は、デプロイメントコンソールを作成するツールベンダーによって提唱され、より広く使われている用語である 継続的デリバリー .

継続的デプロイメント

継続的デプロイメントの焦点は、エンドユーザーがソフトウェアの更新にアクセスする際に、情報の集中ソースの更新に依存し、この集中ソースがモノリシックであったり、本質的に高い一貫性を持っているために更新が必ずしも容易ではない領域（Web、SOA、データベースなど）に関連することがほとんどです。

集中的な情報源がないソフトウェア（デバイス、消費者製品、クライアントインストールなど）を生産する多くのドメインや、集中的な情報源の更新が容易な場合（アプリストア、アーティファクト管理システム、オープンソースリポジトリなど）、継続的デプロイメントという用語についての誇大広告はほとんど全くありません。彼らはただデプロイするだけで、それは大きなことではなく、特別な集中力を必要とする苦痛でもない。

継続的デプロイメントが誰にとっても一般的に興味深いものではないという事実は、「デリバリー」と「デプロイ」が同義語であると主張する学派が完全に間違っていることを示すものでもあります。なぜなら、継続的デリバリーは、実際には誰にとっても完全に理にかなっているからです。たとえあなたがデバイスの組み込みソフトウェアや、フレームワークのオープンソースプラグインをリリースしているとしてもです。

継続的デプロイは継続的デリバリーの自然な次のステップであるというあなたの大学の定義は、QAされたすべてのデリバリーが直ちにエンドユーザーにとって利用可能になるべきであると暗に仮定しており、私の仲間が用語" Continous Release" を説明するために使用している定義に近いものです。

リリースは非常に戦略的、政治的なものであり、誰もがこれを常に行いたいと考える理由はありません（オンラインブックストアやストリーミングサービスのような企業であれば別ですが）。とはいえ、やみくもにすべてを常時リリースしない企業には、とにかく展開の達人になりたいという理由がいくつもあるでしょうから、彼らもまた 継続的デプロイメント . 本番環境へのリリースではなく リリース候補 から プロダクションライク という環境です。

繰り返しになりますが、あなたの大学は間違っていると思います。彼らは、「継続的デプロイメント」と「継続的リリース」を間違えているのです。

継続的デプロイメントとは、開発プロセスの結果を、機能テストを本格的に実行できる本番環境に継続的に移行させることができるようにするための規律です。

継続的デリバリーのストーリー

写真では、すべてが生き生きとしています。

継続的インテグレーションプロセスは、状態遷移図における最初の2つのアクションです。これが成功すると、継続的デリバリーパイプラインが開始されます。 完了の定義 . デプロイメントは、このパイプラインで継続的に行わなければならない多くのアクションの1つに過ぎません。理想的には、開発者がVCSにコミットした時点から、パイプラインが有効なリリース候補を確認した時点まで、プロセスが自動化されることです。