9. CI/CDとパイプライン

パイプラインは、プルリクエストから本番環境に至るまでの流れをBuild.ioが管理する仕組みです。稼働中の本番環境に直接デプロイして動作確認するのではなく、定められたワークフローに沿って進めます。プルリクエストごとに独立した環境で確認し、ステージングで検証したうえで本番環境へプロモートする、という流れです。

この章では、パイプラインの設定と使い方、レビューアプリ、プロモーション、GitHubインテグレーション、自動テストについて説明します。

9.1 パイプラインの設定

1つのパイプラインに複数のBuild.ioアプリを接続し、1つのデプロイワークフローとしてまとめます。各アプリはレビュー、ステージング、本番環境のいずれかのステージに対応し、コードはこの順に流れます。

パイプラインの作成

ダッシュボードのドロップダウンボタン（New +）からNew Pipelineを選択し、パイプラインに名前を付けます。名前には通常、プロジェクト名またはサービス名を使用します。続いて、既存のアプリを該当するステージに追加します。

アプリがまだない場合は、ステージングアプリと本番アプリを先に作成し（セクション1.3を参照）、それをパイプラインにまとめます。

パイプラインのステージ

パイプラインには3つのステージがあります：

レビュー — プルリクエストから自動で作成される一時的なアプリ。マージ前のテストとコードレビューに使用します（セクション9.2を参照）。

ステージング — 本番環境の直前に位置する環境。メインブランチにマージされたコードは、ここに自動でデプロイされます。最終的なQA、統合テスト、デモを行う場所です。

本番環境 — 実際のユーザーにサービスを提供するライブ環境。ここにデプロイされるコードはステージングからプロモートしたものに限られ、ビルドの再実行は行われません（セクション9.3を参照）。

3つすべてを使用する必要はありません。レビューアプリを省略してステージングへ直接デプロイするチームもあれば、アプリを1つだけ運用してパイプラインを使わないチームもあります。チームのワークフローに合うステージを選択してください。

パイプラインの可視性

ダッシュボードのパイプラインビューでは、パイプライン全体の状態を1画面で確認できます。各ステージにデプロイされている内容、どのコミットがどのステージで稼働しているか、ステージングが本番環境より先に進んでいるかが分かります。リリース待ちの変更が残っていないかも、この画面で把握できます。

9.2 レビューアプリ

レビューアプリは、プルリクエストが作成されるとBuild.ioが自動で用意する、一時的で独立した環境です。PRごとに専用のURLを持つアプリが起動するため、マージ前に、実際に稼働している状態で変更を確認・テストできます。

レビューアプリの仕組み

パイプラインでレビューアプリが有効な場合：

1. 開発者が、接続されたリポジトリに対してプルリクエストを作成します。
2. Build.ioがPRを検出し、そのブランチから新しいアプリを作成します。
3. レビューアプリがビルドとデプロイを経て、一意のURLを割り当てられます。
4. そのURLはGitHubのプルリクエストに投稿されるため、レビュアーはそこから直接アクセスできます。
5. PRがマージまたはクローズされると、レビューアプリは自動で削除されます。

プルリクエストごとに動作確認ができます。レビュアーはブランチをプルしてローカルで実行する手間が不要になり、ステージングや本番環境と同じ構成の環境で変更内容を確認できます。

レビューアプリの設定

レビューアプリはダッシュボードのパイプライン設定から有効にします。設定できる項目は次のとおりです。

自動作成 — すべてのPRでレビューアプリを作成するか、手動でトリガーしたときのみ作成するかを選択します。全PRをレビューできる状態にしておきたい場合は、自動作成が適しています。ただし、PRの本数が多いリポジトリでは、レビューアプリが消費するリソースを抑えるため、手動作成を推奨します。

自動削除 — PRがクローズされると、レビューアプリは削除されます。加えて、陳腐化のしきい値も設定できます。指定した日数を超えて更新のないレビューアプリは、自動で削除されます。

Config Var — レビューアプリには、アプリに環境変数として渡される設定値（Config Var）が独自に用意されています。Reveal Environmentをクリックすると確認できます。

9.3 ステージングと本番環境のプロモーション

プロモーションは、コードをステージングから本番環境へ移す操作です。ステージングで稼働しているコンテナを、そのまま本番環境にデプロイします。本番ブランチからの再ビルドは行われないため、テストしたものがそのまま公開されます。

プロモーションの仕組み

プロモーション時、Build.ioは新しいビルドをトリガーしません。ステージングで稼働中のスラグ（ビルド済みのアプリをまとめた成果物）をそのまま取得し、本番環境にリリースします。同一のアーティファクトをリリースするため、ステージングでは動作したのに本番環境では動作しないといった問題は発生しません。

環境ごとに異なるのはConfig Varのみです。たとえばステージングアプリはステージング用のデータベースとサンドボックスの決済プロバイダーを参照し、本番アプリはどちらも本番用のものを参照します。コードと依存関係は同一です。

ダッシュボードからのプロモーション

まだプロモートしていないスラグがステージングで稼働している場合、パイプラインビューのステージングアプリの隣にPromoteボタンが表示されます。クリックして内容を確認すると、プロモーションは数秒で完了します。

プロモートしない場合

リリースできる状態にないコードがステージングで稼働している場合は、プロモートせずにそのまま置いておきます。プロモーションの前に、マージ済みのPRを複数ステージングに蓄積しておくこともできます。マージのたびにプロモートする必要はありません。1日に数回プロモートするチームもあれば、変更をまとめて週に1度プロモートするチームもあります。頻度はリリースプロセスに合わせて決定してください。

本番環境を以前のリリースに戻す場合は、本番アプリのActivityタブから操作します。リリースはすべて記録されているため、過去のどのリリースにも戻せます。

9.4 GitHubインテグレーション

Build.ioはGitHubと直接連携して、リポジトリとアプリを接続し、自動デプロイを有効にし、レビューアプリを稼働させます。

リポジトリの接続

アプリのDeployタブでConnectionセクションを開きます。GitHub Organizationを選び、リポジトリを検索してConnectをクリックします。接続されると、そのリポジトリに対するプッシュやPRをBuild.ioが検知するようになります。

アプリ1つにつき、接続できるGitHubリポジトリは1つです。ただし、必要であれば複数のアプリを同じリポジトリに接続できます。たとえば、同じパイプラインのステージングアプリと本番アプリが1つのリポジトリを共有するケースです。

自動デプロイ

リポジトリを接続すると、特定のブランチを対象に自動デプロイを有効にできます。そのブランチにコードがプッシュされると、Build.ioが新しいビルドを実行し、結果をそのままデプロイします。

最も多い構成は、メインブランチからステージングアプリへの自動デプロイです。マージしたPRは、手動操作なしでステージングにデプロイされます。一方、本番環境へは自動デプロイせず、プロモートによってリリースします（セクション9.3を参照）。変更がユーザーに届く前に、明示的なゲートを1つ設ける構成です。

手動デプロイ

デプロイのタイミングを自分で制御する場合は、Deployタブから手動でトリガーできます。デプロイするブランチを選択し、Deploy Branchをクリックします。デプロイを毎回人の手で開始したい本番アプリや、一時的なテストのためにフィーチャーブランチをステージングへデプロイする場合に有効です。

GitHubでのデプロイステータス

Build.ioはデプロイの状況をGitHubへ通知します。進行中、成功、失敗のいずれの状態も、該当するコミットとプルリクエストの画面に表示されます。コードレビューを行う画面上で、そのままデプロイ結果を確認できます。

9.5 自動テスト

Build.ioにはCIが組み込まれています。コードをビルドしてデプロイするのと同じプラットフォーム上で、テストスイートも実行できます。すでに外部のCIプロバイダーを使用している場合は、そのまま継続して利用できます。どちらの方式にも対応しています。

Build.io CI

テストスイートは、パイプラインのワークフローの一部として自動で実行されます。ビルドがトリガーされるのは、PR、メインブランチへのプッシュ、手動デプロイのいずれかが発生したときです。このタイミングで、デプロイを進める前にテストを実行できます。

これにより、ワークフローが1か所にまとまります。プッシュ、ビルド、テスト、デプロイのすべてがBuild.io上で完結します。別のCIサービスの設定、CIランナーのインフラの管理、複数システム間の整合を取る作業は不要です。

CIの設定はダッシュボードのアプリのSettingsタブで行います。Enable CIチェックボックスをオンにし、Reveal Environmentをクリックして必要なConfig Varを設定します：

外部CIプロバイダーの使用

チームがすでにGitHub Actions、CircleCI、その他のCIサービスを使用している場合も、Build.ioとそのまま組み合わせて利用できます。Build.ioはGitHubのコミットステータスチェックを監視し、その結果に応じてデプロイを実行するか停止するかを判断します。

典型的なワークフロー

Build.io CIを使用する場合でも、外部プロバイダーを使用する場合でも、ワークフローの流れは同じです：

1. 開発者がプルリクエストを作成します。
2. Build.io CIまたは外部プロバイダーで、テストスイートが実行されます。
3. Build.ioがレビューアプリを作成し、チームは稼働中の変更を確認します。
4. GitHub上のコードと、稼働中のレビューアプリの両方をレビューします。
5. テストが成功しPRが承認されたら、マージします。
6. マージを契機に、ステージングへの自動デプロイが実行されます。
7. 必要に応じて、ステージングに対して追加の統合テストを実行します。
8. チームが問題ないと判断したら、ステージングを本番環境にプロモートします。

デプロイ前にCIを待つ

自動デプロイを使用している場合は、CIが成功するまでデプロイを待機するようにBuild.ioを設定できます。これにより、失敗したビルドが自動でステージングへデプロイされることを防げます。設定はDeployタブのAutomatic Deploysセクションから行います。デプロイ前にCIステータスを待機するオプションを有効にしてください。

Build.io CIでは、この待機が標準の動作です。テストはビルドの一部として実行され、失敗した時点でデプロイが停止します。外部プロバイダーの場合は、Build.ioがGitHubのコミットステータスチェックを参照し、必須チェックがすべて成功したときのみ処理を進めます。CIが失敗した場合はデプロイがスキップされ、失敗のステータスがGitHubとBuild.ioのダッシュボードの両方に表示されます。

デプロイ後のチェックの実行

ステージングにデプロイしたあと、稼働中のステージングアプリに対して軽量なスモークテストや統合テストスイートを実行するチームもあります。目的は、本番環境に近い条件でしか再現しない問題を検出することです。ネットワーク依存、実際のアドオン接続、環境固有の設定などが該当します。

実行のトリガーは2通りあります。1つは、デプロイ後のステップとしてBuild.io CIから実行する方法です。もう1つは、外部CIプロバイダーからWebhookまたはスケジュールされたジョブでステージングURLにアクセスし、重要なパスを確認する方法です。スモークテストが失敗した場合は、本番環境へプロモートしません。