【Git】プロジェクトでの使い方
バッチ処理を構築する
分析プロジェクトを経験していると、分析処理バッチを構築する事があると思います。
普段、分析だけを行うなら開発環境とか本番環境とか、
あまり気にすることが無いと思います。
ただ、バッチを構築するならば、本番・開発をきちんと分けて、
構築するべきだろうと思い、自分の整理も含めて記事にしました。
分析プロジェクトの際のgit利用を想定しているので、
もしかしたら、エンジニアとしてのgitの使い方とは少し異なるかもしれません。
とはいえ、私もエンジニア出身では無いので、
間違いや考慮不足のところがあるかもしれません。
その際には、ご指摘いただけたら幸いでございます。
ブランチの役割
master
staging
本番と同じ環境を整備した状態の開発環境。
developで開発された機能をステージング環境で試験運用する。
ステージング環境では、本番に適応するためのテストになるので、
細かく機能の確認をする必要がある。
develop
主に開発を行うためのブランチ
新機能を開発する場合は、stagingからブランチを生やして、
作業を行うようにする。
もう少し詳しく見ていきましょう。
master
ステージング環境で動作検証がクリアした内容を展開する。
本番環境に対して直接スクリプトの編集などは禁忌である。
処理
許容する処理としては、
git pull origin masterのみ
スクリプトの編集などは一切行わない
本番環境のサーバー内で実行される。
githubの設定
マージリクエストを投げるときに、masterへマージするのではなく、
開発からステージング環境へマージするようにデフォルト設定を変えておきましょう。
手順は以下のとおりでございます。
①git cloneの後、staginブランチを作成し、git push origin stagin
②githubのコンソール画面よりsetting画面へ遷移する。
③settingのコンソール画面にBranchesがあるので、そちらを選択
④Default branchを選択できるのでstagingをプルダウンで選択する
staging
本番環境に展開する一歩手前の状態になる。
develop環境で作成された機能を本番さながらに試験する環境。
処理
developブランチで作成された機能をstagingブランチにマージする。
マージされたスクリプトを動かしてみて、期待通りの動きをするのか、
機能が緩衝してエラーが発生していないか確認をする。
develop
処理
ステージング環境に展開するために、新規機能や処理を作成する。
新たに追加した処理の個別動作確認の後、ステージングへマージするために、
全体フローでも動作確認を行う必要がある。
