CI / CDとは何ですか?継続的インテグレーションと継続的デリバリーの説明

継続的インテグレーション(CI)と継続的デリバリー(CD)は、アプリケーション開発チームがコード変更をより頻繁かつ確実に提供できるようにする文化、一連の運用原則、およびプラクティスのコレクションを具体化します。この実装は、CI / CDパイプラインとも呼ばれます。 

CI / CDは、DevOpsチームが実装するためのベストプラクティスの1つです。また、展開手順が自動化されているため、ソフトウェア開発チームがビジネス要件、コード品質、およびセキュリティを満たすことに集中できるため、アジャイル手法のベストプラクティスでもあります。

CI / CDが定義されています

継続的インテグレーション は、開発チームが小さな変更を実装し、コードをバージョン管理リポジトリに頻繁にチェックインするように促すコーディング哲学と一連のプラクティスです。最新のアプリケーションのほとんどは、さまざまなプラットフォームやツールでコードを開発する必要があるため、チームはその変更を統合して検証するメカニズムを必要としています。

CIの技術的な目標は、アプリケーションを構築、パッケージ化、およびテストするための一貫した自動化された方法を確立することです。統合プロセスに一貫性があると、チームはコード変更をより頻繁にコミットする可能性が高くなり、コラボレーションとソフトウェアの品質が向上します。

継続的デリバリー は、継続的インテグレーションが終了する場所をピックアップします。CDは、選択したインフラストラクチャ環境へのアプリケーションの配信を自動化します。ほとんどのチームは、開発環境やテスト環境など、本番環境以外の複数の環境で作業します。CDは、コードの変更をチームにプッシュする自動化された方法があることを保証します。

CI / CDツールは、各配信でパッケージ化する必要がある環境固有のパラメーターを格納するのに役立ちます。次に、CI / CD自動化は、アプリケーションの展開時に再起動または他の手順に従う必要があるWebサーバー、データベース、およびその他のサービスに対して必要なサービス呼び出しを実行します。

継続的インテグレーションと継続的デリバリーには、高品質のアプリケーションとコードをユーザーに提供することが目的であるため、継続的テストが 必要 です。継続的テストは、多くの場合、CI / CDパイプラインで実行される一連の自動回帰、パフォーマンス、およびその他のテストとして実装されます。

成熟したCI / CD devopsプラクティスには、アプリケーションの変更がCI / CDパイプラインを介して実行され、パスビルドが本番環境に直接デプロイされる継続的デプロイを実装するオプションがあります。継続的デリバリーを実践しているチームは、毎日または1時間ごとのスケジュールで本番環境に展開することを選択しますが、継続的デリバリーがすべてのビジネスアプリケーションに常に最適であるとは限りません。  

関連ビデオ:CI / CDを使用してコードをより速く配信する方法

継続的インテグレーションがコラボレーションと品質をどのように改善するか

継続的インテグレーションは、プロセスの仕組みといくつかの自動化に裏打ちされた開発哲学です。 CIを実践する場合、開発者はコードをバージョン管理リポジトリに頻繁にコミットし、ほとんどのチームは少なくとも毎日コードをコミットするという最小限の基準を持っています。この背後にある理論的根拠は、長期間にわたって開発された大きなコードの違いよりも、小さなコードの違いの欠陥やその他のソフトウェア品質の問題を特定する方が簡単であるということです。さらに、開発者がより短いコミットサイクルで作業する場合、複数の開発者が同じコードを編集し、コミット時にマージを必要とする可能性は低くなります。

継続的インテグレーションを実装するチームは、多くの場合、バージョン管理の構成とプラクティスの定義から始めます。コードのチェックインは頻繁に行われますが、機能と修正は短い時間枠と長い時間枠の両方で実装されます。継続的インテグレーションを実践している開発チームは、さまざまな手法を使用して、本番環境で使用できる機能とコードを制御します。

多くのチームは、実行時に機能とコードをオンまたはオフにする構成メカニズムである機能フラグを使用しています。まだ開発中の機能は、コード内の機能フラグでラップされ、マスターブランチとともに本番環境にデプロイされ、使用できるようになるまでオフにされます。最近の調査によると、機能フラグを使用するチームの63%が、より優れたテストとより高品質のソフトウェアを報告しています。 CloudBees Rollout、Optimizely Rollouts、LaunchDarklyなどの機能フラグツールはCI / CDツールと統合され、機能レベルの構成を可能にします。

機能を管理するためのもう1つの手法は、 バージョン管理の分岐です。 Gitflowなどの分岐戦略を選択して、開発、テスト、および本番用に新しいコードを標準の分岐にマージする方法に関するプロトコルを定義します。開発サイクルが長くなるもののために、追加の機能ブランチが作成されます。機能が完了すると、開発者は機能ブランチからの変更をプライマリ開発ブランチにマージできます。このアプローチはうまく機能しますが、同時に開発されている多くの機能がある場合、管理が困難になる可能性があります。

ビルドプロセス自体は、すべてのソフトウェア、データベース、およびその他のコンポーネントをパッケージ化することによって自動化されます。たとえば、Javaアプリケーションを開発している場合、CIは、HTML、CSS、JavaScriptなどのすべての静的Webサーバーファイルを、Javaアプリケーションおよびデータベーススクリプトとともにパッケージ化します。

CIは、すべてのソフトウェアとデータベースコンポーネントをパッケージ化するだけでなく、自動化によって単体テストやその他のテストも実行されます。このテストは、コードの変更によって既存の単体テストが中断されなかったというフィードバックを開発者に提供します。

ほとんどのCI / CDツールでは、開発者はバージョン管理リポジトリ内のコードコミットによって、または定義されたスケジュールで、オンデマンドでビルドを開始できます。チームは、チームのサイズ、予想される1日のコミット数、およびその他のアプリケーションの考慮事項に最適なビルドスケジュールについて話し合う必要があります。コミットとビルドが高速であることを確認するためのベストプラクティス。そうしないと、コードを高速化して頻繁にコミットしようとするチームの進行が妨げられる可能性があります。

継続的テストはテストの自動化を超えています

自動テストフレームワークは、品質保証エンジニアがさまざまなタイプのテストを定義、実行、および自動化するのに役立ち、開発チームがソフトウェアビルドが成功したか失敗したかを知るのに役立ちます。これらには、すべてのスプリントの最後に開発され、アプリケーション全体の回帰テストに集約される機能テストが含まれます。次に、これらの回帰テストは、コード変更が、テストカバレッジがあるアプリケーションのすべての機能領域にわたって開発された1つ以上のテストに失敗したかどうかをチームに通知します。

ベストプラクティスは、開発者がローカル環境で回帰テストのすべてまたはサブセットを実行できるようにし、要求することです。この手順により、開発者は、回帰テストがコードの変更に合格した後にのみ、コードをバージョン管理にコミットします。

回帰テストはほんの始まりに過ぎません。パフォーマンステスト、APIテスト、静的コード分析、セキュリティテスト、およびその他のテストフォームも自動化できます。重要なのは、コマンドライン、Webhook、またはWebサービスのいずれかを介してこれらのテストをトリガーできるようにし、成功または失敗のステータスコードで応答することです。

テストが自動化されると、継続的テストは自動化がCI / CDパイプラインに統合されることを意味します。一部のユニットおよび機能テストは、統合プロセスの前または最中に問題にフラグを立てるCIに統合できます。パフォーマンスやセキュリティテストなどの完全な配信環境を必要とするテストは、多くの場合CDに統合され、ビルドがターゲット環境に配信された後に実行されます。

CDパイプラインは、複数の環境への変更を自動化します

継続的デリバリーは、アプリケーションをデリバリー環境にプッシュする自動化です。ほとんどの開発チームには通常、アプリケーションの変更がテストとレビューのためにステージングされる1つ以上の開発およびテスト環境があります。Jenkins、CircleCI、AWS CodeBuild、Azure DevOps、Atlassian Bamboo、TravisCIなどのCI / CDツールを使用して、手順を自動化し、レポートを提供します。

一般的なCDパイプラインには、ビルド、テスト、および展開の段階があります。より洗練されたパイプラインには、次のステップの多くが含まれます。

  • バージョン管理からコードをプルしてビルドを実行します。
  • クラウドインフラストラクチャを立ち上げたり破棄したりするためのコードとして自動化された、必要なインフラストラクチャステップを実行します。
  • コードをターゲットコンピューティング環境に移動します。
  • 環境変数を管理し、ターゲット環境用に構成します。
  • アプリケーションコンポーネントを、Webサーバー、APIサービス、データベースサービスなどの適切なサービスにプッシュします。
  • 新しいコードプッシュに必要なサービスの再起動またはサービスエンドポイントの呼び出しに必要な手順を実行します。
  • テストが失敗した場合の継続的なテストとロールバック環境の実行。
  • 配信の状態に関するログデータとアラートを提供します。

例として、Jenkinsユーザーは、ビルド、テスト、デプロイなどのさまざまな段階を記述するJenkinsfileでパイプラインを定義します。環境変数、オプション、秘密鍵、証明書、およびその他のパラメーターはファイルで宣言され、段階的に参照されます。投稿セクションは、エラー状態と通知を処理します。  

より洗練されたCDには、データ同期の実行、情報リソースのアーカイブ、アプリケーションとライブラリのパッチ適用などの他の手順が含まれる場合があります。CI / CDツールは通常、プラグインのマーケットプレイスをサポートします。たとえば、Jenkinsには、サードパーティプラットフォームとの統合、ユーザーインターフェイス、管理、ソースコード管理、ビルド管理をサポートする1​​,500を超えるプラグインがリストされています。

CI / CDツールを選択したら、開発チームはすべての環境変数がアプリケーションの外部で構成されていることを確認する必要があります。CI / CDツールを使用すると、これらの変数を設定し、パスワードやアカウントキーなどの変数をマスクし、ターゲット環境の展開時にそれらを構成できます。

CDツールは、ダッシュボードとレポート機能も提供します。ビルドまたは配信が失敗した場合、開発者に失敗に関する情報を警告します。これらはバージョン管理およびアジャイルツールと統合されているため、ビルドを構成するコードの変更やユーザーストーリーを調べるために使用できます。

Kubernetesとサーバーレスアーキテクチャを使用したCI / CDパイプラインの実装 

クラウド環境でCI / CDパイプラインを運用している多くのチームは、DockerなどのコンテナーやKubernetesなどのオーケストレーションシステムも使用しています。コンテナを使用すると、アプリケーションを標準のポータブルな方法でパッケージ化および出荷できます。コンテナを使用すると、ワークロードが変動する環境を簡単にスケールアップまたは破棄できます。

コンテナー、コードとしてのインフラストラクチャ、およびCI / CDパイプラインを一緒に使用する方法はたくさんあります。Jenkinsを使用したKubernetesやAzureDevOpsを使用したKubernetesなどのチュートリアルを使用して、オプションを調べることができます。

サーバーレスコンピューティングアーキテクチャは、アプリケーションを展開およびスケーリングするための別の手段を提供します。サーバーレス環境では、インフラストラクチャはクラウドサービスプロバイダーによって完全に管理され、アプリケーションはその構成に基づいて必要に応じてリソースを消費します。たとえばAWSでは、サーバーレスアプリケーションはLambda関数として実行され、デプロイはプラグインを使用してJenkins CI / CDパイプラインに統合できます。 

CI / CDにより、より頻繁なコード展開が可能になります

要約すると、CIはソフトウェアビルドをパッケージ化してテストし、変更が単体テストに失敗した場合に開発者に警告します。CDは、インフラストラクチャに変更を加え、追加のテストを実行する自動化です。 

CI / CDパイプラインは、アプリケーションを頻繁に改善し、信頼性の高い配信プロセスを必要とする企業向けに設計されています。ビルドを標準化し、テストを開発し、デプロイメントを自動化するための追加の取り組みは、コード変更をデプロイするための製造プロセスです。配置が完了すると、チームはアプリケーションを拡張するプロセスに集中でき、コンピューティング環境にアプリケーションを配信するシステムの詳細に集中できなくなります。

CI / CDは、安定したアプリケーションを必要とする操作で、変更を頻繁にプッシュしたい開発者間の不整合に対処するため、DevOpsのベストプラクティスです。自動化を実施すると、開発者は変更をより頻繁にプッシュできます。環境には標準構成があり、配信プロセスで継続的テストが行​​われ、環境変数がアプリケーションから分離され、ロールバック手順が自動化されているため、運用チームの安定性が向上します。

CI / CDパイプラインの実装による影響は、DevOpsの主要業績評価指標(KPI)として測定できます。継続的テストを伴うCI / CDを実装すると、展開頻度、変更リードタイム、インシデントからの平均修復時間(MTTR)などのKPIが改善されることがよくあります。ただし、CI / CDはこれらの改善を推進できるプロセスの1つにすぎず、展開頻度を改善するための他の前提条件があります。

CI / CDの使用を開始するには、開発チームと運用チームがテクノロジー、プラクティス、および優先順位について協力する必要があります。チームは、CI / CDが導入されると、チームが一貫して以下のプラクティスに参加できるように、ビジネスとテクノロジーの適切なアプローチについてコンセンサスを形成する必要があります。