Skip Navigation
Show nav
Heroku Dev Center
  • Get Started
  • ドキュメント
  • Changelog
  • Search
  • Get Started
    • Node.js
    • Ruby on Rails
    • Ruby
    • Python
    • Java
    • PHP
    • Go
    • Scala
    • Clojure
  • ドキュメント
  • Changelog
  • More
    Additional Resources
    • Home
    • Elements
    • Products
    • Pricing
    • Careers
    • Help
    • Status
    • Events
    • Podcasts
    • Compliance Center
    Heroku Blog

    Heroku Blog

    Find out what's new with Heroku on our blog.

    Visit Blog
  • Log inorSign up
View categories

Categories

  • Heroku のアーキテクチャ
    • Dyno (アプリコンテナ)
    • スタック (オペレーティングシステムイメージ)
    • ネットワーキングと DNS
    • プラットフォームポリシー
    • プラットフォームの原則
  • コマンドライン
  • デプロイ
    • Git を使用したデプロイ
    • Docker によるデプロイ
    • デプロイ統合
  • 継続的デリバリー
    • 継続的統合
  • 言語サポート
    • Node.js
    • Ruby
      • Bundler の使用
      • Rails のサポート
    • Python
      • Python でのバックグランドジョブ
      • Django の使用
    • Java
      • Maven の使用
      • Java でのデータベース操作
      • Spring Boot の使用
      • Java の高度なトピック
    • PHP
    • Go
      • Go の依存関係管理
    • Scala
    • Clojure
  • データベースとデータ管理
    • Heroku Postgres
      • Postgres の基礎
      • Postgres Getting Started
      • Postgres のパフォーマンス
      • Postgres のデータ転送と保持
      • Postgres の可用性
      • Postgres の特別なトピック
    • Heroku Redis
    • Apache Kafka on Heroku
    • その他のデータストア
  • モニタリングとメトリクス
    • ログ記録
  • アプリのパフォーマンス
  • アドオン
    • すべてのアドオン
  • 共同作業
  • セキュリティ
    • アプリのセキュリティ
    • ID と認証
    • コンプライアンス
  • Heroku Enterprise
    • Private Space
      • インフラストラクチャネットワーキング
    • Enterprise Accounts
    • Enterprise Team
    • Heroku Connect (Salesforce 同期)
      • Heroku Connect の管理
      • Heroku Connect のリファレンス
      • Heroku Connect のトラブルシューティング
    • シングルサインオン (SSO)
  • パターンとベストプラクティス
  • Heroku の拡張
    • Platform API
    • アプリの Webhook
    • Heroku Labs
    • アドオンのビルド
      • アドオン開発のタスク
      • アドオン API
      • アドオンのガイドラインと要件
    • CLI プラグインのビルド
    • 開発ビルドパック
    • Dev Center
  • アカウントと請求
  • トラブルシューティングとサポート
  • Integrating with Salesforce
  • 継続的デリバリー
  • アプリの複数の環境の管理

アプリの複数の環境の管理

日本語 — Switch to English

最終更新日 2020年08月06日(木)

Table of Contents

  • 環境の作成とリンク
  • ステージングおよび本番設定の管理
  • 高度: ローカルブランチのリモートアプリへのリンク

Heroku アプリは、少なくとも次の 2 つの環境で動作します。

  • ローカルマシン上 (開発​)
  • Heroku プラットフォームにデプロイ済み (本番​)

アプリは、次の 2 つの追加の​環境で動作することが理想的です。

  • テスト​。アプリのテストスイートを分離して、安全に実行するため
  • ステージング​。アプリの新しいビルドを、プロモートする前に本番同様の設定で実行するため

これらの個別の環境を異なる Heroku アプリとして保持し、各環境をその意図した目的にのみ使用すると、バグの多いコードが本番環境にデプロイされないようにするのに役立ちます。

Heroku の Linux スタック​は開発用マシンのオペレーティングシステムとは異なる可能性があるため、この方法は特に重要です。つまり、ローカル開発環境で動作するコードが、本番環境でまったく同じように動作すると確信することはできません。

Heroku には、アプリのステージングおよびテスト環境を作成して保持するための役立つツール (つまり、パイプライン​、Heroku CI​、レビューアプリ))​ が用意されています。

環境の作成とリンク

ステージング環境の作成

ローカル (開発用) マシンで動作するアプリケーションがあり、それを Heroku にプッシュする準備ができているとしましょう。Heroku CLI​ を使用して、ステージング環境を表す新しい Heroku アプリを作成できます。

$ heroku create --remote staging
Creating strong-river-216.... done
http://strong-river-216.heroku.com/ | https://git.heroku.com/strong-river-216.git
Git remote staging added

デフォルトでは、Heroku CLI は、リポジトリに heroku​ という名前の Git リモートを追加します。上記のコマンドでは、--remote​ フラグを使用して、リモートのための異なる名前 (この場合は、staging​) を指定しています。そのため、コードをアプリの新しいステージング環境にプッシュするには、次のコマンドを使用します。

$ git push staging master
...
$ heroku ps --remote staging
=== web: `bundle exec puma -C config/puma.rb``
web.1: up for 21s

本番環境の作成

ステージングアプリが正しく稼働したら、同じコマンドを使用して本番環境を作成し、そこにプッシュできます。

$ heroku create --remote production
Creating fierce-ice-327.... done
http://fierce-ice-327.heroku.com/ | https://git.heroku.com/fierce-ice-327.git
Git remote production added
$ git push production master
...
$ heroku ps --remote production
=== web: `bundle exec puma -C config/puma.rb``
web.1: up for 16s

これらのアプリは引き続き開発されるため、これらの同期を維持するために、何らかの作業を行う必要があります。たとえば、各環境に貢献者​、環境設定​、buildpack​、アドオン​を個別に追加する必要があります。

これで、2 つの個別の Heroku アプリ (ステージングに 1 つと本番に 1 つ) として実行される同じコードベースが用意されました。

Heroku CLI での環境の指定

Git リポジトリに複数の Heroku リモートが関連付けられている場合、Heroku CLI のコマンドでは、-r​ (または --remote​) オプションを含めることによって対話するアプリを指定する必要があります。ワークフローを簡略化するために、Git 設定を編集してデフォルトの Heroku リモートを示すことができます。

たとえば、次のコマンドを使用して、staging​ をデフォルトの Heroku リモートにすることができます。

$ git config heroku.remote staging

これにより、プロジェクトの .git/config​ ファイルに次のセクションが追加されます。

[heroku]
  remote = staging

この変更を行った後、リポジトリから実行するすべての Heroku CLI コマンドが、デフォルトで staging​ アプリを管理します。production​ アプリに対してコマンドを実行するには、そのコマンドに -r production​ を含めるだけです。

パイプラインでの環境のリンク

Heroku パイプライン​により、アプリの環境をリンクし、ステージングから本番にコードをプロモートすることが簡単になります。

この手順​に従って、Heroku Dashboard から新しいパイプラインを作成し、それにステージングおよび本番環境を追加します。

ステージングおよび本番設定の管理

多くの言語やフレームワークでは、開発/本番スイッチの切り替えがサポートされています。 たとえば、開発モードでは、別のデータベースを使用したり、ロギングレベルを上げたり、すべてのメールをエンドユーザーではなく自分自身に送信したりすることができます。

本番環境へのデプロイ中の予期しない事態を最小限に抑えるために、ステージングアプリケーションには RAILS_ENV=production​ または RACK_ENV=production​ を使用する必要があります。詳細は、「Deploying to a custom Rails environment​」(カスタム Rails 環境へのデプロイ) を参照してください。

アプリケーションが使用するサービスやライブラリでも、独自の環境設定を設定して、本番環境でこれらをミラーリングすることが必要になる場合があります。 たとえば、ステージングでは本番とは別の S3 バケットを使用できるため、次の鍵に別の値を使用します。

$ heroku config:set S3_KEY=XXX --remote staging
$ heroku config:set S3_SECRET=YYY --remote staging

高度: ローカルブランチのリモートアプリへのリンク

上記の手順に従っている場合、git push staging master​ と git push production master​ を入力することは簡単です。ただし、多くの開発者は Git のブランチを利用して、進行中のコードと本番準備完了のコードを分離することを好みます。この種類の設定では、master​ ブランチから本番環境にデプロイし、development​ ブランチの変更がステージングアプリで確認されたらそれらの変更をマージすることもできます。この設定で、プッシュは少し注意が必要です。

$ git push staging development:master

このコマンドは、Git にローカルの development​ ブランチから staging​ リモートの master​ ブランチにプッシュするよう指示します(これは少し乱雑に見えるかもしれませんが、実際にはこれより多くの処理が行われています。refspec についての詳細は、Git の書籍​を参照)。

Git コマンドを簡略化したい場合は、ローカルの Git ブランチに強制的にリモートアプリケーションを追跡させることにより簡潔にすることができます。staging​ と production​ の Git リモートを取得している場合は、次のようにできます。

この 1 つだけでなく、すべての Git リポジトリの push.default​ を設定する場合は、このコマンドに --global​ を追加します。

$ git config push.default tracking
$ git checkout -b staging --track staging/master
Branch staging set up to track remote branch master from staging.
Switched to a new branch 'staging'

これで staging​ ブランチに入っているため、git pull​ と git push​ がそれ以上の引数なしでステージング環境に対して機能するように設定されました。コードを少し変更し、それをコミットしてプッシュします。

$ git commit -a -m "changed code"
$ git push
Counting objects: 11, done.
...

git push staging staging:master​ ではなく、git push​ を入力したことに注意してください。これは push.default​ 設定によって可能になります。それが tracking​ に設定されていると、ローカルブランチでは、追跡しているリモートリポジトリに変更が自動的にプッシュされます。

ローカルの master​ ブランチが production​ リモートを指すようにしたい (かつ、Git 1.7 以降を実行している) 場合は、次のようにできます。

$ git fetch production
$ git branch --set-upstream master production/master

その場合は、master​ からの git push​ によって Heroku 上の本番アプリが更新されます。

関連カテゴリー

  • 継続的デリバリー

Information & Support

  • Getting Started
  • Documentation
  • Changelog
  • Compliance Center
  • Training & Education
  • Blog
  • Podcasts
  • Support Channels
  • Status

Language Reference

  • Node.js
  • Ruby
  • Java
  • PHP
  • Python
  • Go
  • Scala
  • Clojure

Other Resources

  • Careers
  • Elements
  • Products
  • Pricing

Subscribe to our monthly newsletter

Your email address:

  • RSS
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku Blog
    • Heroku News Blog
    • Heroku Engineering Blog
  • Heroku Podcasts
  • Twitter
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku
    • Heroku Status
  • Facebook
  • Instagram
  • Github
  • LinkedIn
  • YouTube
Heroku is acompany

 © Salesforce.com

  • heroku.com
  • Terms of Service
  • Privacy
  • Cookies
  • Cookie Preferences