シナリオ通りにアプリケーションをリリースしてみる
最後に、実際にアプリケーションを更新してどのような動きになるか見てみましょう。おおまかに、次の4つの作業でリリースできます。
- ソースコードを変更して、更新用のブランチをプッシュする
- プルリクエストを作成する
- masterブランチへマージする
- Promote!!
ソースコードを変更して、更新用のブランチをプッシュする
準備いただいたGitHubリポジトリから、“git clone”でソースコードをローカルへ準備します。新たに、更新用のブランチ「fix-a」を準備してソースコードを修正し、変更をコミットします。あとはGitHubのリポジトリへプッシュすると、どうなるかという場面です。ソースコードをローカルに落として、ブランチを作るまでがコマンド1です。
$ git clone git@github.com:tabesfdc/delicious_recipes.git Cloning into 'delicious_recipes'... remote: Counting objects: 134, done. remote: Compressing objects: 100% (89/89), done. remote: Total 134 (delta 35), reused 124 (delta 32), pack-reused 0 Receiving objects: 100% (134/134), 32.13 KiB | 0 bytes/s, done. Resolving deltas: 100% (35/35), done. $ cd delicious_recipes/ $ git checkout -b fix-a Switched to a new branch 'fix-a'
サンプルコードはRubyで書かれているので、わかる方は内部を読んでいただきながら試しに修正してみてください。どのファイルを変更したら良いかよくわからないという方は、「app.json」というファイルがあるので、“description”部分を適当に変更してみてください。例えば、以下のように「テスト」とおもいきって変更してみます。
{
"name": "delicious_recipes",
"description": "テスト",
"scripts": {
"postdeploy": "rake db:migrate"
},
"env": {
},
"formation": {
},
"addons": [
"heroku-postgresql"
],
"buildpacks": [
{
"url": "heroku/ruby"
}
]
}
変更をコミットして、GitHubへプッシュします。コマンド2がその実行内容です。これでソースコードがGitHubへプッシュされました。
$ git commit -am 'テスト' [fix-a 6b92618] テスト 1 file changed, 1 insertion(+), 1 deletion(-) $ git push origin fix-a Counting objects: 3, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 295 bytes | 0 bytes/s, done. Total 3 (delta 2), reused 0 (delta 0) remote: Resolving deltas: 100% (2/2), completed with 2 local objects. To github.com:tabesfdc/delicious_recipes.git * [new branch] fix-a -> fix-a
Herokuのダッシュボード画面に戻って、［Tests］というタブを見ると、図10のように今プッシュしたソースコードがHeroku CIによって自動的にテストされ、その実行結果を確認することができます。今回プッシュしたfix-aの内容はきちんとテストされ、うまくテストもパスしたようですね。
プルリクエストを作成する
GitHubからプルリクエストを作成しましょう。実際にプルリクエストを作成してみると、図11のような画面になります。通常の画面とちょっと異なる部分が2点あります。
- 自動的にHeroku CIによりテストされたことを示す「All checks have passed」内の「continuous-integration/heroku」部分にテストの結果が入っている
- log部分に「requested a deployment to staging-recipes-pr-11」とあるように、自動的にReview Apps のデプロイがリクエストされたことがわかる
しばらくして、Herokuダッシュボードの画面を見ると、「REVIEW APPS」部分に、GitHubメッセージにあった「staging-recipes-pr-11」という一時的なアプリケーションが作成されています。プルリクエストを上げただけで、自動的に実行環境が準備されました！ あとは、このアプリケーションを実際に起動させてテストしてみるもよし、実行ログを見てみるもよし、プルリクエストを受け付けて、単体テストも終わったアプリケーションが、正しく実行されているかどうかを検証できます。
masterブランチへマージする
検証して問題がなければ、GitHubからfix-aブランチをmasterブランチへマージします。
すると、図14のようにHerokuダッシュボード上のReview Apps がなくなり、新たにステージング環境へ、ビルドが走ります。もちろん、マージされた段階で自動的にHeroku CIも実行されるので、先ほどと同じように［Tests］タブを見ると「Merge pull request ...」というテストが実行されてパスされていることがわかります。
このように、GitHub上でプルリクエストを受け付けてマージしただけにもかかわらず、Heroku側では自動的にテストが実行され、自動的にステージング環境が準備されました。
Promote!!
最後に本番環境へリリースです。ステージング環境の［Promote to production...］をクリックしてPromoteしてください。即時に本番環境へリリースされます。即時です。すごい！！
Herokuでチーム開発を上手に調理するための、おいしいレシピをご紹介しました
Herokuは、GitHubと連携して、Heroku CIやHeroku Pipelinesと組み合わせることで、アプリケーション開発をおいしくする「継続的インテグレーション」や「継続的デリバリー」をカンタンに提供できることが、ご理解いただけたのではないでしょうか。
チーム開発とGitHub、そしてGitHubとHeroku、これらを美味しく調理するために必要な「おいしいレシピ」を今回はご紹介しました。これらのサービスの組み合わせは千差万別です。組織ごとに最適な調理方法を見つけて、みなさまにそのレシピをご紹介いただければ幸いです。
