改めて学ぶDevOpsの基盤 「CI」「CT」「CD」の役割とは：DevOpsはCI/CDだけじゃない

TechTargetは、「CI、CT、CDをDevOpsパイプラインにまとめる方法」に関する記事を公開した。DevOpsパイプラインを構成するのはCI/CDだけではない。継続的テスト（CT）も重要な構成要素の一つだ。

[Michael Levan，TechTarget]

　TechTargetは2024年8月5日（米国時間）、「CI、CT、CDをDevOpsパイプラインにまとめる方法」に関する記事を公開した。

CI、CT、CDをDevOpsパイプラインにまとめる方法（提供：TechTarget）

　継続的インテグレーション（CI）、継続的デリバリー（CD）、継続的テスト（CT）はDevOpsの基盤であり、これによって、ソフトウェアデリバリーワークフローとコードリリースプロセスの速度を上げることができる。これらのプロセスはまとめて「CI/CDパイプライン」もしくは「DevOpsパイプライン」と呼ばれる。CTはこのアプローチで重要な役割を果たすにもかかわらず、その説明が省略されることも多い。本稿では、CI、CT、CDが一体となって、迅速でエラーが発生しにくいソフトウェアリリースを実現する方法を紹介する。

DevOpsにおけるCIの役割

　CIとは、複数の開発者が開発したコードを、セキュリティが確保された一元管理のリポジトリ（例えば「GitHub」や「GitLab」など）に自動的に統合（マージ）するソフトウェア開発手法を指す。CIでは、コードへの変更を頻繁にリポジトリにマージする。

　「Slack」や「Microsoft Teams」などのコミュニケーションツールはCIツールと統合されることが多く、開発チームにリアルタイムの更新情報を提供し、デプロイメント中に発生する問題への迅速な対応を促す。

DevOpsにおけるCTの役割

　CTによって、開発ライフサイクルの全ての段階でテストが実施される。

　開発者がコードをリポジトリにコミットすると、CTが効果を発揮し始める。自動テストが開始され、コードが次の段階に進む前に“コードベースの各側面が正しく機能すること”を確認する。こうしたテストが自動的に実施されることで、開発者は開発プロセスの早い段階で問題点を把握できる。

　CTは、DevOpsライフサイクル全体を通じてテストと検証が継続的に実施される状態を確保し、迅速なフィードバックを可能にしてリリースまでの時間を短縮する。

　CTには、以下のようなさまざまな種類のテストが含まれる。

• 単体テスト
• 統合テスト
• 回帰テスト
• パフォーマンステスト
• セキュリティテスト

　これらのテストは、コードのさまざまな側面を対象とし、コード全体の品質と安定性を確保する。

　CTは開発者にフィードバックループを提供する。それによって開発者は問題を迅速に特定して対処可能になり、品質の高いソフトウェアをリリースできるようになる。さらに、テストカバレッジ、テスト合格率、コード品質などの指標を追跡、分析することで、テストプロセスとコードベースの継続的な改善も可能になる。

DevOpsにおけるCDの役割

　DevOpsプロセスの最終段階がCDだ。この段階でコードは実行可能な状態になり、本番環境にリリースされる。本番環境へのリリースには、HashiCorpの「Terraform」や「Packer」などのIaC（Infrastructure as Code）ツールが使用されることが多い。アプリケーションインフラの構成ファイルもバージョン管理できるため、自動化をさらに進めることも可能だ。リリースの準備ができたら、コードを再度テストし、最新バージョンのアプリケーションとその全ての依存関係を使用して環境をプロビジョニングする。

　“バージョン管理”はCI/CT/CDパイプラインを成功に導くカギになる。バージョン管理のプロセスとシステムによって、開発チームはアプリケーションとインフラの構成コードを確認（レビュー）できる。また、バージョン管理は、パイプラインの各ステップをトリガーする「自動化サーバの起点」にもなる。開発者やDevOpsエンジニアが特定のブランチにコードをコミットすると、自動的にパイプライン全体が動き出す。

CI/CT/CDパイプラインのメリット

　CI/CT/CDパイプラインは、コードベースへの不適切な変更やエラーが発生しやすい変更に対するガードレールを提供し、コードの欠陥を早期に検出できるメリットがある。また、開発者に素早くフィードバックを返すことで、発生した問題への迅速な対処が可能になる。フィードバックには、ツールダッシュボードやチャットツールからアクセスする。この継続的なフィードバックループによってイテレーションの速度が上がり、開発サイクルの効率が高まる。

　CI/CT/CDパイプラインはデプロイメント全体を自動化する。ソフトウェアを手作業でリリースすると、人為的エラーが発生しやすくなる。だが、リリースまでの手順を自動化すれば、コードとリリースプロセスの両方が正しく機能することを保証できる。開発者、QAエンジニア、テクニカルライター、テクニカルサポートなどのチームメンバーが欠陥を発見した場合は、このパイプラインを使って、以前のコードバージョンへ自動的にロールバックできる。

　CI/CT/CDパイプラインでは、運用中のトラブルに対する安全策として「機能フラグ」も利用できる。機能フラグはコードベースの一部で、新しいアプリケーション機能のリリースをクライアントのサブセット（特定のグループ）に制限する。開発者は機能フラグを使って、ある機能が選択的または広範囲に使用できる状態になるまで、アプリケーションのソースコード内の関数を非表示にできる。また、「カナリアテスト」として少数のユーザーに限定して機能をリリースできる。リリースしたユーザーで問題が発生した場合は、その機能のリリースを中止するか、ロールバックすればいい。機能フラグがあればアプリケーション自体のデプロイメントを制御できるというわけだ。

　「LaunchDarkly」などのサードパーティーツールを使用すると、開発者は対象ユーザーに機能をリリースし、「A／Bテスト」を実施して、新しい機能の段階リリースが可能になる。別の選択肢としては、オープンソースの機能フラグとリモート構成サービス「Flagsmith」も有用だ。Flagsmithは、セルフホスト型またはマネージドサービスとして利用できる。どちらのツールも、一般的なCI/CDサービスと統合可能だ。

CI/CDパイプラインの流れ

CI/CT/CDの仕組み

　ここからは、CI/CT/CDパイプラインのシーケンスと、そこで使用する一般的なツールについて説明する。

継続的インテグレーション（CI）

　CIフェーズでは、開発者は機能を作成し、更新または修正してから、コードを中央のコードリポジトリにコミットする。これには、GitHubやGitLabなどのバージョン管理ツールがよく使われる。こうしたプラットフォームによって、開発者は他の開発者の作業を妨げることなく、コードを作成、変更できる。

　コミット後のフェーズではCIサーバが利用される。CIサーバはコードに対してテストを実行するトリガーとなる。そのため、開発チームは、コードリポジトリの特定のブランチにコミットがあったことを監視するようにCIサーバ（自動化サーバ）を設定する必要がある。CIサーバは、コードをダウンロード（Pull Down）し、パイプラインを開始してテストに合格したコードを自動ビルドプロセスに移動させる。CIサーバとして業界で利用者が多いのは「Jenkins」だが、「CircleCI」「Travis CI」「CloudBees CI」なども使われている。

継続的テスト（CT）

　DevOpsパイプラインの初期段階では、静的コード分析を実施し、以前のコードと新しいコードの比較や一般的な脆弱（ぜいじゃく）性などを確認する。開発チームはこの分析ができるように、CIサーバにプラグイン（「SonarQube」や「Codacy」などツールのプラグイン）を設定する必要がある。もしパイプラインの早期段階で単体テストが実施されていない場合は、この静的コード分析に合格した後で単体テストを実施する。単体テストでは、コードの個々の機能が正しく動作することを確認する。最後に実施するのは機能テストで、CIサーバがビルドプロセスを開始（ビルドプロセスをトリガー）した後に実施する。機能テストでは、アプリケーションまたは機能が設計通りに動作することを確認する。こうしたテストは、コードをデプロイする前の「ゲートキーパー」の役割を果たす。

継続的デリバリー（CD）

　コードが全てのテストに合格した後の最終段階がデプロイメントだ。DevOpsパイプラインのコンテキストでは、CDは“継続的デリバリー”と称されることが多いが、“継続的デプロイメント”と称されることもある。両者には以下の違いがある。

• 継続的デリバリー：ステージング環境とリリーススケジュールに変更が加えられることがあり、その場合はコードの承認とデプロイが手作業で実施される
• 継続的デプロイメント：テストに合格したコードが本番環境に自動的にデプロイされる

　全てのCIサーバがCDをネイティブにサポートしているわけではないが、プラグインやシェルスクリプトを使うことでCDを実行できるようになる。デプロイメントを自動化するツールには、HashiCorpの「Terraform」、Amazon Web Services（AWS）の「CloudFormation」、Chefの「Chef」、Puppetの「Puppet」、オープンソースの「Ansible 」などがある。Terraformは、「AWS」「Microsoft Azure」「Google Cloud Platform」などの多数のクラウドプラットフォームの環境構成とリリースをサポートしている。ただ、どのツールでも、デプロイするリソースの種類によってはインフラの構成に時間がかかることがあるので注意が必要だ。IaCツールを使用することで、デプロイメントプロセスを繰り返し再現できる。さらに、多くの場合、設定ファイルはバージョン管理されているため、開発者は必要に応じて簡単に修正を加えることができる。

主要なクラウドプロバイダーはDevOpsプロセスを網羅するIaCツールを提供している

　「Kubernetes」は、自動アプリケーションデプロイメント向けにスケーラブルで信頼性の高いプラットフォームを提供するため、CDプロセスにおいて極めて重要な役割を果たす。Kubernetesはコンテナ化されたアプリケーションをオーケストレーションし、分散システム全体でシームレスなアップデートとロールバックを保証する。CI/CDパイプラインに統合することで、Kubernetesはデプロイメントワークフローの効率を高め、効果を上げて、ダウンタイムを削減する。

　パイプライン全体ではセキュリティスキャンと脆弱性評価も実施する必要がある。例えば、静的アプリケーションセキュリティテストツールは開発プロセスの早い段階でソースコードを分析し、脆弱性を特定する。また、チームは、ビルドフェーズ中に動的アプリケーションセキュリティテストを使用して、実行中のアプリケーションに対する攻撃をシミュレートし、セキュリティの欠陥を明らかにできる。コンテナイメージスキャンでは、デプロイメント前にコンテナ化された環境の脆弱性をチェック可能だ。

　ベンダー各社がソフトウェアデリバリーのライフサイクルの中でデータの取り込み、分析、表示の画期的手法を模索する中、CI/CT/CDプロセスの全フェーズでMLOps（Machine Learning Operations）と機械学習への期待が高まっている。

　CI/CT/CDによって「完了までに多くの時間がかかる上、人為的エラーを引き起こす手作業のプロセス」を排除し、ツールとプロセスのセットを自動化することで、本番環境への安全なデプロイメントを実現する。開発チームはDevOpsパイプラインを利用することで、運用やメンテナンスにおいて想像力に欠ける定型的な仕事から解放され、ソフトウェアデリバリーにおけるより戦略的な仕事に専念できるようになるだろう。