Play 2.0/2.1 は Heroku で問題なく動作しています。ただし、「git push」は完了するまでに時間がかかります。Heroku のサーバーでプッシュしてコンパイルする代わりに、'play dist' を使用して Heroku リポジトリに jar をプッシュできますか? ソースコードのメンテナンス以外にデメリットはありますか?
http://www.playframework.com/documentation/2.1.0/ProductionDist
Play 2.0/2.1 は Heroku で問題なく動作しています。ただし、「git push」は完了するまでに時間がかかります。Heroku のサーバーでプッシュしてコンパイルする代わりに、'play dist' を使用して Heroku リポジトリに jar をプッシュできますか? ソースコードのメンテナンス以外にデメリットはありますか?
http://www.playframework.com/documentation/2.1.0/ProductionDist
Heroku は、「ソース コードを Heroku にプッシュする利点はありますか?」git push
のアプローチ
を使用する場合のいくつかの利点を示しています。
- ビルド環境とランタイム環境の違いは、従来の展開環境での不適切な展開の一般的な原因です。アプリが後で実行されるのと同じ環境でアプリのビルドを行うと、このリスクが大幅に軽減されます。
- ビルドではなくコードをプッシュすることで、あなたとあなたのチームは、どのコードがどこにデプロイされているかをより明確に把握できます。たとえば、コマンド
git diff production/master staging/master
は、ステージングと本番の間の正確なコードの違いを示します。- Git は、変更されたもののみを送信するように高度に最適化されています。これは、完全なビルド アーティファクトを転送するのに何分もかかる可能性があるのではなく、ほとんどのコード プッシュ (最初のプッシュ以降) が数秒しかかからないことを意味します。
- リビジョン コントロールを使用してデプロイすると、デプロイ権限を持つチーム メンバー間のコラボレーションがスムーズになります。たとえば、最近のデプロイを古いデプロイで誤って上書きすることを防ぐ、オーバーライド可能な保護手段を提供します。
しかし、かなり単純な Play! のこのアプローチにはいくつか問題があります。私が取り組んでいる2.1アプリケーション。
いくつかの依存関係しかなく、スラッグのサイズはすでに 200m の制限を超えています。今のところ問題はありませんが、成長することを期待しています。
また、Heroku がビルドのみに使用される依存関係 (特にsbtのもの)をフェッチするのに時間がかかりすぎて、何もデプロイできない日もあります。デプロイは 10 分後にタイムアウトします。
そのため、近い将来、コンパイル済みのアーティファクトのデプロイに切り替えることになるでしょう。