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

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

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

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

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

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

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

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

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

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

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

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