こんにちは、皆さん!

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


トピック

リソース


ステージングブランチとは?
***注意***
以下の内容を理解するにはGitの知識が少し必要になってきます!

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

劇とウェブサイト構築の対称

そして、Gitでマージするように、このステージングブランチのコードはいつでも本家の方のウェブサイトにプッシュすることができるのだ。


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

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


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

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

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

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


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

ステージングブランチと仕事の流れ

このようにプログラマーはローカルとステージングの間を行き来し、最終的に完全なものだけをユーザーに届けるのというシステムになっているのだ。


まとめ

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


皆さんの役に立つことを願います!
では、また次回まで✌
記事更新はツイッターで告知するので、ツイッターの方でもフォローお願いします!

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です