3. アプリケーションのデプロイ

ソースコードをBuild.ioにデプロイすると、アプリケーションがビルドされ、インターネットからアクセスできるサービスとして稼働します。ダッシュボードでGitHubリポジトリを接続すれば、ビルドからリリース、実行までの処理はBuild.ioが担います。そのため、コードを書くことに専念できます。

この章では、デプロイ前の準備から、リリースフェーズやカスタムビルドパックを利用した高度なデプロイワークフローまでを説明します。

3.1 デプロイに向けたアプリケーションの準備

デプロイを滞りなく完了するには、アプリケーションがいくつかの要件を満たしている必要があります。いずれも現在のWebアプリケーションでは標準的な構成です。すでに満たしている場合も少なくありません。

GitHubでコードをホストする

Build.ioは、GitHubリポジトリから直接アプリケーションをデプロイします。アプリケーションのコードは、自身がアクセスできるGitHubリポジトリに配置してください。個人アカウントのリポジトリでも、所属組織のリポジトリでもかまいません。

プロジェクトをまだGitリポジトリとして初期化していない場合は、次の手順で初期化し、GitHubへプッシュします：

$ cd my-app
$ git init
$ git add .
$ git commit -m "Initial commit"
$ git remote add origin https://github.com/you/my-app.git
$ git push -u origin main

デプロイの対象は、実行時点でGitHubリポジトリに存在するコードです。ローカルにのみ存在する変更は反映されないため、デプロイの前に必ずコミットとプッシュを済ませてください。

依存関係の宣言

アプリケーションが必要とする依存関係は、言語またはフレームワークごとの標準的な依存関係ファイルで宣言します：

これらのファイルは、リポジトリのルートディレクトリに配置してください。配置されたファイルをもとに、Build.ioがアプリケーションの言語を判別し、ビルドの過程で必要な依存関係をインストールします。

Procfileの追加

アプリケーションの起動方法は、Build.ioが自動で判別できる場合が多くあります。ただし、Procfileを追加すると、アプリケーションを実行するコマンドを明示的に指定できます。Procfileは、リポジトリのルートに配置する拡張子なしのテキストファイルで、ファイル名もProcfileとします。

たとえば、Webサーバーにpumaを使用するシンプルなRuby Webアプリケーションでは、次のように記述します：

web: bundle exec puma -C config/puma.rb

Procfileとプロセスタイプは、セクション3.4で詳しく説明します。

設定値を環境変数から読み取る

twelve-factor appの方法論では、設定値をコードに直接記述せず、環境変数から読み取ることが推奨されます。データベースURL、APIキー、フィーチャーフラグなど、環境ごとに異なるすべての設定値が対象です。

これらの値は、アプリに環境変数として渡される設定値（Config Var）として管理できます。Config Varは、実行時にアプリの環境へ安全に注入されます。設定と編集は、アプリのSettingsタブから行います：

3.2 デプロイ

Build.ioは、ダッシュボードで接続したGitHubリポジトリから直接アプリケーションをデプロイします。リポジトリの接続は、最初に一度だけ行います。以降のデプロイは、手動で実行するか、GitHubへのプッシュを契機として自動で実行するかを選択できます。ここでは手動でのデプロイまでを扱います。自動デプロイの設定手順は、セクション3.4の「自動デプロイの有効化」を参照してください。

ステップ1：アプリを作成する

ページ右上のアバターの隣にあるドロップダウンボタン（New +）をクリックし、表示されたメニューからNew Appを選択します。

表示されたページでアプリの名前を入力し、利用するリージョン（例：us-east-1）を選択します。Create Appをクリックして次に進みます。

作成したアプリの概要ページが表示されます。ページ上部のタブから、アプリの各種設定を管理できます。

ステップ2：スタックを選択する

Settingsタブをクリックし、Stackセクションを開きます。推奨されるビルドパック方式でアプリをビルドする場合は、最新のHerokuスタックを選択します。

スタックは、アプリケーションのベースOSとランタイム環境を決定します。ほとんどのアプリケーションでは、デフォルトのスタックで必要な要件を満たせます。

ステップ3：ビルドパックを設定する

Settingsタブをさらに下にスクロールし、Buildpacksセクションを表示します。アプリケーションに必要な言語またはフレームワーク固有のビルドパックを追加します。

たとえばRubyアプリケーションをデプロイする場合は、GitHubリポジトリへのフルパスを指定して、公式のHeroku Rubyビルドパックを追加します：

https://github.com/heroku/heroku-buildpack-ruby

多くの一般的な言語では、Build.ioが適切なビルドパックを自動で検出します。ただし、ビルドパックを明示的に指定すると、より細かく制御でき、ビルド結果の一貫性も確保できます（セクション3.3を参照）。

ステップ4：GitHubリポジトリを接続する

Deployタブをクリックし、Connectionセクションを表示します。このセクションで、アプリとGitHubリポジトリを接続します。

ドロップダウンからGitHub Organizationを選択し、リポジトリ名で検索します。検索結果から、デプロイ対象のリポジトリの横にあるConnectをクリックします。

接続が完了すると、Connectionセクションに接続済みのリポジトリが表示されます。

ステップ5：デプロイ

Deployタブを下部のManual Deployセクションまでスクロールし、デプロイするブランチを選択してDeploy Branchをクリックします。

ビルドページに自動で移動します。アプリのビルド状況はリアルタイムで表示されます。アプリケーションタイプの検出、依存関係のインストール、コードのコンパイルが順に進む様子を確認できます。

ビルドが正常に完了すると、アプリは自動でデプロイされます。Overviewタブでは、最後にビルドとデプロイを実行した時刻を含め、アプリの状態を確認できます。右上のGoリンクをクリックすると、デプロイしたアプリが開きます。

3.3 ビルドパック

ビルドパックは、ソースコードをBuild.ioのインフラ上で実行可能な形式に変換します。使用している言語を判別し、依存関係を取得し、必要なコンパイル処理を実行して、ランタイム環境まで構築します。手動での設定は不要です。

ビルドパックの仕組み

処理は3つの段階に分かれます。最初の検出フェーズでは、リポジトリをスキャンし、使用している言語やフレームワークを示すシグネチャファイルを探します。RubyビルドパックはGemfile、Node.jsビルドパックはpackage.jsonを検出の手がかりとします。続くコンパイルフェーズでは、条件に一致したビルドパックが処理を引き継ぎます。依存関係をダウンロードし、必要に応じてアセットをコンパイルして、デプロイ可能な単位にまとめます。最後にリリースフェーズが、実行時にアプリケーションが必要とするデフォルト設定を出力します。

ダッシュボードでビルドパックを設定する

アプリのSettingsタブに移動し、Buildpacksセクションまでスクロールします。Add Buildpackをクリックし、公式ビルドパックの名前、またはカスタムビルドパックのGitHubリポジトリへのフルURLを入力します。

たとえば、公式のRubyビルドパックを追加するには：

https://github.com/heroku/heroku-buildpack-ruby

ビルドパックは、リストに表示された順に実行されます。ドラッグして順序を変更したり、不要になったビルドパックを削除したりできます。

複数のビルドパックの使用

複数のビルドパックを必要とするアプリケーションもあります。代表的な例は、アセットのコンパイルにNode.jsも必要とするRuby on Railsアプリケーションです。実行はリストの順に行われるため、後続のビルドパックは、先に実行されたビルドパックがインストールしたバイナリを利用できます。

たとえば、JavaScriptアセットを持つRailsアプリケーションの場合：

1. https://github.com/heroku/heroku-buildpack-nodejs
2. https://github.com/heroku/heroku-buildpack-ruby

サードパーティとカスタムビルドパック

公式ビルドパックが対応していない言語やフレームワークを使用する場合は、サードパーティのビルドパックを利用できます。SettingsタブのBuildpacksセクションで、そのビルドパックのGit URLを指定してください。

独自のビルドパックを作成し、カスタムのビルドプロセスや独自の言語に対応させることもできます。ビルドパックの実体は3つのシェルスクリプトです。bin/detectは、対象のコードベースにそのビルドパックが適合するかを判定します。bin/compileは、依存関係のインストールとアセットのコンパイルを実行します。bin/releaseは、ランタイム環境の設定を出力します。

3.4 Procfileとプロセスタイプ

Procfileは、アプリケーションの実行方法をBuild.ioに指定するファイルです。プロセス名と、そのプロセスを起動するコマンドを対応づける単純な構成ですが、Dynoの起動時の動作をここで細かく制御できます。

Procfileの基本

Procfile（拡張子なし、先頭は大文字のP）という名前のファイルを作成し、リポジトリのルートディレクトリに配置します。このファイルでは、1行が1つのプロセスタイプを定義します。書式は次のとおりです：

process_name: command to execute

たとえば、シンプルなWebアプリケーションでは次のように記述します：

web: bundle exec puma -C config/puma.rb

バックグラウンド処理を伴うアプリケーションでは、次のように複数のプロセスタイプを並べます：

web: bundle exec puma -C config/puma.rb
worker: bundle exec sidekiq

Webプロセスタイプ

すべてのプロセスタイプの中で、webだけは特別な役割を持ちます。Build.ioのルーティング層は、受信したHTTPリクエストをこのタイプのプロセスにのみ転送します。Webトラフィックに応答するアプリケーションでは、必ずwebプロセスを定義してください。

webプロセスは、$PORT環境変数で指定されたポートをリッスンする必要があります。Pumaを使用する場合は、通常config/puma.rbで設定します：

port ENV.fetch("PORT") { 3000 }

そのうえで、Procfileから次のように参照します：

web: bundle exec puma -C config/puma.rb

その他のプロセスタイプ

webプロセス以外にも、HTTPリクエストへの応答を伴わない処理のために、プロセスタイプを必要な数だけ定義できます。これらは独立したDynoとして動作します。バックグラウンドジョブの処理、定期実行タスク、長時間実行される処理に適した仕組みです。

代表的なユースケースをいくつか挙げます。

• キュー（SidekiqやResqueなどのツールを使用）からジョブを取得するワーカープロセス
• 一定の間隔で定期実行タスクを起動するクロックプロセス
• デプロイの過程で実行されるリリースプロセス

自動デプロイの有効化

継続的デプロイを行う場合は、GitHubの特定のブランチへプッシュしたタイミングで、Build.ioが自動でデプロイするよう設定できます。DeployタブでAutomatic Deploysセクションを表示します。対象のブランチを選択し、Enable Automatic Deploysをクリックします。

自動デプロイを有効にすると、対象ブランチへプッシュするたびに、新しいビルドとデプロイが実行されます。ダッシュボードを操作する必要はありません。

再デプロイ

アプリケーションの新しいバージョンをデプロイするには、変更をGitHubへプッシュします。自動デプロイが有効な場合は、Build.ioが新しいコミットを検出し、ビルドを自動で開始します。

手動デプロイを使用している場合は、Deployタブに移動し、Manual DeployセクションのDeploy Branchをクリックします。選択したブランチの最新コミットから、新しいビルドが開始されます。

特定のコミットをデプロイする

デフォルトでは、選択したブランチの最新コミットがデプロイされます。以前のバージョンへのロールバックなど、特定のコミットをデプロイする場合は、Activityタブを使用します。正常に完了した過去のビルドを一覧から選び、Rollback to hereをクリックします。

同じ履歴はCLIからも確認できます。bld builds -a my-appでアプリのビルドを一覧表示し、bld deployments -a my-appでデプロイメントを一覧表示します（現在のデプロイメントにはマークが付きます）。オプションの詳細についてはCLIコマンドリファレンスを参照してください。

3.5 コンテナ/Dockerデプロイ

Build.ioは、Dockerコンテナを直接デプロイする方式にも対応しています。カスタムのシステム依存関係、特定のランタイムバージョン、厳密に制御された環境などを必要とするアプリケーションが対象です。ランタイム環境を完全に制御しながら、Build.ioのマネージドインフラ、ルーティング、アドオンエコシステムをそのまま利用できます。

コンテナデプロイを使用する場合

コンテナデプロイは、次のような場合に適しています。

• 標準のBuild.ioランタイムでは利用できないシステムレベルの依存関係（FFmpeg、ImageMagick、カスタムライブラリなど）をインストールする
• 特定のLinuxディストリビューションまたはベースイメージを使用する
• 既存のDockerベースのワークフローを維持する
• Build.ioのビルドパックで公式にサポートされていない言語でアプリケーションを実行する

ただし、ほとんどのアプリケーションでは、ビルドパックによるデプロイのほうがシンプルです。ベースイメージのセキュリティアップデートも自動で適用されます。コンテナデプロイは、ビルドパックでは満たせない要件がある場合に限って使用してください。

Dockerfileデプロイの設定

ビルドパックの代わりにDockerfileを使用するには、アプリのスタック設定を変更し、リポジトリにDockerfileを追加します。

ステップ1：リポジトリにDockerfileを追加する

リポジトリのルートにDockerfileを作成します。Rubyアプリケーションのシンプルな例は次のとおりです：

FROM ruby:3.2-alpine
RUN apk add --no-cache build-base postgresql-dev yaml-dev ruby-dev
WORKDIR /app
COPY Gemfile Gemfile.lock ./
RUN bundle install
COPY . .
EXPOSE 3000
CMD ["bundle", "exec", "puma", "-C", "config/puma.rb"]

CMD命令は、アプリケーションの起動方法を定義します。この命令で起動するプロセスが、webプロセスとして扱われます。

ステップ2：スタックをDockerfileに設定する

ダッシュボードでアプリのSettingsタブに移動します。Stackセクションのドロップダウンからdockerfileを選択します。

この設定により、ビルドパックの自動検出と実行は行われません。ビルドにはDockerfileが使用されます。

ステップ3：デプロイ

スタックを設定し、Dockerfileをリポジトリにコミットしたら、Deployタブから通常と同じ手順でデプロイします。デプロイでは、Build.ioが次の処理を順に実行します：

• GitHubからソースコードをプルする
• リポジトリルートのDockerfileを検出する
• イメージをビルドする
• イメージをBuild.ioの内部レジストリにプッシュする
• コンテナをDynoにデプロイする

ビルドパックデプロイと同様に、ビルドの進行状況はビルドページでリアルタイムに確認できます。

Dockerfileデプロイでのプロセスタイプ

Dockerfileを使用する場合、Build.ioが作成するプロセスタイプは、イメージのCMDまたはENTRYPOINT命令に基づくwebプロセス1つのみです。Procfileから複数のプロセスタイプを読み取れるビルドパックデプロイとは、この点が異なります。

アプリケーションがバックグラウンドワーカーやその他のプロセスタイプを必要とする場合、対応方法は2つあります。1つは、同じイメージを異なるコマンドで実行する方法です。Resourcesタブで追加のプロセスタイプを設定し、それぞれのデフォルトコマンドを上書きします。もう1つは、ワーカーを独自のDockerfileを持つ別のアプリとして分離する方法です。構成が複雑な場合は、こちらを検討してください。

正しいポートでリッスンする

アプリケーションは、ビルドパックデプロイと同じくPORT環境変数で指定されたポートをリッスンする必要があります。この変数はBuild.ioが実行時に注入し、該当するポートへトラフィックをルーティングします。ポート番号をコードに直接記述せず、この環境変数から読み取ってください：

CMD ["bundle", "exec", "puma", "-C", "config/puma.rb", "-p", "$PORT"]

または、アプリケーションのサーバー設定ファイルで指定してください。

ベストプラクティス

イメージのサイズは小さく保ってください。可能な場合はAlpineベースのイメージを使用し、マルチステージビルドでビルド時とランタイムの依存関係を分離します。イメージが小さくなると、デプロイ時間が短縮され、コールドスタートのパフォーマンスも向上します。

Dockerfileのレイヤー構成も見直してください。依存関係ファイル（Gemfileやpackage.jsonなど）を先にコピーし、ソースコード全体のコピーはその後に記述します。この順序であれば、Dockerが依存関係のインストールレイヤーをキャッシュし、依存関係が変更されたときにのみ再ビルドします。

ベースイメージには、latestではなく明示的なバージョンタグを常に指定してください。ビルドの再現性が確保され、ベースイメージが更新された際の予期しない変更も避けられます。

3.6 リリースフェーズとフック

アプリケーションによっては、デプロイのたびに実行する必要のある処理があります。データベースのマイグレーション、キャッシュのクリア、CDNへのアセットのアップロードなどです。こうした処理のためのフックがリリースフェーズです。コードのビルドが完了した後、新しいDynoがトラフィックを受け付ける前に実行するコマンドを指定できます。

リリースフェーズの仕組み

リリースフェーズを設定したデプロイでは、まずコードがコンパイルされ、デプロイ可能なスラグ（ビルド済みのアプリをまとめた成果物）が作成されます。続いて、新しいDynoの起動に先立ち、一時的なOne-off Dyno上でリリースコマンドが実行されます。コマンドが正常に完了すると（終了コード0）、新しいバージョンが公開されます。

コマンドが失敗した場合は、デプロイがその時点で完全に停止します。新しいバージョンへの切り替えは行われません。稼働中のバージョンがそのまま動作を継続します。

リリースフェーズの定義

Procfileにreleaseプロセスタイプを追加します：

release: bundle exec rails db:migrate
web: bundle exec puma -C config/puma.rb

バックグラウンドワーカーを持つアプリケーションの場合：

release: bundle exec rails db:migrate
web: bundle exec puma -C config/puma.rb
worker: bundle exec sidekiq

リリースコマンドは、データベース接続文字列やその他のシークレットを含め、アプリのすべてのConfig Varにアクセスできます。

一般的なリリースフェーズのタスク

リリースフェーズの主な用途は次のとおりです。

• データベーススキーマのマイグレーション — リクエストの処理を開始する前に、データベース構造を新しいコードに合わせる
• コンパイル済みアセットのアップロード — CSS、JavaScript、画像をCDNまたはオブジェクトストレージへ送信する
• キャッシュのプライミングまたは無効化 — 新しいデータでキャッシュをウォームアップする、または古いエントリをクリアする
• データ変換スクリプトの実行 — 新しいコードが前提とする形式に合わせて、データをバックフィルする、レコードを更新する
• デプロイ通知の送信 — 新しいバージョンがデプロイされることを外部サービスに通知する

失敗したリリースの再試行

リリースの失敗がコードの問題ではなく、一時的な障害（データベースに接続できないなど）に起因する場合は、デプロイをそのまま再試行できます。Deployタブに移動してDeploy Branchをクリックすると、同じコミットから新しいビルドとリリースが実行されます。

設計上の考慮事項

リリースフェーズを使用する際に注意すべき点は、実行のタイミングです。リリースコマンドは、新しいコードを含むOne-off Dyno上で、新しいDynoが起動する前に実行されます。したがって、リリースコマンドの実行時点で、新しいコードが現在のデータベースの状態と互換である必要があります。

データベースマイグレーションは、後方互換性を保つように設計してください。デプロイをロールバックした場合でも、以前のバージョンのコードを正常に動作させるためです。推奨される手順は次の3段階です。

1. 追加のみの変更（新しい列やテーブルの追加）を先に適用する
2. 新旧どちらのスキーマでも動作するコードをデプロイする
3. すべてのコードが新しいスキーマを使用するようになった後、後続のリリースで古い列やテーブルを削除する

3.7 Gitでのデプロイ

Build.ioのアプリには、それぞれ専用のGitリモートが用意されています。このリモートにブランチをプッシュすると、ソースコードのアップロード、ビルドパックによるビルド、リリースが順に実行されます。処理の流れはダッシュボードからのデプロイと同じで、すべての操作をターミナルから行えます。

この方法は、ダッシュボードでGitHubリポジトリを接続する方法（セクション3.2）の代わりとして利用できます。どちらの方法を使ってもかまいません。1つのアプリで両方を併用することもできます。

事前準備

GitとBuild CLIをインストールしたうえで、ログインしてください：

$ bld login

bld loginを実行すると、APIホストとGitホストの認証情報が~/.netrcに書き込まれます。追加の設定は不要で、ログイン後すぐにgit pushを実行できます。

また、プロジェクトがGitリポジトリである必要があります。まだ初期化していない場合は、次の手順で初期化します：

$ cd my-app
$ git init
$ git add .
$ git commit -m "My first commit"

Build.ioのGitリモートを追加する

アプリのプッシュ先URLは、bld apps:infoで取得できます。取得したURLをGitリモートとして追加します：

$ GIT_URL=$(bld apps:info -a example-app -j | jq -r '.git_url')
$ git remote add build "$GIT_URL"

この手順は、クローンごとに1回だけ実行します。アプリをまだ作成していない場合は、先に作成してください：

$ bld apps:create example-app -t my-team

リモート名を変更する

リモート名はローカルでのみ使われる名前で、Build.io側の動作には影響しません。複数のリモートを使う場合は、環境名を含む名前に変更しておくと区別しやすくなります：

$ git remote rename build build-staging

コードをデプロイする

デプロイするブランチを、リモートのmainブランチにプッシュします：

$ git push build main

Build.ioがデプロイするのは、リモートのmainブランチだけです。ローカルで別の名前のブランチからデプロイする場合は、ローカルブランチ:リモートブランチの形式で指定します：

$ git push build my-feature:main

デプロイされるのはコミット済みのコードだけです。未コミットの変更や、ステージされていない変更は対象外です。

プッシュが完了したら、次のコマンドでリリースが正常に起動したかを確認してください：

$ bld ps -a example-app
$ bld logs -a example-app

複数の環境を使い分ける

Git URLはアプリごとに割り当てられます。そのため、ステージング用と本番用のアプリを使い分けるには、同じリポジトリに2つのリモートを追加します：

$ git remote add build-staging $(bld apps:info -a example-app-staging -j | jq -r '.git_url')
$ git remote add build-production $(bld apps:info -a example-app -j | jq -r '.git_url')

デプロイ時は、対象となる環境のリモートを指定してプッシュします：

$ git push build-staging main

ステージングと本番が同じパイプラインに属している場合は、両方にプッシュする代わりにプロモートを使用してください。プロモートでは、ステージングでビルド済みのスラグを下流のアプリに引き継ぐため、再ビルドは行われません：

$ bld pipelines:diff -a example-app-staging
$ bld pipelines:promote -a example-app-staging

パイプラインの詳しい使い方は、CI/CDとパイプラインを参照してください。

Gitの認証

Build.ioのGitリモートはSSHではなくHTTPSで接続するため、デプロイキーを管理する必要はありません。認証にはHTTP Basic認証を使用し、APIの認証情報で認証します。この認証情報は、bld loginの実行時に~/.netrcへ保存されます。

プッシュが認証エラーで失敗する場合は、認証情報の有効期限が切れている可能性があります。bld loginを再度実行して、認証情報を更新してください。

3.8 Deploy to Buildボタン

Deploy to Buildボタンを使うと、ダッシュボードで設定を行わなくても、誰でもワンクリックでアプリをBuild.ioにデプロイできます。オープンソースプロジェクトやスターターテンプレートのREADMEに設置すると、閲覧者は説明を読むだけでなく、実際にアプリを動かして試せます。

Build.ioのデプロイボタンは、Heroku Buttonの仕様に準拠しています。Herokuのデプロイボタンをすでに設置している場合、移行作業の中心はURLの書き換えです。ただし、app.jsonの扱いにはいくつか違いがあるため、後述の「app.jsonによるデプロイの設定」と「Herokuからの移行」を確認してください。

READMEへのボタンの追加

リポジトリのREADMEにボタン画像を追加し、Build.ioのデプロイエンドポイントへのリンクを設定します：

[![Deploy to Build](https://app.build.io/deploy-to-build-button.svg)](https://app.build.io/deploy?template=https://github.com/your-username/your-repo)

ボタンのサイズを指定する場合は、HTMLで記述します：

<a href="https://app.build.io/deploy?template=https://github.com/your-username/your-repo">
  <img src="https://app.build.io/deploy-to-build-button.svg" alt="Deploy" width="150px">
</a>

templateパラメータを省略した場合、Build.ioはブラウザのリファラーからリポジトリを判別します。ただし、この判別が機能するのは、GitHubのREADMEページからボタンがクリックされた場合に限られます。そのため、templateは常に明示的に指定することを推奨します。

ボタンをクリックすると、Build.ioの確認画面が表示されます。利用者はアプリ名、リージョン、Config Varを確認してから、デプロイを実行します。

URLパラメータ

デプロイエンドポイントでは、次のパラメータを指定できます。

• template — デプロイするGitHubリポジトリ。完全なURL（https://github.com/your-username/your-repo）、github.com/で始まるパス、owner/repoのいずれの形式でも指定できます。GitHubからのリファラーがある場合は省略できますが、明示的に指定することを推奨します（「READMEへのボタンの追加」を参照）。
• app[name] — 新しいアプリの名前の候補（例：app[name]=my-awesome-app）。名前の重複を避けるため、Build.ioは末尾に短いランダムな文字列を付加します。実際のアプリ名はmy-awesome-app-a1b2c3d4のようになります。
• app[region] — デプロイ先のリージョン（例：app[region]=us-east-1）。
• env[VARIABLE_NAME] — Config Varの値（例：env[DATABASE_URL]=postgres://...）。複数の変数を指定する場合は、パラメータを繰り返します（例：env[API_KEY]=abc123&env[SECRET_KEY]=xyz789）。
• express — trueを指定すると、確認画面を表示せずにデプロイを開始します。

デプロイされるのは、常にリポジトリのデフォルトブランチです。templateに/tree/my-branch、/blob/main/README.md、/pull/123などのパスが含まれていても、エラーにはならず、その部分は無視されます。このため、ボタンはリポジトリ内のどのページに設置してもかまいません。ただし、現時点では特定のブランチやタグを指定する方法はありません。

複数のパラメータを組み合わせた例は次のとおりです：

https://app.build.io/deploy?template=https://github.com/myorg/myapp&app[name]=production-app&app[region]=us-west-2&env[NODE_ENV]=production

app.jsonによるデプロイの設定

Build.ioは、リポジトリのapp.jsonをもとに、アプリの名前やメタデータ、Config Var、アドオン、ビルドパックを設定します。スキーマはHerokuのapp.jsonに準拠していますが、実装されていないフィールドもあります。Herokuで使用していたapp.jsonを移行する前に、サンプルの後に記載した相違点を確認してください。

{
  "name": "My Application",
  "description": "A sample application",
  "repository": "https://github.com/myorg/myapp",
  "keywords": ["productivity", "rails"],
  "env": {
    "WEB_CONCURRENCY": {
      "description": "The number of processes to run.",
      "value": "5"
    }
  },
  "addons": [
    "schema-to-go:basic"
  ],
  "buildpacks": [
    { "url": "heroku/ruby" }
  ]
}

Herokuのスキーマとの主な相違点は次の3つです。

• アドオンにはBuild.ioの名前を指定する。 アドオンがプロビジョニングされるのは、サービスとプランの両方がBuild.ioのカタログに存在する場合だけです。heroku-postgresql:hobby-devではなく、schema-to-go:basicのようにBuild.ioの名前を指定してください。カタログにない名前はエラーにならず、無視されます。この場合はアドオンなしでデプロイが完了するため、初回のデプロイ後にアプリのアドオンを確認してください。
• Config Varはapp.jsonではなくボタンのURLで指定する。 ボタンからのデプロイでは、app.jsonをもとにアプリが作成された後、Config Varが置き換えられます。そのため、envブロックの値はアプリに反映されず、URLのenv[...]で指定した値だけが反映されます。また、必須のConfig Varの入力を利用者に求める機能はなく、Herokuのgenerator: "secret"にも対応していません。シークレットは事前に生成し、env[...]で渡してください。envブロックは説明のために残しておいてもかまいませんが、その値はアプリに反映されません。
• scripts.postdeployは実行されない。 Build.ioはscripts.postdeployの内容を保存しますが、現時点では実行しません。マイグレーションなどの処理は、postdeployフックではなく、リリースコマンドまたは起動コマンドで実行してください。

ボタンからのデプロイではapp.jsonが必須で、buildpacks配列も記述する必要があります。通常のデプロイと異なり、ボタンからのデプロイではビルドパックが自動検出されないためです（セクション3.3を参照）。app.jsonがないリポジトリでは、app.jsonの追加を求めるメッセージが表示され、デプロイは失敗します。

Herokuからの移行

Build.ioのデプロイエンドポイントは、Herokuと同じURLパラメータに対応しています。既存のHerokuボタンを移行する場合は、まずURLを書き換えます。

変更前：

https://heroku.com/deploy?template=https://github.com/myorg/myapp

変更後：

https://app.build.io/deploy?template=https://github.com/myorg/myapp

env[...]とapp[...]のパラメータは、変更せずにそのまま使用できます。app.jsonについては、次の2点を修正してください。

1. Herokuのアドオン名を、対応するBuild.ioのアドオン名に変更する
2. scripts.postdeployで実行していた処理を、リリースコマンドまたは起動コマンドに移す

詳しくは「app.jsonによるデプロイの設定」を参照してください。