こんにちは、浅野です。

次はPullRequest Deployの手順について書くよ、と宣言したものの別のポストです、ごめんなさい。 (PullRequest Deployは Review Appsという名前が与えられたみたいです)

今回は、Salesforceさんが主催されているHeroku基礎トレーニングを紹介します。

というのも、5月22日(金)に、私がこのトレーニングの講師を担当させていただいていたのです。

このブログを見てくださる方は、Herokuに興味をお持ちの方だと思うので、 そういった方が「そのトレーニング、ここはどうなっているの？」 と疑問に思われる事に回答します。

どうしてSalesforceさんが開催される教育をFlectが？

Salesforceさんとはお仕事で密接な関係があり、Herokuのテクニカルなテーマでは何かとお手伝いさせていただいている御縁で協力させていただいております。昨年末に開催された、Salesforce World Tour TokyoのHerokuブースもFlectメンバーが協力していました。 @herokujpのPOST

このトレーニングの講師は、FlectでHerokuを使ったシステム開発を担当しているメンバーが務めています。

受講する為に必要な前提知識は？

必須となる知識はありません。講習の内容の理解をより深めるには下記の3つです。

1. gitの基本的な操作(リポジトリをクローンする、変更をコミットする、リモートリポジトリへ変更をプッシュする)
2. Java(演習で簡単なJavaのWebアプリケーションをつくるため)
3. Windowsのコマンドプロンプト操作

どんな事をやっているの？

4章で構成されており、それぞれ以下のような内容になっています。

• 第1章 Herokuの特徴・市場での位置づけ、Herokuを操作する環境の構築・アプリケーションのデプロイ
• 第2章 Herokuの内部コンポーネントの動作
• 第3章 Herokuのアドオン紹介
• 第4章 Heroku開発でのトラブルシュート(開発編、運用編)

何ができるようになるの？

受講後には以下のようなことが可能になっている、と想定しています。

• Heroku上に典型的なWebアプリケーションを作って公開する
• 必要なアドオンが何かがわかる

でも、お高いんでしょう？

半日の講義で、受講料は3万円となっております。

会場はどんな感じ？

会場は、Salesforceさんのトレーニングルームで、とても綺麗な会場です。

教室の後ろには、 文房具やちょっとつまめるお菓子、空調が寒いと感じる方の為のひざ掛け等が用意されています。

こういった配慮は嬉しいですね。

会場のマシン環境はどんな感じ？

マシンはお一人様毎に1台、環境セットアップ済みのWindowsのノートPCが用意されています。 演習には問題のないスペックのマシンです。

演習時、自分で持ち込んだPCを使うのは可能？

環境が教室のマシンと違って演習が上手く進められない場合があるリスクはありますが、お使いいただいてもかまいません。

会場用のマシンには、JDK、Apache Maven, PostgreSQLがインストールされています。 (Herokuを操作するためのHeroku Toolbeltは演習時にセットアップします)

動作確認

それぞれ、下記のコマンドを実行してバージョンが表示されることを確認してください。

javac -version

mvn -version

psql --version

(psqlだけ、半角ハイフンが2つです。)

この他にもご質問ございましたら、ぜひコメント欄等でお知らせください。可能な範囲で回答いたします。

次回の開講は7月を予定しておりますので、興味のある方はぜひこちらをチェックしてみてくださいませ。

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

今回も技術話ではないので、ゆるっと見てやってください。

前回の記事→no.1

順調に行けば、9月で終わるコーナーですが、今年行けない場合はさらに1年間続ける予定です。

パスポートの期限は大丈夫でした！2019年までチャレンジできそうです！

サンフランシスコに行ったことのある人に話を聞いてみる。

かに食べる、ゴールデンゲートブリッジに行く、チョコレートを買う。。

あと向こうで知り合って行動した人たちとは今も仲良しと聞いて、いいなぁと思いました。

（せっかくお会いしたのにWAZAの話を聞き逃しました。。）

そういえば、Salesforceユーザー会で自慢大会があるのですが、その景品がDreamforceご招待券だそうです。ユーザー会はSalesforceを利用してる会社さんが集まるコミュニティです。

（しかしパートナーが出て行くわけにもいかず、、Salesforceユーザーのみなさんはチャンスですよ～）

今年の「Dreamforceご招待」を手にするのは？

Herokuの日々のアップデートには感心します。

Salesforceは年3回なので、Herokuのupdateの速さについていくのが大変。

ちなみに、前回ポストのご案内をして終わったのですが。

なんと1通入ってました！（ありがとうございます！！）

なので今後も細々と続けていきます↓

おたより（なかやま直通）

おたよりまってまーす！

なかやま。

こんにちは。 ゴールデンウィーク中に入籍をしましたおっぴーです。

Herokuさんも、Dockerが利用できるにようなったり、あたらしい料金体系が発表されたりと、驚きの（というか、影響が大きそうな）発表が多いですね。 すでに、Dockerや新料金については下記のように記事をまとめている方がいらしゃいます。

Herokuの'docker:release'の動き

HerokuがDockerのサポートを開始、DockerコンテナがPaaSで運用管理可能に。その仕組みは

Herokuの新しいプライシングがついに公開。Freeは1日6時間以上Sleepする必要あり

そこで今日は、新料金について「結局、お得なんだろうか」という点と「こんなときどうな動きをするの？」という疑問についてまとめてみました。 疑問については、実際の調査はまだですので、少々、お待ちくださいませ。

いままでは無料でサイトを運用できたのに。。。

まずは、現状のdynoについて整理しましょう。 現状のdynoには下記の特長があります。

• 1X Dynoを750時間運用する分の料金が無料(750 dyno hourの無料利用枠)
• PXDyno以外では1Dynoで運用していると1時間非アクティブだとsleepする

この無料枠ですが、750時間を日付に換算すると31日分です。

このため、バットノウハウと言って良いかもしれませんが、1XDynoを1つだけ立ち上げて、定期的にアクセスをするcronなどを仕組むことでsleepさせず、 サイトを無料で運営することができました。

企業サイトのような比較的アクセス数が少ないサイト（そもそもサイトがそういう状態なのが問題だよね、と言うのは別の話）などは、こうした運営をしている方もいらっしゃるかも知れませんね。 僕自身は上記の方法で、営業日のみだけ定期的なスケジュール通知をしてくれるhubotを動作させています。

ちなみに今回、大きな影響を及ぼしているsleepという概念ですが、下記を読んでいたので、 単純に、アクセスが1時間ない場合に、dynoがsleepしている状態でもdyno hourを消費していると思っておりました。

https://devcenter.heroku.com/articles/usage-and-billing#dyno-sleeping

今回からはsleep=dyno hourの消費なし、という定義になったのか、など疑問点があるのですが、もはや利用しない概念になりそうなので調べるのも微妙ですね。。。

お安くなった？Professional Dyno

あたらしい料金の一番の違いは、いままであった750dyno hourの無料枠がなくなったことです。 このため、無料でサイト運用したいと考えた場合、適当な手段がなくなった、といえるでしょう。

ただし単純に価格が上がったわけではありません。 公式ブログでも30%ぐらい安くなったよ、書いてあるとおり、2Dyno構成の場合は従来よりもお安く運用できます。 ただし、750dyno hourの無料枠がなくなったので、1dynoの場合は実質の料金が上がっています。

• 1Dynoの構成の場合

（※円の表記は1ドルが120円の換算です）

• 2Dynoの構成の場合

（※円の表記は1ドルが120円の換算です）

1Dynoの運用を考えると価格は上がったのですが、本番環境の冗長化を考える場合は、かならず2Dynoで動作させます。 このように考えると、Standar-1X Dyno以外は、本番の運用費用がさがった、といえる体系になったようです。

新しいfree dynoは開発・検証向き

今回の新料金ではDynoTypeが見直され、free dynoとhobby dynoが新たに加えられました。

free dynoはいままでのよう無料で運用できるweb dynoにくわえて、無料のworker dynoを含みます。 ただし、下記のような制限があるため無料で、24時間365日動かすようなサービスを運営できません。

• 30分、非アクティブの状態でSleepする
• 1日18時間までしか起動できない
• web dynoとworker dynoを1つだけしか起動できない

一方、hobbyは月額7ドル確実にかかるようになりました。 このため「無料」を利用の条件とすると選択肢から外れるdynoになってしまいました。 しかし、下記のような特長をもっているため、お安い料金で本番で利用できる環境を手に入れられます。

• 1Dynoでもsleepしない
• 24時間365日稼働する

また、free、hobbyともに、いままで課金の対象であったheroku schedulerで起動されるone-off dynoやheroku run bash で起動されるone-off dynoも無料になります。

個人的にはfree dynoはかなり嬉しいdynoですね。 web dynoにくわえて、worker dynoやheroku schedulerを利用すると無条件で課金されていましたが、そんなことを気にすることなく利用したアプリケーションを社内公開などができます。 また、スケジュールを通知するbotなど、営業時間のみ運用したい場合にも十分な利用ができそうです。

で、結局は

今回の新料金では、

• hobby dynoをつくり、Ping作戦などで無料利用していたユーザーがからしっかりとサービス提供分の料金を徴収するようにした
• free dynoをつくり、開発や検証で利用できる環境として利用できるようにした
• Performance dynoは本番運用を想定して、2Dyno構成でさらに低額で利用できるようにした

ということで、フリーミアム的なビジネスモデルから脱却し、しっかりと利用しているユーザーにお得な価格体系にきりかわった、と言えると思います。

一方で、いままで無料でサイト運営しているユーザーさんからすると「えっ！値上げ！」という感想になりそうですね。

ですが、hobby dyno に切り替えることを想定しても、小規模サイトを運用するPaaSとして7ドル、日本円で840円（1ドルが120円の換算です）で利用できるってかなりお得な気がします。

これってどうなるの？

ただし、新価格にともないでてきたDynoTypeについてはまだまだ挙動や仕様に謎が多いです。

• free dynoのsleep時間は選択できるのか。1日6時間のsleepを違反するとどうなるのか。
• free dyno でworker dynoやheroku schedulerを設定しているとsleepしたことになるのか。
• hobby dynoは再起動しちゃうのか。prebootができなそうだけど、その時どうなるのか。
• Professional dynoのworker dynoやone-off dynoの料金は無料になったのか。

これらの点は、近いうちに調査、検証して見たいと思います。

Heroku Github PullRequest Deploy の巻

こんにちは、浅野です。

今回は、PublicBetaで復活した Github PullRequest Deployの紹介です。

簡単に3行で

1. GithubのPullRequestに同期して自動的にHerokuアプリが作られます
2. 設定が必要なapp.jsonを母体アプリから生成するウィザードが用意されました
3. 親アプリの環境変数の値コピーができるようになりました

実際に設定を行って使ってみた手順、は次回のポストで紹介します。

Github PullRequest Deploy とは

Herokuアプリケーションと同期させたGithubリポジトリへプルリクエストが送られた時に、 そのプルリクエストの内容のHerokuアプリケーションが自動的に作られる仕組みで、下記のような特徴があります。

• HerokuアプリケーションはPullRequest単位で自動的に作られます(親アプリ名がhogeだった場合、#1のPullRequestで作られるアプリ名はhoge-pr-1)
• そのHerokuアプリケーションのライフサイクルはPullRequestのライフサイクルと自動で同期します。
  • PullRequestが作られた時にHerokuアプリケーションも作られます
  • PullRequestが更新された時(コードが追加でPushされた時)にHerokuアプリケーションも更新されます
  • PullReqeustがマージされた時にHerokuアプリケーションも消滅します

何が嬉しいの？

• PullRequestの変更点を確認する時に、動く環境を作るのが省力化できます
  • これまでは自分でブランチをチェックアウトして、ローカルで動かすとか・Herokuにデプロイ、などの対応だった
• 動的テスト(Seleniumを使ったWebUIテスト、Vaddyのような脆弱性スキャン、お客様側の受け入れテスト)を実行しやすくなる

app.jsonの生成ウィザード

PullRequestDeployを使用するには、リポジトリ直下に app.json を置く必要があります。 このapp.jsonは、規模の大きなアプリになればなるほど後から作るのが面倒になります。(使用するaddonの数が増えたり、環境変数の数が増えたり) このウィザードを使用すると、母体アプリケーションで定義されている内容からアドオン・環境変数の項目が設定済みの app.json の雛形が作られ、それをカスタマイズした後にgithubリポジトリへコミットまでを行うことができます。

親アプリの環境変数の値コピー

親となるHerokuアプリケーションの環境変数の値を、PullRequestごとに生成される子Herokuアプリ―ケーションでコピーできるようになりました。 これによって、コード管理したくない秘匿情報(DBの接続情報、何らかのサービスのAPIキー等)を子Herokuアプリケーションに引き渡す事ができます。

例えば、開発環境で子HerokuアプリケーションともDBを共有するようにできるようになるので、 developブランチの内容をデプロイした親Herokuアプリケーションで、特定のデータの組み合わせで発生するバグが そのバグ修正を実施したPullRequestのブランチをデプロイした子Herokuアプリケーションで解消されている、が簡単に確認できるようになります。

app.jsonの書き方

親Herokuアプリケーションから値をコピーしたい環境変数 INHERIT_THIS_CONFIG_VAR をapp.jsonの "env"で以下のように定義します。 これで親Herokuアプリケーションで定義されている値をそのまま利用できるようになります。

"env": {
    "INHERIT_THIS_CONFIG_VAR": {
      "required": true
    }
  }

次回ポストでは、これらを実際に設定して使ってみた手順をご紹介いたします。

公式の情報ソース

• GitHub Integration#pr-apps
• GitHub Integration: Pull Request Apps