みなさんこんにちは！
9月の初めに、Eberhard Wolfによる興味深い書籍「連続配信。 継続的な更新の実践 "
急成長している業界では、用語を定義することが役立つ場合があります。 Wolfの本にまだ慣れていない人のために、Marco Anastasovによる短い記事を翻訳することにしました。この記事では、継続的インテグレーション、継続的デリバリー、継続的デプロイの違いが明確かつ明確に説明されています。 猫へようこそ！
継続的統合、継続的展開、継続的配信は、方向が同じでモジュールが異なるベクターのようなものです。 3つのトリックすべての目標は同じです。ソフトウェアの開発とリリースの信頼性を高め、開発とリリースをスピードアップすることです。
3つのアプローチの主な違いは、それぞれの自動化の量です。 初心者はしばしばこれらの現象を混同します。なぜなら、それらは相互に排他的ではないことに気付かないが、入れ子人形のようにお互いに入るからです。
カーネル：継続的インテグレーション
ほとんどの開発者は、このトピックに取り組み、最初に継続的インテグレーション （CI）に精通します。これは、コードに加えられたすべての変更が中央リポジトリで結合されます（操作は「マージ」と呼ばれます）。 マージは1日に数回行われ、特定のプロジェクトでの各マージの後、自動アセンブリとテストがトリガーされます。
プログラムをビルドしてテストする前に、プログラムをコンパイルする必要があります（作成された言語によって異なります）。 現在、アプリケーションをDockerコンテナにパックする必要性が高まっています。 次に、自動テストにより、特定のコードモジュール、UIパフォーマンス、アプリケーションパフォーマンス、API信頼性などが検証されます。これらのすべてのステップは、まとめて「ビルド」と呼ばれます。
CIは、開発者がプロジェクトを開始する前に多くの問題を回避できるようにする一種のセーフティネットです。 したがって、プログラマーはそのようなコードを引き渡すことに自信を持っていますが、作業自体は加速する可能性が低いです-デプロイメントが手動で長時間実行される可能性があり、この段階でエラーが発生する可能性もあります。
開発者が最初の段階でできることは、自動テストのセットが包括的で安定していることを確認して、CIに合格したアセンブリを安全に起動し、最初に実行してから実稼働することです。 したがって、長時間の手動テスト（QA）を行わなくても実行できます。
第二に、CIの速度に注意してください。開発者はCIの結果を最大10分で取得する必要があると確信しています。そうしないと、集中力が失われタスクが頻繁に切り替わって生産性が低下します。 CIを高速化するには、強力なプラットフォームでテストを並列化すると便利です 。
継続的な配信と展開への移行
継続的デリバリー（CD）は、ソフトウェアリリースプロセス全体を自動化する方法です。 IjeyaはCIを実行し、さらに実動用のリリースを自動的に準備および実施します。 この場合、以下を達成することが望ましい：新しいリリースを展開するのに十分な権限を持っている人はいつでも展開を実行でき、これは数回のクリックで実行できます。 プログラマーは、ほとんどすべての手作業を取り除き、より生産的に機能します。
通常、継続的な配信プロセスでは、少なくとも1つの手順を手動で完了する必要があります。運用環境での展開の承認と起動です。 多くの依存関係がある複雑なシステムでは、連続配信パイプラインに手動または自動で追加の手順が含まれる場合があります。
継続的な展開は、「1レベル」の継続的な配信に位置しています。 この場合、ソースコードに加えられたすべての変更は、開発者から明示的に承認されることなく、本番環境に自動的に展開されます。 原則として、開発者のタスクは、同僚からのプルリクエストをチェックし、すべての重要なイベントの結果についてチームに通知することになります。
継続的な展開には、チームが適切に機能する監視文化が必要です。誰もが最新の状態を保ち、システムを迅速に復元する方法を知っています。
私は多くの継続的な展開チームと会話をしました。 開発者は、さまざまな環境に合わせて展開を構成できることを高く評価しています。 誰が、何を、いつ展開するかを誰もが想像することも同様に重要です。 CIを実践し、最初にフレームワークへの展開を自動化して継続的な展開に移行したい開発者は、ワンクリックで手動で実稼働への展開を続けます。
概念の境界
「継続的配信」は「継続的統合」および「継続的展開」よりも不安定な概念であるため、最初の用語は、個別のサービスまたはアプリケーションのレベルよりも幅広いコンテキストに適用されます-システム全体、さらには組織の動作を表すことができます。
たとえば、完全な継続的インテグレーションにより、ゼロからの事故が発生した場合、1つのチームで本番環境の完全なコピーを作成することが可能になります。 または、約5分で新しいマイクロサービスの展開に適合しない場合、チームが要求する開発ペースを維持できないことに同意することができます。 これは、継続的デリバリーとDevOpsを区別するのが難しい場所です。 実際、DevOpsカテゴリにインフラストラクチャの自動プロビジョニング（「コードとしてのインフラストラクチャ」プラクティスが使用されます）などのタスクを残し、製品全体を記録し、メトリックを追跡する方が論理的です。
さらに、混乱が生じる場合があります。これは、ペア「CI / CD」の略語「CD」を意味します。 この質問に対する明確な答えはありませんが、ほとんどの場合、このペアは「継続的な統合と継続的な配信」として理解されています。 これは、継続的な展開が、すべてのシステムに適用できるわけではない継続的な配信の特殊なケースであると考える場合に論理的です。
短い要約と最終的な考え
だから：
- 継続的インテグレーション（CI）：短命の機能ブランチ。チームは1日に数回それらをメインの開発ブランチにマージします。アセンブリおよびテストプロセスは完全に自動化され、結果は10分以内です。 展開は手動です。
- 継続的デリバリー（CD）：CI +は、ソフトウェアリリースプロセス全体を自動化します。 いくつかの段階で構成される場合があります。 実動デプロイメントは手動です。
- 継続的な展開：CI + CD +本番環境での完全自動化された展開。
この投稿では、これらの現象の違いを説明するために、継続的インテグレーション、継続的デリバリ、継続的デプロイの主な特徴を強調したかったのです。 当然、3つのトピックのそれぞれをより詳細に調べることができます。この記事で提供されているリンクに従うことをお勧めします。