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

パイプラインはBuild.ioがプルリクエストから本番環境へのコードの旅をモデル化する方法です。ライブ環境に直接デプロイして結果を期待するのではなく、パイプラインはチームに構造化されたワークフローを提供します。変更を独立して確認し、ステージングで検証し、自信を持って本番環境にプロモートします。

このセクションでは、パイプライン、レビューアプリ、プロモーション、GitHubインテグレーション、自動テストの設定と使用方法を説明します。

9.1 パイプラインの設定

パイプラインは複数のBuild.ioアプリを単一のデプロイワークフローに接続します。パイプライン内の各アプリはステージ（レビュー、ステージング、本番環境）を表し、コードは順番にそれらを経由して流れます。

パイプラインの作成

ダッシュボードから**New +**ドロップダウンを見つけ、New Pipelineを選択します。パイプラインに名前（通常はプロジェクトまたはサービスの名前）を付け、既存のアプリを適切なステージに追加します。

最初から始める場合は、まずステージングと本番環境のアプリを作成し（セクション1.3を参照）、それらをパイプラインにグループ化します。

パイプラインのステージ

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

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

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

本番環境 — 実際のユーザーにサービスを提供するライブ環境。コードはステージングからのプロモーションによって本番環境に到達します。新しいビルドによってではありません。（セクション9.3を参照。）

すべての3つのステージを使用する必要はありません。一部のチームはレビューアプリをスキップして直接ステージングにデプロイします。シングルアプリでパイプラインを使用しないチームもあります。チームのワークフローに合ったステージを使用してください。

パイプラインの可視性

ダッシュボードのパイプラインビューは、各ステージにデプロイされているもの、どのコミットがどこで実行されているか、ステージングが本番環境より進んでいるかどうかを1つの画面で確認できます。これにより、リリース待ちの未リリースの作業があるかどうかを一目で確認できます。

9.2 レビューアプリ

レビューアプリは、プルリクエストを開いたときにBuildが自動的に作成する一時的な独立した環境です。各PRには独自のURLを持つアプリが割り当てられ、チームがマージ前に実際の実行環境で変更を確認・テストできます。

レビューアプリの仕組み

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

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

これにより、すべてのプルリクエストがライブでクリック可能なデモになります。レビュアーが「ブランチをプルしてローカルで実行する」必要はなく、ステージングと本番環境を反映した環境で変更が実行されている様子を見ることができます。

レビューアプリの設定

ダッシュボードのパイプライン設定からレビューアプリを有効にします。以下を設定できます：

自動作成 — すべてのPRに対してレビューアプリを自動的に作成するか、手動でトリガーするかどうか。自動作成はすべてのPRをレビュー可能にしたいチームには便利ですが、リポジトリのトラフィックが多い場合はリソースの使用を制御するために手動作成を好む場合があります。

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

設定変数 — レビューアプリには独自の設定変数があり、「Reveal Environment」ボタンをクリックしてアクセスできます。

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

プロモーションはコードがステージングから本番環境に移動する方法です。本番環境ブランチに対してアプリを再ビルドする代わりに、Buildはステージングで実行されているまったく同じコンテナを取得して本番環境にデプロイします。テストしたものが公開されます。

プロモーションの仕組み

プロモーション時、Buildは新しいビルドをトリガーしません。ステージングで現在実行されているスラグ（アプリのコンパイルされパッケージングされたバージョン）を取得して本番環境にリリースします。これにより、デプロイの問題のクラス全体が排除されます。ステージングで動作した場合、本番環境でも動作します。なぜなら同じアーティファクトだからです。

Config Varだけが環境間で異なります。ステージングアプリはステージングデータベースとサンドボックス決済プロバイダーを指し示すかもしれませんが、本番環境は実際のものを指し示します。コードと依存関係は同一です。

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

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

プロモートしない場合

ステージングがリリースする準備のできていないコードを実行している場合は、単にプロモートしないでください。ステージングはプロモーション前に複数のマージされたPRを蓄積できます。マージするたびにプロモートする必要はありません。一部のチームは1日に数回プロモートし、他のチームは変更をまとめて週に1度プロモートします。リリースプロセスに合ったペースを使用してください。

本番環境を以前のリリースにロールバックする必要がある場合は、本番環境アプリのActivityタブから行うことができます。各リリースが記録されており、任意の以前のものにロールバックできます。

9.4 GitHubインテグレーション

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

リポジトリの接続

アプリのDeployタブからConnectionセクションを見つけます。GitHub Organizationを選択し、リポジトリを検索し、Connectをクリックします。接続されると、BuildはそのリポジトリのプッシュとPRに応答できます。

各Build.ioアプリは1つのGitHubリポジトリに接続します。必要に応じて複数のアプリが同じリポジトリに接続できます（例えば、同じパイプライン内のステージングと本番環境のアプリが同じリポジトリに接続する）。

自動デプロイ

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

最も一般的な設定は、メインブランチからステージングアプリへの自動デプロイです。これにより、すべてのマージされたPRが手動の手順なしにステージングにデプロイされます。本番環境のデプロイはプロモーション（セクション9.3を参照）を通じて行われ、変更がユーザーに到達する前に明示的なゲートを提供します。

手動デプロイ

デプロイのタイミングを正確に制御したい場合は、Deployタブから手動でトリガーできます。デプロイしたいブランチを選択し、Deploy Branchをクリックします。これは本番環境アプリで各デプロイを手動で開始したい場合や、アドホックテストのためにフィーチャーブランチをステージング環境にデプロイする場合に便利です。

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

BuildはデプロイステータスをGitHubに報告します。デプロイが進行中、成功、または失敗した場合、ステータスはGitHub上の関連するコミットとプルリクエストに表示されます。これにより、チームは通常のコードレビューワークフローから直接デプロイ結果を確認できます。

9.5 自動テスト

Build.ioには組み込みのCIテストソリューションが含まれており、コードをビルドおよびデプロイするのと同じプラットフォームの一部としてテストスイートを実行できます。すでに外部のCIプロバイダーを使用している場合も問題ありません。Buildは両方のアプローチと統合します。

Build.io CI

Build.io CIはパイプラインワークフローの一部としてテストスイートを自動的に実行します。ビルドがトリガーされると（PRから、メインブランチへのプッシュから、または手動デプロイから）、Buildはデプロイが進む前にテストを実行できます。

これにより、ワークフロー全体が1か所にまとまります。コードがプッシュされ、ビルドされ、テストされ、別のCIサービスを設定したり、CIランナーインフラを管理したり、複数のシステム間で調整したりすることなく、Build.ioでデプロイされます。

ダッシュボードのアプリのSettingsタブからEnable CIチェックボックスにチェックを入れ、Reveal Environmentボタンの後ろに必要な設定変数を設定してCIを設定します：

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

チームがすでにGitHub Actions、CircleCI、または別のCIサービスを使用している場合、Build.ioはそれとスムーズに統合します。BuildはGitHubのコミットステータスチェックを監視し、その結果に基づいてデプロイをゲートできます。

典型的なワークフロー

Build.io CIを使用するか外部プロバイダーを使用するかにかかわらず、ワークフローは同じに見えます：

1. 開発者がプルリクエストを開きます。
2. テストスイートが実行されます。Build.io CIまたは外部プロバイダーで。
3. Buildがレビューアプリを作成するため、チームが実行中の変更を確認できます。
4. PRがレビューされます。GitHub上のコードと実行中のレビューアプリの両方。
5. テストが通過してPRが承認されたら、マージされます。
6. マージによりステージングへの自動デプロイがトリガーされます。
7. ステージングに対して追加の統合テストまたはスモークテストが実行されます。
8. チームが満足したら、ステージングが本番環境にプロモートされます。

デプロイ前にCIを待つ

自動デプロイを使用している場合、デプロイの前にCIが通過するのを待つようにBuildを設定できます。これにより、壊れたビルドが自動的にステージングに届かないことを確認できます。DeployタブのAutomatic Deploysからこれを有効にします。デプロイ前にCIステータスを待つオプションにチェックを入れてください。

Build.io CIを使用する場合、これはネイティブに処理されます。テストはビルドの一部として実行され、失敗するとデプロイが停止されます。外部プロバイダーを使用する場合、BuildはGitHubのコミットステータスチェックを監視し、すべての必要なチェックが通過した場合にのみ続行します。CIが失敗した場合、デプロイはスキップされ、GitHubとBuildダッシュボードの両方に失敗が表示されます。

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

ステージングへのデプロイ後、一部のチームはライブステージング環境に対して軽量なスモークテストまたは統合テストスイートを実行し、本番環境に似た設定でのみ現れる問題（ネットワーク依存関係、実際のアドオン接続、環境固有の設定）を検出します。

これはBuild.io CIのデプロイ後のステップとして、または外部CIプロバイダーからWebhookやスケジュールされたジョブを使用してステージングURLにアクセスし、重要なパスを確認することでトリガーできます。スモークテストが失敗した場合は、本番環境にプロモートしないようにします。