本番化フェーズ
リリースする時のブランチの取り回しと、バージョンの打ち方
本番用のソースコードをスナップショットとして記録していくことは、とても重要です。
「一体いつから間違っていたんだろう？」という疑問にすぐ答えられるようになります。それは、自分のためにも、誰かのためにもです。
Web制作では、一般公開がされた単位でバージョン番号を制定して記録していくようにします。
バージョン番号は、HTMLの中に忍ばせて明記するようにして、それをGitのタグと同じにすることで、関連を見極められるようにしましょう。
誰が本番化するのかを決める
これから説明するリリース作業、つまり本番化を、複数人でやることは避けます。
毎回決まった人がやる必要はないですが、指名制にして担当者は決めましょう。
リリースの修正に関しても、後述しますが、出来れば「バトンタッチ」でやるほうが無難です。
リリースブランチ概要
デベロップブランチは、フィーチャーブランチを作り回帰させる、シンプルな構造でしたが、リリースブランチは、様相が変わります。
リリースブランチは、デベロップブランチから派生させ、作業したあとは、デベロップブランチにも、メインブランチにも、同時にマージ。つまり、2回マージされます。
図にすると以下の通りです。
通常手順
1. フェッチ→プルを実行してから、作業を始める
必ず、develop ブランチ、main ブランチが最新であるかどうか？を確認しましょう
2. リリースブランチを開始
デベロップブランチからリリースブランチが作られます。リリースブランチの名前をどうするか？即ち、バージョンをどうするか？と聞かれるので、バージョンを打ち込みます。
例として 1.10.2 というバージョンがあったとします。これは、セマンティック・バージョンニングと呼ばれる、バージョン表記の方法の一つです。
それぞれ左から
- メジャーバーション（1.10.2）
- マイナーバーション（1.10.2）
- パッチバーション（1.10.2）
と呼ばれます。
メジャーバージョンは、任意の大きな節目でカウントアップさせます。Web制作では、「見た目も含めて、グロナビの構成が変わる」というのを目安にすると良いかもしれません。
マイナーバージョンは、Git Flowのリリース、パッチバージョンは、Git Flowのホットフィックスの度にカウントアップされ、左側の数字がカウントアップしたら、右側の数字は、0にリセットします。
例：「1.10.2 -> リリース -> 1.11.0 -> ホットフィックス -> 1.11.1」
3. コード内の表記を変更
HTMLやpackage.jsonのバージョンを変更します。
package.json のバージョン番号を、他のソースコードに伝播させるスクリプトを書いて、ビルドを回すようにしておくと便利だし間違いが無いです
4. 最終確認
依頼主をまじえての最終確認をします。 QAと呼ばれる作業です。
5. リリースブランチを終了
終了後は、develop と main、両方をプッシュする必要があるので、忘れないようにしましょう。また、終了時にバージョンが書かれたタグが自動で作られますので、これもプッシュするのを忘れないようにしましょう。
6. 公開作業
更新されたメインブランチの内容をサーバーにアップロードします。
つまり、公開サーバーにはメインブランチの内容のみが反映されるようします。
リリースの修正を複数人で
リリースの段階で、お客さんに最終確認をしてもらったところ、大量の修正が発生した。
ということが、あるかと思います。
その場合、デベロップブランチが進んでいなければ、リリースブランチを破棄するだけですが、そうでもなくて、一人ではやりきれない量であれば、リリースブランチからブランチを派生させて作業すことになります。
しかし、このブランチについて、Git Flowでは決まりが定義されていませんので、フィーチャーブランチの運用に習って、やってみてください。
大きな修正は、次のリリースに回すことも検討しましょう。
また、リリース段階にそのような修正が流れ込んでこない努力をすることが大切です。
「完成品」を見ながら作っていくという方法は、真のアジャイル開発とも違います。コストにもクオリティにもリスクのある行為です。プロジェクトマネージメントの課題とするようにしましょう。