heroku

2015年9月 3日 (木)

herokuにカジュアルなスキーマ変更を求めるのは間違っているだろうか

herokuブログでは初めまして。@ucmskyです。

まず最初に告知ですが。前の記事でも紹介したとおり、9月10日に弊社で勉強会を開催します。

第1回FlectMeetup MEANスタック+HerokuでWebサービスを作ろう!

内容はMEANスタックのハンズオンですので、node.jsに興味のある人は是非。


rigepoleの簡単な紹介

さて、今日紹介することですが、その前に。

皆さん、herokuでもridgepole使いたいですよね? 使いたいですよね?(震え声

ところで、ここでridgepoleって何? という人はこちらをどうぞ。

クックパッドにおける最近のActiveRecord運用事情

平たく言うと、クックパッドの中の人が開発したgemです。

通常、railsで開発を進める場合、DBのスキーマを変更する場合ですと、各変更毎にmigratenファイルを生成し、変更内容を記載します。変更内容はカラムの変更(追加削除更新など)と、逆に差し戻す場合の逆の手順(カラムを追加した場合は削除し、変更した場合は変更前の状態に戻すなど)を記載します。

こうすることで、変更と差し戻しをrakeで制御するのですが、あまりスキーマの変更を容易に出来る仕組みではありません。

ところが、ridgepoleはテーブルの情報を記載したスキーマファイルを読み取り、DBの情報と差異がある部分だけを直接DBに適用することが出来るので変更コストを減らすことが出来ます。

さて、ridgepoleですが、heroku上でも使うことはできるでしょうか? 結論から言うと可能です。

ただし、以下の様な使い方

$heroku run ridgepole  -e config/database.yml ...  

とか

$heroku run bash
$ridgepole -e config/database.yml ...  

ではheroku上では使えません。

(9月4日追記)
heroku runから呼び出す場合は、以下のようにクォーテーションで囲むと使えます。

後述のようにrakeタスクを登録する手間を省きたい場合はこちらの方法も可能です。

(dry runの例)


$ heroku run "bundle exec ridgepole -c config/database.yml \
 -E production -f config/Schemafile --apply --dry-run"

herokuでの使い方

便利な方法として、rakeタスクに記述して、rake経由でridgepoleを呼び出すという方法です。


$bundle exec rails g task ridgepole  

で lib/tasks/ridgepole.rake が生成されるので、こちらのページの内容に従って編集します。

【Ruby】【Rails】手間な実行コマンドはRakeタスクに書いて行くようにした。

エクスポートのコマンドはheroku上では意味が無いですが、ローカルで使う分には便利です。

デモ

では実際に変更されるのか試してみます。今回はこちらのrails apiのサンプルを使って、実際にmigrationファイルを生成しないでスキーマ変更ができることを確認してみます。 途中まではサンプル通りに作り、そこからridgepoleによってスキーマを変更するまでを行います。 スキーマ変更はローカル→herokuの順に行います。

因みになぜrails apiかというと、rails5で標準搭載されると以前ginza.rbで話題になった時に軽く触ってみていたので。

サンプル

確認で使ったrailsとrubyのバージョンは以下の通りです。サンプルのrailsのバージョンは3系ですが、4でも問題なく動きます。

ruby 2.2.2 / rails 4.2.3

今回はpostgresを使うので作成時にdオプションを付けます。


$rails-api new todo -d postgresql  

作成されたらGemfileを編集します。


gem 'ridgepole'
group :production do
  gem 'rails_12factor' # herokuで必要
end

後はサンプルの通りに作りこんでいきます。

取り敢えず一旦サンプルの通りに作ったら、herokuにデプロイします。


$heroku login
$heroku create flt-simple-todo
$git init
$git add .
$git commit -m "first commit"
$git remote add heroku https://git.heroku.com/flt-simple-todo.git
$git push heroku master
$heroku run rake db:migrate

余談ですが、最後の heroku run rake db:migrate が好きなherokuのコマンドです(あくまで初回のみ)。

ridepoleによるマイグレート

さて、ここからがridgepoleを使った場合のマイグレーションです。 上で書いたとおりにridgepoleを呼び出すタスクを生成します。

スキーマファイルを生成してみます。


$bundle exec rake ridgepole:export

するとconfig/Schemafileが生成され、以下のような内容になっていると思います。


create_table "tasks", force: :cascade do |t|
  t.string   "name"
  t.datetime "created_at", null: false
  t.datetime "updated_at", null: false
end

ご覧のとおり、テーブルの定義が記載されています。 ではこのファイルを編集し、herokuにデプロイするところまでやってみます。


create_table "tasks", force: :cascade do |t|
  t.string   "name"
  t.string   "title" #<==タイトルを付けてみる
  t.datetime "created_at", null: false
  t.datetime "updated_at", null: false
end

まずローカルで適用します。


$bundle exec rake ridgepole:apply

本当に増えているのか動作確認も含めて行うので、諸々編集します(追加したカラムを含めて表示編集できるような内容であれば特になんでも構いません)。

こんな感じで反映されていればローカルでは成功です。

20150903_111108


では続いて肝心のherokuでの動作確認をします。

その前に以下の注意点が有ります。

注意点

heroku上でridgepoleからDB(PostgreSQL可)に繋ぎに行く場合、config/database.ymlの接続情報が正しく設定されていないと接続できません。

何を当たり前のことを、思われるかもしれませんが、herokuの場合、config/database.ymlの設定を読み飛ばすという仕様になっています。

参考 https://devcenter.heroku.com/articles/rails-database-connection-behavior

The config/database.yml file no longer generated for applications using ActiveRecord 4.1+

接続のための情報は環境変数「DATABASE_URL」から設定します。

環境変数 DATABASE_URLには接続するDBの情報が postgres://ユーザ名:パス@ホスト名:ポート/DB名 の形で記載されていますので、この情報からに接続情報を切り出します。 今回はデモということで、以下の環境変数を登録します。(もっとうまいやり方があるかもしれませんが)

DB名 DBNAME
ユーザ名 DBUSER
パスワード DBPASS
DBホスト名 DBHOST
ポート DBPORT

環境変数にセットしたら、config/database.ymlから読み出せるように設定します。

production:
  <<: *default
  database: <%= ENV['DBNAME'] %>
  port: <%= ENV['DBPORT'] %>
  username: <%= ENV['DBUSER'] %>
  host: <%= ENV['DBHOST'] %>
  password: <%= ENV['DBPASS'] %>

(9月4日追記)
環境変数「DATABASE_URL」が設定されている場合は、以下の設定にすることで、特に追加の設定は必要無いみたいです。

production:
  url: <%= ENV['DATABASE_URL'] %>

設定できたらもう一度デプロイします。


git add .
git commit -m "ridgepole deploy"
git push heroku master

ではデプロイ後、ridgepoleによるマイグレートを行います。


heroku run rake ridgepole:apply

こんな表示になっていて上手く動いたら完了です。

20150903_112249


お疲れ様でした。

続きを読む "herokuにカジュアルなスキーマ変更を求めるのは間違っているだろうか" »

2015年8月12日 (水)

【Herokuお絵かき】Herokuにデプロイする!

こんにちは、なかやまです。

前回に引き続きキャラクターを使って、Herokuにデプロイするところをお絵かきしてみたいと思います!

Heroku2_01

前回(【Herokuお絵かき】Herokuってな~に?)、

じーちゃんにアプリを作るならHerokuがおすすめだよと言われました。

 

#2.Herokuにデプロイする

たろうはPlay Framework(以下play)をつかってデプロイすることにチャレンジするようです。

がんばれたろう!

Heroku2_02_2

 

じーちゃんの教えにより、まずはローカル環境でちょっとだけ動くプログラムを書いてみることになりました。

Heroku2_03

 

やる気いっぱいのたろう。

Heroku2_04

 

・ローカル環境を作る

Macをつかって開発環境をつくるようです。PVM(Play Version Manager)入れて、playをインストールして、、Eclipseの準備も整ったようですよ!

Heroku2_05_2

 

ローカル環境を作るのも結構大変。

たろうがんばれー!

Heroku2_06

playをEclipseの設定ファイルを生成する

https://www.playframework.com/documentation/ja/1.2.x/ide

 

・gitの設定

ローカル環境でプログラムが動いたら、次はgitにコミットします。

Heroku2_08_2

 

・Herokuの設定

Herokuアカウントの作成と、Heroku Toolbeltのインストールを行いましょう。

Heroku2_09

 

・Herokuにデプロイする(git push heroku master)

Herokuにデプロイしますよ!いけーー!

Heroku2_10

 

Herokuではgit pushを確認すると、Dynoに展開するためのslugという塊を作ってくれます。

あわせてgitにコミットされたファイルを見ながら、どの言語・フレームワークを使っているから、このビルドパックを使う、ということもHerokuが判断してくれます。

playだと「/conf/application.conf」ファイルがあるのでplayだね!となるわけです。

ビルドパックを自作することもできるそうです。

参考)HerokuのSlugとその動き

Heroku2_11

 

指定されたライブラリのダウンロードなど、コンパイルが行われます。

Heroku2_13_2

 

コンパイルに成功するとslugという塊ができます。

このslugですが、サイズがあまりにも大きい場合にはデプロイできないので注意しましょう。

すばやく展開するためにも、サイズは小さいほうがよいです。

https://devcenter.heroku.com/articles/slug-compiler#slug-size

Heroku2_13

 

slugの作成に成功すると、指定された数のDynoが起動します。

Heroku2_14

 

100Dynoだといっぱいです。

Heroku2_15

 

ローカル環境のモジュールをデプロイできたようですね。

ですが、playのバージョンが1.3でデプロイされてしまったようです。。

ローカル環境では1.2で動いていたのに、なぜだろう?

Heroku2_17_2

ビルドのログはActivityタグから確認ができますよ。

Activity

 

ビルドパックの説明をみると、定義ファイルにバージョンを指定しない場合はデフォルトの1.3が指定されると書いてました。なるほどなるほど。

設定ファイル(dependencies.yml )にバージョンきちんとかいてみましょう。

Heroku2_18_3

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

 

モジュールに変更があった場合は、再度gitのコミットと、git push heroku masterをしましょう!

Heroku2_19_3

 

・heroku run bash

run bashコマンドを使うとDynoにアクセスできます。

ここではインストールされたplayのバージョンを聞いてみました。

Heroku2_19

正しいバージョンでインストールできたようです!よかったねたろう!

 

 

 

・おたより

そういえば、おたよりが届いてました!2通目です!ありがたや。

Heroku2_22

 

前回のHeroku説明について「あってますよ」というメッセージをいただきました。

ありがとうございますー。

Heroku2_23_2

フィードバックいただけるとうれしいです。m(_ _)m

Heroku2_24

おたより(なかやま直通)

2015年8月 5日 (水)

【速報】HerokuのPerformanceDynoがさらなるPerformanceを獲得

はい、どうも。 中2日、2連投のおっぴーです。

タイトルですべてを要旨は全て言い尽くしておりますが、HerokuでもっともパワフルなDynoであるPerformanceDyno、いわゆるPXDynoのパフォーマンスが向上しました。

もともと6GBだったメモリが14GB、ディスクもSSDになったということです。

さらに嬉しいのはお値段が据え置き(っぽい)ということろで、無償のアップグレードと考えられます。

Herokuを利用しているとダッシュボードなど、少しずつ改善されている部分もあるのですが、こうした大きなアップグレードを聞くとやはりうれしいですね。

Herokuの公式発表は下記のURLで見られます。

https://devcenter.heroku.com/changelog-items/690

すでにPXDynoを利用しているユーザーは、72時間以内にあらたなPXDynoに切り替わるようです。 こうしたアップグレードが簡単なところもPaaSの良い所ですね。

「とくに2XDynoとPXDynoの間を埋める性能の新Dynoの登場があるとうれしい」(弊社、浅野)という意見もありますので、今後もさらなる進化を期待しています。

参考情報

2015年8月 3日 (月)

HerokuConnectでお手軽なデータ連携。クリーム玄米ブランでお手軽な朝食。

はい、どうも。 最近の朝食はもっぱらクリーム玄米ブランのおっぴーです。 さくさくと食べごたえがあり、冷たいアイスコーヒーとの相性抜群。 夏バテや朝の忙しから、朝食をついつい抜いてしまうあなたにおすすめの組み合わせです。

ということで、今回はおすすめのHeroku謹製のアドオンHerokuConnectのご紹介です。 約1年前からGAとなっているアドオンであり、SalesforceとHerokuのデータ連携を行えるという便利さは理解されているものの、なかなか情報を手に入れることが難しい印象ですが、今年の2月からdemoというプラン名で無料で使えるようになっておりました。

また、最近はHerokuConnectで利用するSalesforceのAPIのCall数は利用回数には加算されないという発表もされるなど、さらにHerokuとSalesforceの親和性を高めてくれる、個人的にはとても注目しているアドオンです。

今回は基本的な使い方ついて、ご紹介したいと思います。

作業自体は簡単なものの、かなり(がんばって)丁寧に記事を書いた結果、少々長くなってしまったので、先に3行で結論を。

  • HerokuPostgresにデータ連携をするSalesforceのオブジェクトのテーブルが作られます
  • SaleforceとHerokuPostgresの双方向のデータ登録、更新が可能です
  • 上記の設定はとっても簡単です

herokuアプリの作成

まずは、herokuアプリを作ります。 今回は、heroku-connect-flect-demoという名前のアプリを作成します。 ちなみに、herokuアプリ名は世界中で一意である必要があるので、実際に試される際は適宜、変更してください。

heroku create heroku-connect-flect-demo

HerokuConnectの追加

さて次は、HerokuConnectを追加します。 今回は無料版として、demoというプラン名を指定して登録をします。

heroku addons:create herokuconnect:demo --app heroku-connect-flect-demo

追加に成功すると、下記のようなメッセージが表示されます。

Creating smiling-stably-8670... done, (free)
Adding smiling-stably-8670 to heroku-connect-flect-demo... done
Setting HEROKUCONNECT_SCHEMA, HEROKUCONNECT_URL and restarting heroku-connect-flect-demo... done, v3
Use 'heroku addons:open herokuconnect' to finish setup
Use `heroku addons:docs herokuconnect` to view documentation.

表示されているコマンドを実行すると、HerokuConnectの設定画面が開かれます。

heroku addons:open herokuconnect --app heroku-connect-flect-demo

おっと、まずはHerokuPostgresを追加しないといけませんね。

Heroku_connect1

ボタンを押して追加もできますが、HerokuPostgresをコマンドから追加しましょう。

heroku addons:create heroku-postgresql:hobby-dev --app heroku-connect-flect-demo

追加が完了したら、登録中の画面の「Refresh」を押して登録を続けましょう。

画面がリフレッシュされると追加したHerokuPostgresの情報が表示されます。

その下に、Enter schema nameとありますがこれはSalesforceのオブジェクトの情報をHerokuPostgres上で管理するために作成されるSchema名を入力し、決定する項目です。 今回はそのまま「salesforce」にしておきましょう。 では、次の設定画面に進むため「Next」ボタンをクリックしましょう。

Saleforceアカウントの作成

次に進むとSalesforceアカウントとの接続設定を行う画面が表示されます。 が、そのまえにSalesforceアカウントを作成し、連携をおこなうカスタムオブジェクトを作成しましょう。

今回は、無料で利用できるSalesforceのデベロッパーアカウントを作成します。 まずは、https://developer.salesforce.comに接続し、「サインアップ」のボタンをクリックします。

Salesforce1

つぎに必要情報を入力し、契約内容に同意を示すチェックをいれたら、「サインアップ」ボタンをクリックします。

Salesforce2

下記の画面が表示された登録は完了です。 表示されているメッセージに従い、入力したメールアドレスにメールが届いているか確認し、アクティベーションしましょう。

Salesforce3

連携用(テスト用)のカスタムオブジェクトの作成

作成したSalesforceアカウントにログインし、カスタムオブジェクトを作成します。 画面右上の「設定」をクリックし、左端に表示される項目から「作成」→「オブジェクト」をクリックします。

その後、「新規カスタムオブジェクト」をクリックすると独自のオブジェクトが作成できます。 ちなみにSalesforceに馴染みのない方に大雑把な説明をしますと、SalesforceのオブジェクトはRelationalDatabaseでいうところのTableとほぼ同義のものと捉えていただくとわかりやすいかと思います。

Salesforce4

今回はHerokuConnectのテストに利用するオブジェクトのため、単純にHerokuConnectTestという名称でオブジェクトを作成します。 必要な情報を入力して、「保存」をクリックするとカスタムオブジェクトの作成は完了します。

Salesforce5

次に、作成したカスタムオブジェクトのHerokuConnectTestにカスタム項目を追加します。 カスタム項目を追加するには、「カスタム項目&リレーション」で「新規」をクリックします。

Salesforce6

項目の属性としてSalesforceではさまざま用途に合わせて選択できますが、今回は単純にテキストを選択します。

Salesforce7

次に項目名と文字列の桁数を定義します。 今回は「testText」という項目名で 最長の文字列長の255文字で定義しましょう。

Salesforce8

次は、項目にたいする権限の設定を行います。 Salesforceには、「プロファイル」というユーザーをグループわけを行う概念があり、この「プロファイル」単位に今回、作成した項目についての「閲覧も修正(登録含む)もできない」、「閲覧のみ可能」、「閲覧も修正(登録含む)も可能」の3つから選択する画面です。

今回は、ブログ用のデモなのですべてのプロファイルにたいして「閲覧も修正(登録含む)も可能」にしていますが、実運用においては、用途に合わせて慎重に決める必要がある項目です。

Salesforce9

最後に、作成している「testText」項目をどのページに表示するか、という選択を行います。 ここでは「HerokuConnectTest」オブジェクトを作成した際に、同時に自動で作成されるページに表示することを選択します。 選択しない場合は、どこにも表示されず値の登録などもできないので、このまま表示されるように設定し、登録を完了します。

Salesforce10

以上でカスタムオブジェクトの作成とカスタム項目の追加が完了です。 さて、HerokuConnectの設定にもどりましょう!といいたのですが、もう少しだけSalesforceで作業を行います。

カスタムタブの作成

カスタムオブジェクトを作成し、そのオブジェクトにたいしてカスタム項目を追加しただけでは、Salesforce上でオブジェクトの編集はできません。

そのためにはカスタムタブ、という独自のタブを作成する必要があります。 画面の左から「作成」→「タブ」をクリックします。

表示された画面にはいくつかの「タブ」についての種類が表示されます。 今回は「カスタムオブジェクト」のタブを作成するため、「カスタムタブ」の新規作成を行います。 カスタムタブの左に表示されている「新規」をクリックしましょう。

Salesforce11

次にタブの詳細を選択します。 色々入力する必要はありますが、今回のデモで重要なのはオブジェクトの欄で上記で作成した「HerokuConnectTest」を選択することです。 選択をし、「タブスタイル」も適当に選択したら「次へ」をクリックして先に進みましょう。

Salesforce12

ここでもカスタム項目と同様にプロファイルにたいしてタブの操作を可能にするかどうかの選択を行う画面が表示されます。 ここもカスタム項目と同様にすべてのプロファイルにたいして操作を許可します。

Salesforce13

最後に作成したカスタムタブをどのアプリケーションから利用できるようにするか、を選択します。 このアプリケーションという概念ですが、これはSalesforceが提供する様々な機能へアクセスをおこなうためのタブをグループ分けするものと考えて良いと思います。 添付の画像では、「セールス」や「コールセンター」などの名称のアプリケーションがご確認いただけると思います。 これらは「標準アプリケーション」と呼ばれるもので、Salesforceが標準で提供するアプリケーションです。

今回は、これらのどのアプリケーションにたいしても、作成しているカスタムタブが追加されて問題はないので、すべてのアプリケーションから利用可能にして登録します。 ということで、「保存」をクリックして作成を完了します。

Salesforce14

完了すると、カスタムタブが追加されているのが確認できます。

Salesforce15

設定は以上で完了です。 が、ついでに「HerokuConnectTest」オブジェクトのレコードが作成できるか、確認してみましょう。

追加された「HerokuConnectTest」タブをクリックすると、画面が切り替わり「新規」というレコードを作成するためのボタンが表示されますので、そのボタンをクリックしましょう。

Salesforce16

入力項目に適当な値を入力し、「保存」をクリックするとレコードの登録は完了です。 ちなみに「HerokuConnectTest」という作成した覚えのない項目が必須入力の項目として存在していますが、これは、オブジェクトを作成するときに自動で作成される項目です。 一意の値である必要もなく、レコードのID(SalesforceはオブジェクトIDと呼びます)は別に生成されて保存されているため、IDのような存在でもありません。 検索結果の表示などで利用される値です。

Salesforce17

以上で、Salesforceの設定も完了しました。

HerokuConnectの設定

Salesforceへの接続設定

さて、HerokuConnectの設定の続きです。 HerokuConnectからSalesforceへの接続を行うための認証の途中でしたね。 まずは、接続先にSalesforceの環境を選択しましょう。 「Production」、「Sandbox」、「CustomDomain」と3つの選択肢が表示されますが、今回は「Production」を選択します。 ちなみにSandboxはSalesforceのステージング環境、CustomDomainはSalesforceを独自ドメインで運用している際にもちいる選択肢です。

選択したら右上の「Authorize」ボタンをクリックしましょう。

Heroku_connect4

「Authorize」をクリックするとSalesforceへの接続認証を行うために、ユーザー名とパスワードの入力を求められます。 HerokuConnectで接続したいSalesforceアカウントのユーザー名とパスワードを登録し、ログインボタンをクリックします。

Salesforce18

HerokuConnectにたいしてSalesforceへの接続をふくめた権限を与えてよいか、が問われますので、「許可」ボタンをクリックしましょう。

Salesforce19

認証が完了すると、HerokuConnectのダッシュボードが表示され、HerokuConnectを利用して接続しているHerokuのアプリケーション名とSalesforceのユーザー名が確認できます。

Heroku_connect6

さて、いよいよSalesforceとHerokuPostgresの接続、Mappingを行いましょう。 画面左下にある「Create Mapping」をクリックすると画面が設定画面へと切り替わります。

画面にはズラッとSalesforceのスタンダードオブジェクト(Salesforceが標準で提供するオブジェクト)とカスタムオブジェクトが並びます。 お目当てのオブジェクト名を、画面の右にある検索ペインを利用して絞り込むと簡単に探せます。 お目当てのオブジェクト、今回は上記で作成したHerokuConnectTestオブジェクトを接続する対象としてクリックします。

Heroku_connect7

ReadOnlyModeとRead / Write Mode

表示されている画面がHerokuConnectのメインとも言える画面です。 SalesforceのオブジェクトとHerokuPostgresのTableの結びつけやデータの連携の設定を行います。

Heroku_connect8

画面を眺めつつ、すこしHerokuConnectと考え方と操作の結びつきについて説明をします。 HerokuConnectにはReadOnlyModeとRead/WriteModeという2つの概念があります。 Salesforce→Herokuのデータ反映をReadOnlyModeと呼び、それにくわえてHeroku→Salesforceのデータ反映を行うことをRead/WriteModeと呼びます。

ですので、これらのモードは、モードそのものを指定するというよりは、Heroku→Salesforceのデータ反映を行うことを選択する(画面の「Write to Salesfore any updates to your database.」にチェックをつける)と、Read/WriteModeを選択したことになるのです。

画面では、「Write to Salesfore any updates to your database.」にチェックをつけているため、Read/WriteModeの選択をしています。

また、前後しますがSalesforceからHerokuPostgres(画面では「Salesforce→Database」と表示されていますが)の設定では、ポーリングをするか、Streaming APIを利用するかのどちらかが選択できます。 ポーリングはHerokuからSalesforceへ、Salesforce側のオブジェクトのレコードに変更がないか問い合わせを行うモードで、Streaming APIはSalesforceのオブジェクトに変更があった場合、即時でHerokuPostgresにデータを連携させる動きを行います。 ドキュメント(少々、古い気がするのですが。。。)では、Streaming API の利用を推奨しているので今回は、こちらを選択しています。

最後に、連携する項目についての選択を行います。 これについては説明は不要でしょう。連携が必要な項目にチェックをつけましょう。 今回は、上記で作成した「testText」と標準項目の「Name」を選択しています。

以上の設定をおこなったのち、「Save」をクリックするとHeorkuConnectの設定は完了です。

Heroku_connect9

完了するとマッピングの情報に行が追加されていることが確認できます。 また、余談ですがこの画面ではSalesforcのAPIの利用量も確認できます。 が、APIの利用量については気にしないで良いはずなので、今後はなくなるかもしれませんね。

以上で、HerokuConnectを利用したSalesforceとHerokuPostgresの接続作業は完了です。

Heroku_connect10

少し時間がたつと設定内容にしたがってSalesforceからHerokuPostgresにデータ連携がおこなれ、その結果がグラフに表示されているのがわかります。

HerokuPostgresの確認

さてさてこの状態でHerokuPostgresはどのような変化が起きているでしょうか。

まずはHerokuPostgresに接続してみましょう。

heroku pg:psql --app heroku-connect-flect-demo DATABASE_URL

接続が完了したら、上記で作成した「salesforce」Schemaの状態を見てみましょう。

\dt salesforce.*;

上記のコマンドを打つと、Schemaで定義されているTableの一覧が表示されます。 複数のテーブルがあるのですが、今回、詳細な説明は割愛させていただきます。 注目は最下部にある「herokuconnecttest__c」テーブルです。 HerokuConnectでデータ連携の設定を行うと、SalesforceのAPI名がすべて小文字で定義されたテーブルが作成されるのですね。

Herokupostgres1

では、その「herokuconnecttest__c」テーブルにデータが連携さているかを見てみましょう。

select * from salesforce.herokuconnecttest__c;

上記をコマンドを実行すると下記のように連携されたデータが見ることできました。

Herokupostgres2

ということで、無事、HerokuConnectのダッシュボードで確認できたように、データがHerokuPostgresに反映されていることが確認できました。

ほんとにお手軽

このブログを書くにあたっては、いちいちキャプチャをとっていたので時間がかかったのですが、HerokuもしくはSalesforceのどちらかの操作に慣れている方でであれば、この作業は30分もかからず完了できるはずです。

それだけお手軽にSalesforceとHerokuのアプリケーションでデータが活用できるとなると俄然、利用の検討の余地が出てくるというものです。

さらに、大事なことなので二回言います。 HerokuConnectによるSalesforceのAPIコール数は、APIの利用上限数には加算されません。 一度、連携させてしまえば利用制限を気にすることなく、CRMのデータを活かしたWebサービスの構築も可能になってしまいます。

今度は、といいつつなかなか続編を書かないのですが、HerokuConnectについてはさらに、詳細の利用方法を現在まとめております。

次回の更新では、更に踏み込んだ操作や動き、実際の利用の際の考慮点についてなども書いてみたいと思います。

2015年7月30日 (木)

Wercker v2でHerokuっぽい環境を作ってテストを動かす

Wercker v2でHerokuっぽい環境を作ってテストを動かす

こんにちは、浅野です。

今日は、Dockerに対応したWercker v2(Ewok)でHeroku+Postgresqlっぽい環境を作ってテストを実行するまでの手順を紹介します。

言語は相変わらずJavaです。(Java8+Gradle)

Werckerとは

Werckerは、TravisCIやCircleCIのようなCIサービスです。 無償プランでGithubのPrivateリポジトリがビルドできるため、Flectではよく使用されています。

Wercker v2

元々はBoxと呼ばれる独自の実行環境を使っていたのですが、V2からは実行環境にDockerHubのイメージを指定するようになっています。

テストを実行するDockerイメージを作る

HerokuがDockerをサポートしたこともあり、DockerHub上にHeroku謹製のcedarイメージがあります。 これがそのまま使えるかと期待したものの、上手くいきませんでした。

原因は、heroku/cedar:14 に標準インストールされているJDKが 1.7.0_79 だったためです。 なので、 heroku/cedar:14 をベースにJDK8入りのイメージを作ります。

こんなDockerfileで作ったイメージをDockerHubへ登録します。 (DockerHubのここのタグ0.2にこれで作ったDockerイメージが置いてあります)

FROM heroku/cedar:14

ENV DEBIAN_FRONTEND noninteractive

RUN apt-get update
RUN apt-get -y install software-properties-common python-software-properties
RUN add-apt-repository -y ppa:openjdk-r/ppa
RUN apt-get update
RUN apt-get -y install openjdk-8-jdk

RUN update-alternatives --set java /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java
RUN update-alternatives --set javac /usr/lib/jvm/java-8-openjdk-amd64/bin/javac

wercker.ymlを書く

ここにテストを実行するための環境・テストの実行ステップを定義します。

ベースイメージを指定する

先ほどDockerHubにUpしたDockerイメージをBoxに指定します。

box: yuasano/heroku:0.2

Postgresqlを追加する

次にHeroku Postgresqlアドオン相当のものを追加します。Werckerでは外部サービスを追加する時は serviceを使います。 これは以下のようになります。 POSTGRES_USERは省略可で、省略した場合はpostgresユーザが作られます。

services:
   - id: postgres
     env:
       POSTGRES_PASSWORD: YOUR_PASSWORD
       POSTGRES_USER: YOUR_NAME

詳しくは公式ドキュメントを参照してください。

DB接続用の環境変数 DATABASE_URLを定義する

次に、HerokuPostgresで追加される環境変数DATABASE_URLを定義します。 これは、実行時に動的に決まる値なので、以下の環境変数群(どうもpostgresqlのDockerイメージがこういう環境変数を使うよう)を使って生成します。

POSTGRES_ENV_POSTGRES_USER=YOUR_NAME
POSTGRES_ENV_POSTGRES_PASSWORD=YOUR_PASSWORD
POSTGRES_PORT_5432_TCP_PORT=5432
POSTGRES_PORT_5432_TCP_ADDR=172.XX.X.XX

この値を組み合わせてDATABASE_URLを定義する手続きを、buildステップの最初に記述します。

build:
    steps:
        - script:
            name: set DATABASE_URL env
            code: |
                export DATABASE_URL="postgresql://${POSTGRES_ENV_POSTGRES_USER}:${POSTGRES_ENV_POSTGRES_PASSWORD}@${POSTGRES_PORT_5432_TCP_ADDR}:${POSTGRES_PORT_5432_TCP_PORT}/postgres"

Gradleのテストを実行するステップを作る

次に、 set DATABASE_URL envスクリプトの後にGradleのテストタスクを実行するステップを追加します。

- script:
    name: run test
    code: |
        ./gradlew test

これでWerckerV2の上で、Heroku+Postgresqlに近い環境でJava8+Gradleのテストが実行できるようになりました。

最終的に出来上がった wercker.yml は以下のようになります。

box: yuasano/heroku:0.2

services:
   - id: postgres
     env:
       POSTGRES_PASSWORD: mypage
       POSTGRES_USER: mypage

build:
    steps:
        - script:
            name: set DATABASE_URL env
            code: |
                export DATABASE_URL="postgresql://${POSTGRES_ENV_POSTGRES_USER}:${POSTGRES_ENV_POSTGRES_PASSWORD}@${POSTGRES_PORT_5432_TCP_ADDR}:${POSTGRES_PORT_5432_TCP_PORT}/postgres"
        - script:
            name: run test
            code: |
                ./gradlew test

Heroku謹製のcedarイメージがDockerHubに置かれて、よりHeroku環境に近い環境でテストができるのは安心ですね。(Cedar14がベータの頃にHerokuにデプロイした時だけ動かない機能があって、原因がCedar14側だった経験があるので...)

続きを読む "Wercker v2でHerokuっぽい環境を作ってテストを動かす" »

2015年7月16日 (木)

【Herokuお絵かき】Herokuってな~に?

こんにちは、なかやまです。

この間のキャラクターが気に入ったので、引き続き使いまわします。

Heroku_01

 

キャラクター紹介

たろう

Heroku_02

 

じーちゃん

Heroku_03

 

#1 Herokuってな~に

インターネット中のたろう。

Heroku_04

 


とても素敵なアイデアが浮かんだようです。

Heroku_02

 

早くみんなに見せたくて仕方がありません。

Heroku_06

 

じーちゃんに聞いてみよう!

Heroku_07

 

Herokuの何がよいの?

Heroku_05

 

アプリ開発すると、インフラ構築にも人が必要だけど、、

Heroku_09

 

Herokuを使うと、インフラ部分はHerokuがやってくれるらしい。

Heroku_10

 

インフラ部分を面倒見なくて良い分、アプリを作ることだけに集中できるよね!

Heroku_08

 

だいたいのプログラム言語は動きます。

Heroku_12

Herokuが提供しているBuilpack(Herokuの環境のようなもの)

Ruby、Node.js、Coljure、Python、Java、Gradle、Grails、Scala、Play、PHP

https://devcenter.heroku.com/articles/buildpacks#default-buildpacks

最近はgoもはいったよ。

 

便利アドオンもいっぱい

Heroku_13_2

 

開発環境が無償で使えます。

ただし、1日6時間は休止させないといけませんが、普通に開発する分には問題なし。

Heroku_14

 

24時間稼動させたい場合は、$7でFreeからHobbyにプランを変えましょう!

Heroku_15

 

Heroku_16

 

今のリージョンはUSとEUにしかないのですが、

TOKYOリージョンができたらすごく便利だよね!ね!

Heroku_17

日本からの距離が遠いのでレイテンシ(遅延)が発生するそうです。

近場の日本にリージョンが欲しいですよね。

 

記事を書いている現在、142人の賛同者があつまっております!!

東京リージョンまってるよ!という方は、こちらも参加いただくとよいかも。

We ask for the Tokyo region of Heroku/東京リージョンに対応してください #heroku

 

 

私のHerokuの認識ってこんなかんじなんですけど、

あってますか?

Heroku_13_2

 

 

 

 

フィードバックいただけるとうれしいです。m(_ _)m

Heroku2_2_14

おたより(なかやま直通)

2015年7月 2日 (木)

HerokuとGitHubの連携を考える

こんにちは、浅野です。

今日は、8月以降に始まる開発案件(Heroku上にWebアプリを乗せる)でこんな風に開発を進めよう、と考えている開発のフローについて書きます。

目的

このPOSTでは、GitHubのリポジトリとHerokuを使った開発で、手動でのHeroku環境へのデプロイを減らしつつ、開発・テスト等の活動の並行性を維持するために、HerokuのGitHub連携機能をどう使うか、を整理します。

書くこと

Heroku上に乗せるアプリは以下の3つの環境を用意する想定です。

  • dev 開発環境。開発の最新版
  • staging 検証環境。リリース候補のテストを行う
  • production 本番環境。リリースされたもの

これらの環境に、いつ、なにを、どうやってデプロイするのかを考えます。

ブランチ戦略

何をデプロイするか、はブランチ戦略に密に関わってくるので、まず想定しているブランチ戦略を書きます。

ブランチ戦略は基本的にgit-flowを踏襲します。 git-flowについてはこちら(A successful Git branching model を翻訳しました)が詳しいです。

踏襲しない所 * 元々はサポートブランチになっている release ブランチを、メインブランチと同じくずっと存在し続けるものとします(理由は後述します)。混同を防止するために名前をstagingブランチとします。 * hotfixブランチは上記の変更に伴って、stagingブランチから作ってマージする。

各ブランチ間での変更の取り込みは、全てプルリクエストを介して行うように想定します。

図にすると下記のようなイメージです。

ブランチ間の関連図

Branching


デプロイ戦略

メインブランチのデプロイ

基本的に、それぞれの環境に対応するブランチに対してプルリクエストが受け付けられたタイミングで自動デプロイするようにします。 これは、それぞれの環境に対応するHerokuアプリケーションを作って、GitHub Integrationの automatic-deploysを設定します。

各環境とブランチ、アプリ名の対応は以下のようにします。

環境対応ブランチアプリ名
devdevelopdev-xxxxxx.herokuapp.com
stagingstagingstaging-xxxxxx.herokuapp.com
productionmasterxxxxxx.herokuapp.com

ここで「後述します」と言っていたreleaseブランチをメインブランチ相当にする理由を説明します。 git-flowを踏襲すると releaseブランチはリリースの度に作られて消えてしまいます。Herokuの automatic-deploys で指定するブランチが都度作られて消えてだと毎回設定を変える必要あるので、 設定そのままで自動デプロイするためにstagingブランチをずっと保持し続けるようにしています。

サポートブランチのデプロイ

サポートブランチの自動デプロイは ReviewAppを使ってデプロイします。 このReviewAppは、dev環境のHerokuアプリケーションに設定して、DB接続先などの環境変数情報はdev環境のアプリケーションと同じ値を使用します。

少し悩ましいのは、development -> staging, staging -> master といったメインブランチからメインブランチへのプルリクエストもおそらくReviewAppで対応するHerokuアプリケーションが作られてしまう事ですが、マージされたタイミングでアプリが消滅するので気にしない事にします。

これを先ほどのブランチ戦略の図に重ねるとこのようになります。

ブランチ・デプロイの図

Deploy


まとめ

HerokuのGitHub Integration機能を使うとこのようにGitリポジトリのブランチとHeroku上のアプリケーションを自動で同期させることが可能です。「デプロイする」行為をほぼ意識しなくて済むのは楽でいいですね。

2015年6月17日 (水)

なかやまがゆくHeroku本社への道 no.3~Herokuコマンドお絵かき~

こんにちは、なかやまです!

Heroku2_1_01_3

 

「なかやまがゆくHeroku本社への道 no.3」というタイトルですが、

Heroku本社に行くためにはHerokuの知識は必要ですよね!

ということで、今回はHerokuアプリを作るための基礎となるHerokuコマンドについて振り返ってみました。

Heroku2_2_02

 

 

heroku toolbeltをインストールする!

Heroku2_2_03

herokuアプリを作るためには、heroku toolbeltのインストールが必須です!

自分のOSにあったものをインストールしてくださいね。

heroku toolbelt

herokuコマンドでgitを使うのですが、gitのバージョンが低いと警告がでます。

gitは1.9.5以上が推奨ですので、gitのバージョンも合わせて確認しましょう。

 

 

heroku login!!

Heroku2_2_04

heroku toolbeltのインストールができたら、heroku loginをしてみましょう!

作成したHerokuアカウント情報を途中で入力していきます。

メールアドレスとパスワードは間違えないように。。

https://devcenter.heroku.com/articles/heroku-command#logging-in

 

 

heroku --version

Heroku2_2_05

ツールのバージョンがわかるコマンドです。

https://devcenter.heroku.com/articles/heroku-command#installing-the-heroku-cli

 

heroku keys:add

Heroku2_2_06

鍵ファイルを追加するときに使います。

heroku loginをした際に追加しているはずですが、あとから追加することもできます。

https://devcenter.heroku.com/articles/keys#adding-keys-to-heroku

 

 

heroku create

Heroku2_2_07

herokuアプリを作るときに呼ぶコマンドです。

heroku createの後にアプリ名を指定します。アプリ名はユニークにする必要があるので、すでに存在していると怒られます。

名前を指定しない場合はherokuが命名してくれます。

あとからアプリ名を変更することもできるので、安心ですね。

https://devcenter.heroku.com/articles/creating-apps#creating-a-named-app

 

 

git push heroku master

Heroku2_2_08

これはherokuじゃなくてgitコマンドになりますが、作ったアプリを公開するコマンドです。

このコマンドを入力することで、ローカルで開発していたアプリケーションがherokuに展開されます。

リリースしたアプリケーションに問題がある場合は、ロールバックすることもできます。

https://devcenter.heroku.com/articles/releases#rollback

Heroku2_3_01_2


 

 

heroku addons:create

Heroku2_2_10

アプリにアドオンを追加するコマンドです。

ログ監視のPapertrailを追加する場合は、以下のようなコマンドになります。

heroku addons:create papertrail

アドオンの詳細画面の下のほうにコマンドがかいてあるので参考にしてみてください。

Papertrail_addons_heroku

https://devcenter.heroku.com/articles/managing-add-ons#creating-an-add-on

 

 

heroku addons:open

Heroku2_1_11

アドオンのダッシュボードを開くときのコマンドです。

ログ監視アプリであればログ情報の確認ができます。

heroku addons:open papertrail

https://devcenter.heroku.com/articles/managing-add-ons#open-an-add-on-dashboard

 

 

heroku apps:info

Heroku2_2_12

アプリの情報を見るコマンドです。

girリポジトリ、所有者、リポジトリサイズ、スラグサイズ、スタック、アプリのUrlを見ることができます。

https://devcenter.heroku.com/articles/using-the-cli#app-commands

 

 

今回は基本的なコマンドをご紹介しました。

Heroku2_2_13

これらのコマンドはHerokuのコンソールからも設定できるようになっています。

便利ですね。

 

 

 

フィードバックいただけるとうれしいです。m(_ _)m

Heroku2_2_14

おたより(なかやま直通)

2015年6月10日 (水)

CloudDesignPattern、それってHerokuでもできますよ!あ、でもそれはできません。

どうも、最近Herokuの勉強をさぼりがちのおっぴーです。 そのため今回は、「試してみた!」という内容ではなく、主観が多く含まれる内容となっております。

さてHerokuの勉強をサボっているさなか、改訂版が出版されたAmazonWebServiceの『クラウドデザインパターン設計ガイド』を週末に読みました。

クラウドデザインパターンを読んでいる(かつ、操作もしてみる)と、

  • Webサービスを運営するためのサーバー群の調達が早くできる
  • サーバー、ネットワーク、DBなど各コンポーネントに拡張性がある
  • IaaSのトップランナーとして進化し続けている

という点をしみじみと感じます。 実サービスでAWSを利用することが一般的になってきた今、いまさらな感想ですが、本当に便利なサービスだと感じます。

なにか新しいサービスを始めよう!と思った時に、まずはサービス規模を想定し、CPU、メモリ、ハードディスクの容量を予測し、消費電力を考え、回線使用量を見積もり、、、 それが終われば、各業者に相見積もりをとって、、、といったことを作業にまつわる悩みが減らせることは大きなメリットです。 さらにCloudDesignPatternというサーバー構成のパターン集は、ある特定の状況における十分に検証された解決策なので、「こんな問題に対処したいのだけど、どんなサーバー構成にすれば良のだろう?」と悩む時間を減らせます。

このことにより、「こんなサービスを始めよう!」と決めてから、「つくってみた!」までの期間を短くできます。意思決定から結果にいたるまでの時間が短くなることはビジネスのアジリティをあげることに直結します。

このように考えると、PaaS、Herokuの魅力とは、IaaSよりもさらにサービスの構想段階で悩むことを減らせる、というものだと感じています。 なぜならば、Herokuはサービスとして、いくつかのCloudDesignPatternに対応済みの環境を提供しているからです。

たとえば、CloudDesignPatternの基本パターンで紹介されている5つのパターンのうち、ScaleUpパターンScaleOutパターンはもちろん、可用性のパターンで紹介されるMulti-Serverパターンは、提供されているコンソールから2,3クリックで完了してしまいます。 また、動的コンテンツの処理パータンであるScheduled Scale OutパターンAPIと無料のAddOnであるHerokuSchedulerを組み合わせると簡単に設定できてしまいます。

くわえて、Ondemand Activationパターンのような機能は、One-Off Dynoが提供しています。

さらにさらに、CDPではありませんが、AWSをはじめとしてIaaSを利用することでサーバーの調達とセットアップの手軽になったことから実現できるようになったBlue-GreenDeployはどうでしょうか? これもPrebootという仕組みやAPIからリリースをロールバックできることから、簡単に実行できます。

いやいや、「Herokuではこんなことができないでしょ?AWSではできるけど」という部分はもちろんあります。 たとえば、有償のAddOnを利用しないと、HerokuではAutoScaleができません。LogAggregationパターンについても、Papertraillogentriesなどの有償AddOnの利用が必要です。 さらに、メモリやCPUの選択肢はほとんどないといって良いと思います。たとえば、10GB以上のメモリが必要になるシステムを動かしたい!と考えるとHerokuは選択肢に入りません。 Herokuでスペックが一番良いPX Dynoでも6GBまでしかメモリの提供がされていないからです。

Herokuを選択することはCloudDesignPatternに対応済みの環境を享受できる一方で、AWSなどのIaaSにある自由度や選択肢が狭めることになるのは事実です。 一方で、強引に良い方向に考えると、そもそもできないことは悩む必要がなくなる(というより、これもやりたい、という点を切り捨てる)、という点でもWebアプリケーションをつうじてサービスを提供したい、というゴールに到達するための悩みが減らせる、といえます。

上述したように、IaaSやPaaSに感じるメリットは、サービスが提供する拡張性を前提として「開発の前の悩みがすくなくなる」ことから、ビジネスのアジリティをあげられるというです。 ですので、IaaS?PaaS?、AWS?Heroku?など、どちらを選べばよいの?ということをお悩みなら、「どれだけ最初に悩むことを減らしてWebアプリケーションを利用したサービスを提供したいか」を軸に検討してみるのはいかがでしょうか。

たとえば、Ruby on RailsやSpringBootのようなWebアプリケーションのフレームワークを用いて開発を行うようサービスは、まずはHerokuを利用することを考えて良いと思います。 もちろん、厳しい非機能要件があらかじめ想定される場合は、おすすめできない部分もありますが、アイデアベースのサービスをはじめたい、という場合ならオススメできます。

ちなみに、Herokuのプラットフォームの背後にはThe twelve-factor appという考え方があります。 もしも、Herokuを検討する場合は、現状の機能がなぜこうなっているのか、今後はどのように発展しそうか、という点の参考になりますので目を通しておくと良いと思います。

あと、AWSにはElastic BeanstalkというPaaSに類するサービスもありますね。 これとの比較はまたこんど。(できたらいいな)

2015年6月 3日 (水)

Review Apps を試してみた の巻

こんにちは、浅野です。 前回からだいぶ時間が空いてしまいましたが、予告していたPullRequest Deploy改め Review Appsを実際に実行した手順を紹介します。

作業の流れ

今回の検証は以下の流れで作業をすすめました。

  1. 同期元Githubリポジトリを作成
  2. 同期先Herokuアプリの作成
  3. Github Integrationの設定
  4. PullRequestを送る

同期元Githubリポジトリを作成

まずGithubリポジトリを作ります。 今回は、heroku-pullrequest-deployのリポジトリを作りました。

同期先Herokuアプリの作成

ここでは、Herokuアプリを作成と、次ステップで app.json の生成ウィザードの挙動を確認する為に addon追加、環境変数の追加を行います。

herokuアプリの作成

herokuダッシュボードからgithub-pr-deploy-sample を作りました。(以降、実際に試される方はご自身のアプリ名に差し替えてください)

addonの設定

開発で馴染みのある下記2種類のアドオンを追加します。

  1. Heroku Postgresql
  2. Redis Cloud

この2つのアドオンを追加すると、下記の環境変数が自動的に追加されます。

  1. DATABASE_URL
  2. HEROKU_POSTGRESQL_BRONW_URL (BROWN部分は環境によって異なります)
  3. REDISCLOUD_URL

環境変数の追加

自動で追加される環境変数の他に、手動で追加した環境変数がapp.jsonの生成ウィザードでどう扱われるかを検証する為に手動で環境変数を設定します。環境変数名はHOGEHOGE, 値は piyopiyo とします。

Github PullRequest Deployの設定

ここからが本番。 PullRequest Deployを設定します。 ゼロの状態から始めるには以下の手順になります。

  1. 同期対象Githubリポジトリの選択
  2. PullRequest Deployの設定
  3. app.jsonの生成

同期対象Githubリポジトリの選択

まずは、HerokuからGitHubへアクセスする設定を行います。

Herokugithubdeploy


  1. Deployタブを選びます
  2. GitHubを選びます
  3. Connect to GitHubをクリックします

(初めてGithub Integrationを使う場合は、Githubで Heroku Dashboardアプリからのアクセスを許可するかの認証がでます。)

続いて、同期対象となるGithubリポジトリを選択します。

Herokugithubconnectrepo


  1. 対象となるリポジトリのオーナを選択(今回は yuasano )
  2. 対象となるリポジトリを検索
  3. 対象となるリポジトリの connect をクリック (今回は heroku-pullrequest-deploy )

PullRequest Deployの設定

続いて、PullRequest Deployを有効にします。

注意書きが2点あるので気をつけてください。 大胆に意訳すると

  1. PullRequest Deployは、development/test環境で使う想定で、production環境で使うことは推奨しない。
  2. PullRequestで生成されるアプリの Dyno Hour / Addon もこのユーザの課金対象となる

のような感じです。 問題なければ Enable Pull Request Deploys をクリックします。

次に自動デプロイを有効にします。今は、PullRequest Deployに必要な app.json がリポジトリにないので設定を有効にできないので、app.jsonを作成するウィザードが呼び出せるのでそちらを使って app.json を作成します。(作成は次ステップ)

Executeappjsonwizard


  1. Create new apps for new pull requests automatically にチェックを入れる
  2. リポジトリに app.json がないので設定できない、との旨のメッセージが表示される
  3. Create an app.json File... をクリック

app.jsonの生成

app.jsonの生成画面が開いて、app.jsonのスキーマ の必要最低限の項目が並んでいます。

今回は、環境変数の共通化を見てみたいのでEnvironment の箇所だけを変更して、リポジトリへapp.jsonを登録します。

Environmentの変更

環境変数のリストに DATABASE_URLHOGEHOGE それぞれどのように扱うかを指定します。

Editappjson_2


  • DATABASE_URL は Copy at build time
  • HOGEHOGE は Generate Secret

リポジトリへの登録

Output の箇所に、生成される app.json のプレビューが表示されているので、これを確認して問題なければ Commit to Repo and Enable Pull Request Deploys をクリックします。

これで、GitHubリポジトリのmasterブランチ(defaultブランチ)にapp.jsonがコミットされます。

補足

なお Config Varsのプルダウンで選択できる4種類は以下のように使い分けるのだと理解しています。

  • Copy at build time … ビルド(アプリを作る時)にその環境変数の値をコピーする。親アプリの環境変数の設定値をコピーする場合はこれを指定する。
    • Copy now ... 現時点での親アプリの環境変数の設定値をコピーします。選択すると警告が表示される通り、ここで入力した値は app.json に直接記載されてバージョン管理下に置かれるので、見られたくない情報は書かないでください。
    • Set value ... 右側テキストボックスに入力した文字列を設定します。これも Copy now同様 app.jsonに直接記載されるので取り扱い注意です。
    • Generate Secret ... ビルド(アプリを作る時)に生成されたランダムな文字列が設定されます。Ruby On Railsの SECRET_KEY_BASE などはこれを使うのだと思います。

PullRequestを送る

このリポジトリに対して送ったPullRequestがこちらです。

Pullrequestdeploy


リスのアイコンで、2回Herokuにデプロイされている様子がわかります。 1回めはPullRequestを送った直後のデプロイです。この時点ではこのアプリが動いておらず(InternalServerErrorが出ていた)、原因を調べたところ、 config/secrets.yml ファイルが .gitignore に含まれていてリポジトリに格納されていなかったのが原因でした。

これを修正してpushしたところ、自動的に github-pr-deploy-sample-pr-1 へのデプロイが動いて、無事問題が解決していることが確認できました。

このPullRequestをマージすると、 github-pr-deploy-sample-pr-1 アプリは削除されて Dashboardからも消えました。

PullRequestと自動で同期してくれるのは非常に便利で助かるな?と思いました。

みなさんも是非使ってみてください。

公式情報ソース

Heroku Review Apps Beta

採用情報

株式会社フレクトでは、事業拡大のため、
Salesforce/Force.comのアプリケーション
開発
HerokuやAWSなどのクラウドプラッ
トフォーム上でのWebアプリケーション開発

エンジニア、マネージャーを募集中です。

未経験でも、これからクラウドをやってみた
い方、是非ご応募下さい。

フレクト採用ページへ

会社紹介

株式会社フレクトは、
認定コンサルタント
認定上級デベロッパー
認定デベロッパー
が在籍している、
セールスフォースパートナーです。
heroku partnersにも登録されています。
herokuパートナー
株式会社フレクトのSalesforce/Force.com
導入支援サービス
弊社の認定プロフェッショナルが支援致します。
・Visualforce/Apexによるアプリ開発
・Salesforceと連携するWebアプリ開発
も承っております。
セールスフォースご検討の際は、
お気軽にお問合せください。
Powered by Six Apart