CI/CD パイプラインとは

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

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

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

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

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

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

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

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

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

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

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

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

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

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

これらのテストは、パイプラインを加速化してより素早くフィードバックを得られるように、並行して実行するとも可能です。

自動テストの結果に確実性を持たせるには、これらが一貫して実行することを保証する必要があります。

理想的に言えば、テスト環境はできるだけ本番に似せて構成されるべきであり、テストが実行されるたびに、環境上の矛盾によるテスト結果への影響を回避できるようにリセットされなければなりません。

仮想マシン（VM）はテスト中の新しいビルドごとにプロセスを初期化できるようにスクリプトすることができるため、長い間、テスト環境の実行に使用されてきました。

ところが、新しい VM を取り崩してスピンアップするには時間がかかる上、ソフトウェアが実行する必要のあるすべての依存関係を提供する仮想環境ごとの構成をスクリプトに含める必要があります。 新しい依存関係が追加されると、環境スクリプトも更新が必要となりますが、このような単純な作業は、ビルドが実行しない理由に悩まされるまで気づかないものです。

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

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

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

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

たとえば、テスト環境はビルドごとに更新しても、ステージング環境はそれほど頻繁にではなく、1 日に 1 回または 1 週間に 1 回のペースで、最新の成功ビルドを使用してリフレッシュするように決定することもできます。

コードの変更がパイプラインの手前の全ステージで合格すると、本番にリリースできるようになります。 この最後のステップは手動でも自動でも実施できます。

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

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

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

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

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

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

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

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

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

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