Fork app

HerokuのPostgresのデータ、設定変数、アドオンを含んだ、既存のアプリケーションをコピーするためにはheroku forkコマンドを使ってください。

これは、それぞれのアプリケーションにとって、一つ以上の環境を持つための一般的な方法です。例えば、それぞれのアプリケーションに置けるステージングやプロダクション環境とともに、いくつかの開発段階で機能のための一時的なテスト環境をいくつか用意する事があると思います。アプリケーション間での同一性を確保するために、プロダクション環境からのフォークで新しくアプリケーションを作りましょう。

フォークされたアプリケーションは`heroku fork`を実行したユーザのアカウントで作られます。フォークしたユーザはアプリケーションのオーナーとなり、そのアプリケーションの変更に対しての責任が発生します。このため、もしアプリケーションが有料情報を含んでいた場合、あなたのアカウントは認証される必要がでてきます。

設定

ここで説明する機能を使うには、Heroku Toolbeltがインストールされている必要があります。Toolbeltのインストールを完了し、、そしてheroku updateを使って最新版に更新してください。

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

このガイド用に、元のアプリケーションは`sourceapp`と呼び、新しくフォークするアプリケーションは`targetapp`と呼ぶ事にします。

古いアプリケーション上にある有料プランのアドオンは、新しいアプリケーション上では同じ有料プランとして配備されます。フォークした後でアップグレードやダウングレードをすることで、必要に応じてアドンのプランを調整してください。

targetappを作るためにheroku forkを実行し、すべてのHeroku Postgresのデータと環境変数を新しいアプリケーションにコピーし、、そして同じプランのアドオンを全て配備し直します。データベースの大きさによってはこの処理はいくらかの時間を要します。

Heroku Postgresのデータだけは自動で新しいアプリケーションにコピーされます。他の全てのアドオンは単に再配備されるため、これらのサービスのために必要なエクスポート／インポート用のデータは手動で管理する必要が出てきます。

`targetapp`を自分で作らないでください。`heroku fork`はtargetappをフォークの処理の過程で作成します。

:::term
$ heroku fork -a sourceapp targetapp
Creating fork targetapp... done
Copying slug... done
Adding pgbackups:plus... 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 フラグを使ってください :

:::term
$ heroku fork -a sourceapp targetapp --region eu

アドオンの失敗

いくつかのアドオンは、それらがもう利用不可能である場合に配備に失敗する可能性があります。

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

もし元々のプランが存在しなくなっているせいで、アドオンが配備できなくなった場合、sourceappのプランをアップグレードした上でフォークを再実行してください。

もし既に`heroku fork`を実行している場合、もう一回実行する前にtargetappを破棄する必要が出てきます: `heroku destroy -a targetapp`

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

手動でのアドオンの設定

配備した後に、追加で設定が必要なアドオンがいくつかあります。おそらくアドオンの一覧に載っていない物もあるので、手動で設定を入力したアプリのアドオンは、よく見直すようにしてください。

Heroku Postgres

全てのアプリケーション上のHeroku Postgres データベースはsourceappからtargetappへとコピーされます。これはpg_backupsを通して行われ、Heroku Postgres のフォークとしてフォークする事はしません。これに対してフォロワー（のDB）がある場合、ことは結果としてリーダーとなるDBをフォローしていない、重複するコピーを生むこととなります。

もしDATABASE_URLの値がsourceapp上で手動で設定されていた場合、例えば他のアプリケーションとデータベースを共有する場合や?pool=10のようなパラメータを追加したいなどに、targetappに何のぶれも無くコピーされます。別のことばでいうならば、targetappはsourceappと同じデータベースを使うように設定されます。

もしこれが望んだ挙動でないのならば、heroku pg:promoteを使用し、かわりにtargetapp用の特別なデータベースを使うようにします。

カスタムドメイン

カスタムドメインは一度に一つのアプリケーションにしか対応しないため、どのカスタムドメインもフォークの過程としてコピーされることはありません。もしカスタムドメインをあなたの新しい環境で使いたい場合は、これらを自分自身で追加し、同様に必要なDNSの追加をする必要がでてきます。

SSL

もしフォークしたアプリがSSLを使う必要がない場合、不必要な変更を避けるため、`heroku addons:remove ssl`を使ってアドオンを削除してください。

フォークの処理でtargetapp上のSSL Endpointが再配備されますが、あなたの代わりに証明書を追加してくれる訳ではありません。もしあなたのアプリケーションがSSL付きのカスタムドメインを使っている場合、targetapp上のSSL endpointに新しい証明書を追加する必要があります。

:::term
$ 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レコードを追加してください。

Type	Name	Target
CNAME	www	tokyo-1234.herokussl.com

Scheduler

Heroku Schedulerアドオンでは、ジョブのスケジュールを手動で移す必要があります。sourceappとtargetappの両方のSchedulerのダッシュボードを開いて差分を確認しながら、ジョブを手動でコピーしてください。

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

デプロイ

あなたのアプリケーションをフォークしても、自動であたらしいGitのリポートを現在のプロジェクト内に作成してくれるわけではありません。targetappをデプロイするためには、自分自身でGitのリモートを作る必要があります。heroku infoを使って、新しいアプリケーションのGitのURLを確認し、手動で設定してください。

:::term
$ heroku info -a targetapp
=== targetapp
...
Git URL:       [email protected]:targetapp.git
...

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

:::term
$ git remote add forked [email protected]:targetapp.git

以下のコマンドで新しい環境へデプロイします :

:::term
$ git push forked master

もし新しいアプリをデフォルトのデプロイ先として設定したい場合は、Gitリモートの名前を変更することができます。

:::term
$ git remote rename heroku old
$ git remote rename forked heroku

フォークしたアプリの状態

フォークしたアプリケーションは可能な限り元のアプリケーションに近い状態に成っていますが、しかしながらいくつか違いがあります。

Gitリポジトリ

フォークするとき、フォークされたアプリケーションの中で現在実行中のスラッグが新しいアプリケーションへとコピーされます。古いアプリケーションのGitリポジトリの内容は新しいアプリケーションのGitリポジトリへコピー_されません_。

Dyno

フォークしたアプリケーションは、新しく作るアプリケーションのように、一つのWeb DynoとWorker Dynoなどの他のDynoが無い状態で構成されるデフォルトのDyno 編成が組まれます。

ニーズに合わせて、フォークしたアプリケーションのDynoを拡張しましょう :

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

コラボレータ

元のアプリケーションからは、どのユーザもフォークしたアプリへと転送される事はありません。コラボレータは自分で追加する必要があります。

:::term
$ heroku sharing:add [email protected] -a targetapp

データベースのフォロワー

フォークの処理はsourceappに存在する全てのデータベースをコピーしますが、フォーク/フォローの関係は維持しません。無関係なデータベースは削除し、フォークとフォロワーを手動で作り直してください。

ラボの機能

sourceapp上のいかなる有効なHerokuラボの機能も、targetapp上では有効化されません。