CI/CD パイプラインとは

実際のところ、継続的インテグレーション/継続的デリバリーパイプラインとは一体何なのでしょうか。それはどうすれば構築できるのでしょうか。

継続的インテグレーションとデリバリーおよびデプロイ(総称して CI/CD)について調べたことがある方なら、ほぼ必ずと言っていいほど「自動パイプライン」という用語に遭遇し、これらの手法を実践する際にそれが重要な役割を果たすことを学んだはずです。

CI/CD は品質を妥協することなく、より迅速にソフトウェアを提供できるようにする DevOps の手法です。CI/CD では変更を頻繫にコミットし、かかる更新を厳格にテストし、フィードバックに迅速に対応することが求められます。自動 CI/CD パイプラインの構築はこの工程において不可欠です。

CI/CD パイプラインの説明

CI/CD パイプラインとは、開発環境のコードをテストやステージングといったさまざまなステップを経て最終的にユーザーへ提供するプロセスを指します。

CI/CD はこのプロセスを定期的に(1 日単位や 1 時間単位で何度も)実行することを目的としています。そのため、CI/CD パイプラインをできる限り自動化することが重要です。あるステップが正常に完了したら、次のステップが自動的にトリガーされるようにする必要があります。ステップが失敗した場合は、フィードバックを迅速に伝えて問題を解決できるようにしなければなりません。

CI/CD パイプラインを自動化すると、ソフトウェアのビルド、テスト、およびデプロイの全体的なプロセスが高速化されるだけでなく、それぞれのステップを常に確実に実行させることができます。

ビルドパイプラインのステージ

CI/CD パイプラインの正確な構造は使用する製品と組織によって異なりますが、どんなパイプラインでも一般的には次のようなパターンが使用される傾向があります。

  1. プロセスはメイン(または CI ブランチに指定されたブランチ)へのコミットから始まり、それによってビルドまたは最初のユニットテストがトリガーされます。結果は通常、ダッシュボードで確認できます。パイプラインはビルドかテストが失敗したときに停止し、問題を解決してから続行できるように設計できます。修正がコミットされるとパイプラインが最初から自動的に再開されるため、すべてを意図したとおりに確実に機能させることができます。または、後で調査するための失敗フラグを立てながら処理を続行するようにパイプラインを構成することも可能です。
  2. 次のステージでは一連の自動テストが実施され、テストが行われるたびにフィードバックが提供されます。テストは一般的には構造化されており、最も簡単なテストを先に実行することで、可能な限り早い段階でフィードバックを提供できるようになっています。リソースを激しく消費するテストは最後に実行されますが、先行するすべてのステップがすべて成功した場合にのみ実行されます。このステージでも何らかのテストが失敗した場合、パイプラインを停止して最初から再開することも、後で調査するために問題を提起して続行することも可能です。
  3. 自動テストが完了すると、ソフトウェアは一般的に複数のステージング環境にデプロイされます。ステージング環境の一部はさらなる手動テストに使用されることも、トレーニング、サポート、および顧客プレビューの目的に使用されることもあります。
  4. CI/CD パイプラインアーキテクチャの最後のステージでは、変更が公開されます。リリースは手動(継続的デリバリーの場合)または自動(継続的デプロイの場合)のいずれかでトリガーされます。

では、各ステージでの主な考慮事項を詳しく見てみましょう。

フラグとブランチ

継続的インテグレーションを導入する際の最初のステップは、コードベース全体を Git、Mercurial、Perforce といったバージョン管理システム または VCS(ソースコントロール管理または SCM とも呼ばれます)に投入し、チーム全員に変更の頻繁なコミットを習慣付けさせることです。メインにコミットされるたびに継続的インテグレーションのパイプラインが開始され、コードのビルドとテストが行われ、最新の変更に対するフィードバックが迅速に提供されます。

CI/CD パイプラインでは頻繁なコミットを実践することが重要ですが、完成するまでに数日または数週間かかるような大規模な機能に取り組んでいる場合、その過程で定期的にコミットするのは少し非生産的に感じられるかもしれません。

その一方、増分変更を定期的にパイプラインに通せば迅速なフィードバックを得ることができます。また、機能が完成するのを待つよりも複雑なマージの競合が発生する可能性が下がります。

とは言え、未完成の機能をパイプラインに通すのはあまり現実的ではない可能性があります。ステージング環境でも未完成の作業をユーザーを共有するのは望ましくない場合もあります。

この問題については、フィーチャーフラグとフィーチャーブランチで対処できます。フィーチャーフラグを使用すると、コードがユーザーに公開される環境を指定できます。変更はそれでもメインにコミットされてチームに公開されますが、その機能がステージングと本番に公開されるタイミングを決めることはできます。

フィーチャーブランチを使うと、自動ビルドとテストのメリットを損なうことなく機能を別のブランチで開発できます。フィーチャーブランチにコミットされるたびに CI/CD パイプラインをトリガーすることで、作成した内容に対するフィードバックをメインへのコミットと同様に迅速に得ることができます。

ビルドとテスト

コミットによってパイプラインのインスタンスがトリガーされたら、次のステージであるビルドとテストに移行します。ユニットテストを自動化している場合、このテストは一般的にリントと静的解析チェックと共にビルド前に実行されます。

使用するビルドツール(Ant や Maven など)と詳しいビルドステップは、使用している言語とフレームワークによって異なります。専用のビルドサーバー自動ビルドを実行することで、依存関係の欠落による下流での問題、よくある「自分のマシンでは動作する」問題を回避することができます。

ビルドステップでは、インストーラー、バイナリ、またはコンテナーなどのアプリケーションのアーティファクトが生成されます。これらのアーティファクトはテスト環境にデプロイされ、統合テスト、コンポーネントテスト、エンドツーエンドテスト、およびパフォーマンスおよびセキュリティ解析などのより高度な自動テストを実行するために他のシステムコンポーネントと統合されます。

このようなテストを並列実行してパイプラインを加速させることで、より迅速にフィードバックを得ることもできます。

コンテナーと VM

自動テストの結果に信頼性を持たせるには、テストを確実に実行させる必要があります。

理想を言えば、テスト環境の構成を可能な限り本番環境のものに近づけ、環境の不整合が原因でテスト結果に影響が出ないよう、テストを実行するたびにテスト環境をリセットすべきです。

仮想マシン(VM)はテスト環境を実行するための選択肢として長らく人気を博してきました。新しいビルドをテストするたびに環境をリフレッシュする処理をスクリプト化できるからです。

しかし、環境を破棄して新しい VM を起動するには時間がかかります。さらに、各仮想環境のスクリプトにはソフトウェアの実行に必要なすべての依存関係を提供する構成を含めなければなりません。新しい依存関係が追加された場合は環境スクリプトを更新する必要がありますが、このような簡単なことはビルドが動作しない理由に悩むまでは気づかないものです。

このような問題は、最初のビルドステップにコードをコンテナーにパッケージ化する処理を組み込むことで回避できます。コンテナーにはソフトウェアが実行する必要のあるすべての依存関係が含まれるため、非常に移植しやすく、別の環境に簡単にデプロイすることができます。

自己所有のインフラストラクチャで CI/CD パイプラインを運用している場合はコンテナーのデプロイ先となる VM が必要となりますが、テスト環境の準備にかかる手間は少なくなります。クラウドでパイプラインを実行している場合はコンテナーを使用することで、マネージドサービスを利用してインフラストラクチャの管理をクラウドプロバイダーに任せることができます。

本番前環境

パイプラインアーキテクチャ内のテスト環境とステージング環境の数は構築しているものと組織内のさまざまな関係者グループのニーズによって異なります。探索的テスト、セキュリティレビュー、ユーザー調査、販売デモ、トレーニング環境、およびサポートスタッフが顧客の問題を再現するために使用するサンドボックスなどが例として挙げられます。

これらの環境を自動的に作成し、そこへ自動的にデプロイするほうが手動でリフレッシュするよりも効率的です。また、環境ごとに異なるパイプライントリガーを構成することもできます。

たとえば、テスト環境はビルドごとに更新しても、ステージング環境は 1 日に 1 回または 1 週間に 1 回のペースといった比較的低い頻度で最新の成功したビルドを使用してリフレッシュする方針にすることもできます。

デプロイ

コードの変更は先行するすべてのパイプラインステージで合格した後に本番にリリースできるようになります。この最後のステップは手動でも自動でも実施できます。

手動でのリリース(継続的デリバリー)は以下の場合に役立ちます。

  • 新しい機能が公開されるタイミングを制御したい場合。
  • デプロイ作業に伴ってユーザー側のダウンタイムが発生する場合。
  • ユーザーが製品をインストールする必要があり、定期的なリリーススケジュールに沿って変更を一括で配布したい場合。

継続的デプロイの場合、リリースは自動で行われます。変更は先行するすべてのステージで合格している場合に公開されます。コミットの頻度が高い比較的大規模なチームはこれを利用することで、1 日に何度も更新をユーザーにデプロイできます。これは自動パイプラインが構成されていない場合はほぼ不可能な離れ業です。

CI/CD パイプラインの概要の理解

CI/CD は自動化を使用してソフトウェア開発ライフサイクルの各ステージで迅速にフィードバックを提供するための DevOps のプラクティスです。最近のコード変更が原因で発生した問題を検出することで、ソフトウェア開発の効率を向上させます。シフトレフト(より早く対応してより早くフィードバックを得る)を実践することでフェイルファストを実践できるようになります。また、パイプラインを自動化すると、これらの手法を実践に採り入れやすくなります。

独自の CI/CD プロセスを設計する際には、継続的インテグレーションから着手して段階的に構築することをお勧めします。パイプラインの実際のステージと、それぞれのステージがトリガーされるタイミングを決めるロジックは製品と組織によって異なります。

独自の要件に応じてパイプラインを柔軟に構成可能ながらも管理しやすい CI/CD プラットフォームを選択すると、信頼できるリリースプロセスを築き、ソフトウェアの品質を改善できるようになります。

TeamCity のメリット

TeamCity Pipelines ソリューションを使用すると、既存の CI/CD プロセスを自動化できます。

すべての主要バージョン管理システムのサポートと一般的なビルド、テスト、およびパッケージ管理ツールの統合が備わった TeamCity Pipelines では、開発ワークフローを効率的な自動パイプラインに変換することができます。

柔軟なトリガーオプションと視覚的なパイプラインエディターを利用できるため、あらゆるワークフローに適したパイプラインを簡単に構成できます。構成はコードとして自動的に保存されるため、GUI で自由にパイプラインを構築して管理しながら、構成をコード化するメリットを活かせます。

TeamCity のオンプレミスとクラウドに固有のデプロイオプションがあるため、必要なときに柔軟にパイプラインを実行し、オンデマンドで拡張できます。テスト並列化などの機能やリアルタイムのフィードバックによって早い段階で失敗することができるため、開発の生産性が向上します。

まだご質問等がございますか?FAQ セクションをご覧ください。