Last updated 06 May 2019

既存のアプリケーション (アドオン、環境設定、Heroku Postgres データを含む) をコピーするには、heroku fork​ を使用します。

アプリケーションごとに複数の環境​を保持することは一般的な習慣です。たとえば、アプリごとのステージングおよび本番環境のほか、開発のさまざまな段階での機能のための任意の数の一時的なテスト環境があります。アプリケーションにまたがる同等性を確保するには、本番環境からのフォークとして新しいアプリを作成します。

セットアップ

ここに記載の機能を使用するには、Heroku CLI​ がインストールされている必要があります。CLI がインストールされていることを検証​し、heroku update​ で最新バージョンに更新してください。

アプリケーションのフォーク

heroku fork​ を呼び出すと、ターゲットアプリが作成され、すべての Heroku Postgres データと環境設定が新しいアプリにコピーされた後、すべてのアドオンが同じプランで再プロビジョニングされます。データベースのサイズによっては、このプロセスに時間がかかる可能性があります。

$ heroku fork --from sourceapp --to targetapp
Creating fork targetapp... done
Copying slug... done
Adding heroku-postgresql:dev... done
Creating database backup from sourcapp... .. done
Restoring database backup to targetapp... .. done
Copying config vars... done
Fork complete, view it at http://targetapp.herokuapp.com/

アプリをデフォルト以外のリージョン​にフォークするには、--region​ フラグを使用します。

$ heroku fork --from sourceapp --to targetapp --region eu

アドオンの失敗

一部のアドオンは、使用できなくなっている場合、プロビジョニングに失敗することがあります。

$ heroku fork --from sourceapp --to targetapp
Creating fork targetapp... done
Copying slug... ........ done
Adding airbrake:developer... done
Adding bonsai:test... skipped (not found)
...

元のプランが存在しなくなったためにアドオンをプロビジョニングできない場合は、ソースアプリ上のプランをアップグレードし、フォークを再試行してください。

$ heroku addons:upgrade bonsai:starter -a sourceapp
Upgrading to bonsai:starter on sourceapp... done, v207 (free)

アドオンの手動設定

一部のアドオンでは、プロビジョニングの後に追加の設定が必要です。一覧表示されている他にもアドオンが存在する可能性があるため、使用しているアプリのアドオンに、手動で入力される設定を持つものがないかどうか確認してください。

Heroku Postgres

アプリケーション上の Heroku Postgres データベースはすべて、pg:copy​ を使用して sourceapp​ からターゲットアプリにコピーされます。このために Heroku Postgres のフォーキング​は使用されません。フォロワーが存在する場合は、これにより、現在はリーダーデータベースに従っていない重複したコピーが生成されます。

よりサイズの大きなデータベースの場合、このステップには長時間かかります。このステップは、--skip-pg​ フラグを渡すことによってスキップできます。

$ heroku fork --from sourceapp --to targetapp --skip-pg

--skip-pg​ フラグを指定すると、ターゲットアプリ上に Heroku Postgres データベースは作成されません。これは、heroku fork​ の後に手動で作成できます。または、Heroku Postgres のフォーキングを使用することもできます。

カスタムドメイン

カスタムドメインは同時には 1 つのアプリにしか属することができないため、カスタムドメインはフォーキングプロセスの一部としてはコピーされません。新しい環境でカスタムドメイン​を使用する場合は、自分で追加し、必要な DNS の追加を行う必要があります。

SSL

フォーキングプロセスは targetapp​ で SSL エンドポイント​を再プロビジョニングしますが、ユーザーの代わりに証明書を追加することはありません。アプリが SSL でカスタムドメインを使用する場合は、targetapp​ 上の SSL エンドポイントインスタンスに新しい証明書​を追加する必要があります。

$ heroku certs:add server.crt server.key -a targetapp
Resolving trust chain... done
Adding SSL Endpoint to targetapp... done
example now served by tokyo-1234.herokussl.com

HTTPS 経由でリクエストを処理するために、この新しいエンドポイント URL を利用する新しい DNS CNAME レコードを追加します。

スケジューラー

Heroku Scheduler​ アドオンでは、ジョブスケジュールを手動で転送する必要があります。sourceapp​ と targetapp​ の両方で横並びでスケジューラーダッシュボードを開き、diff を表示して手動でジョブをコピーします。

$ heroku addons:open scheduler -a sourceapp
$ heroku addons:open scheduler -a targetapp

デプロイ

アプリケーションのフォーキングによって、現在のプロジェクトに新しい Git リモートが自動で作成されることはありません。targetapp​ にデプロイを行うには、ユーザー自身が Git リモートを確立する必要があります。heroku info​ を使用して新しいアプリケーションの Git URL を取得し、手動で設定します。

$ heroku info -a targetapp
=== targetapp
...
Git URL:       git@heroku.com:targetapp.git
...

targetapp​ のデプロイ URL を表す forked​ という名前の Git リモートを追加します。

$ git remote add forked git@heroku.com:targetapp.git

次を使用して新しい環境にデプロイします。

$ git push forked master

この新しいアプリをデフォルトのデプロイターゲットにする場合は、Git リモートの名前を変更できます。

$ git remote rename heroku old
$ git remote rename forked heroku

フォーク済みアプリの状況

フォーク済みアプリは可能な限りソースアプリに似せられています。ただし、いくつか相違点があります。

Git リポジトリ

フォークすると、現在フォーク済みアプリで実行されている slug は新しいアプリにコピーされます。古いアプリの Git リポジトリの内容は、新しいアプリの Git リポジトリにはコピーされません​。

Dyno

フォーク済みのアプリケーションは、1 つの Web dyno で構成されていて Worker dyno や他の dyno は含まれないデフォルトの Dyno formation​ にスケーリングされるという点で、新しいアプリに似ています。

ニーズを満たすように、フォーク済みのアプリケーションの dyno をスケーリングします。

$ heroku ps:scale web=1 worker=1 -a targetapp

共同作業者

ソースアプリのユーザーがフォーク済みアプリに転送されることはありません。共同作業者はユーザー自身が追加する必要があります。

$ heroku access:add colleague@example.com -a targetapp

データベースフォロワー

フォーキングプロセスでは、sourceapp​ 上に存在するすべてのデータベースがコピーされますが、それらの間のフォーク​/フォロー​の関係は保持されません。無関係のデータベースを自分で削除し、フォークまたはフォロワーはすべて手動で再確立します。

Labs 機能

sourceapp​ で有効化されている Heroku Labs​ 機能は、targetapp​ で再有効化されません。