Herokuのステージングブランチとは?(導入編)

こんにちは、皆さん!

ステージングブランチというものをみなさんもどこかで一度は聞いたことがあるかもしれない。特にすでに会社でHerokuを使っているという場合はなおさらである。今回はWeb開発を効率化し、そして、メインテナンスをより簡単にさせてくれるステージングブランチについて紹介していきます。(実践編はこちら→
Herokuのステージングブランチとは?(実践編) - Programming_Shopの日記


  • トピック:
  1. ステージングブランチとは?
  2. ステージングブランチの利点


  • リソース:
  1. Managing Multiple Environments for an App | Heroku Dev Center


ステージングブランチとは?

***注意***
以下の内容を理解するにはGitの知識が少し必要になってきます!

まず、初めにステージングブランチとは何かについて説明していこうと思う。ざっくり簡単に言うと、GitのマスターブランチがHerokuにデプロイしたコードでステージングブランチはGitのマスターブランチ以外のブランチといえる。つまり、実際に運営しているウェブサイトとは別にもう一つ同じ内容のウェブサイトを持つことができるということだ。
もっと一般的な例でいうのなら、劇を例に挙げて、ローカルでのテストが練習、ステージングブランチでのテストがリハーサル、そして、本家のウェブサイトにデプロイが本番といったような感じだ。(以下の図参照)

f:id:Programming_Shop:20181209092651p:plain
劇とウェブサイト構築の対称
そして、Gitでマージするように、このステージングブランチのコードはいつでも本家の方のウェブサイトにプッシュすることができるのだ。

ステージングブランチの利点

では、本題ですね。いったいなぜステージングブランチを使う必要があるのか?
大きく分けてステージングブランチを使うことには2つの利点があります。

  • Herokuにデプロイした際、エラーがあっても、ユーザーに影響を与えない

Herokuとローカルでテストしたときに内容が違うことはよくある。例えば、レイアウトのサイズ感が少し違う(これに関してはどうしてなっちゃのかいまだに謎)など。これをユーザーが直接見る本家のウェブサイトにデプロイしないで、ステージングブランチにデプロイすることで、事前確認ができ、修正することができる。

  • Herokuでしかテストできない要素がある

少し1個目とも被るが、例えば、メールをユーザーに送信するものなどは確かにローカルでテストコードを書いてテストしてみることもできるが、やはり、最終的にはHerokuにデプロイした後の状態で確認する必要がある。この時、本家に直接デプロイすると、ユーザーもその新しいエラーのあるかもしれない機能に触れる可能性があり、非常に望ましくない。なので、まずはステージングで確認するところから始める。

これらを踏まえると、下記のような仕事の流れができる。

f:id:Programming_Shop:20181209093901p:plain
ステージングブランチと仕事の流れ
このようにプログラマーはローカルとステージングの間を行き来し、最終的に完全なものだけをユーザーに届けるのというシステムになっているのだ。

まとめ

導入編はここまで。次は実践編で実際にどうやったらHerokuでステージングブランチを実行することができるのかを紹介していきます。実際に自分のアプリケーションに取り入れたい人はぜひ下記のリンクからどうぞ↓↓
Herokuのステージングブランチとは?(実践編) - Programming_Shopの日記


ご精読ありがとうございました。では、また次回まで✌



Herokuのステージングブランチとは?(実践編)↓↓
programming-shop.hatenablog.com