こんにちは、サーバーエンジニアをしている新卒入社2年目のJです。

初めての投稿なのでテーマについていろいろと迷っていたのですが、最近のある出来事で記事としてまとめておきたいものができたので、他の困っている新卒の皆様のため7割、自分のため3割の気持ちで述べていきたいと思います。

皆さんが新卒のとき特にハードルの高かったタスクは何ですか。

私の場合はhotfixです(.^.)

通常のリリースフローを理解するだけで精一杯だった私にとってhotfixはイレギュラーな応用問題みたいなものでした。

が、2回ほどの経験でやっと全体像が描けるようになった（と思います）ので、この場を借りてまとめていきたいと思います。

リリースのフロー

まずは普段のリリースフローについてざっくり紹介します。

組織によって異なるとは思いますが、私の所属チームでは、masterブランチとstableブランチを使って運用しています。

（masterブランチは一つですが、stableブランチはバージョンごとに新しく作成します。）

フロー概要

1. 開発プロセス:
• masterブランチは開発ブランチとして使用しています。
• 各開発者はmasterブランチからローカルブランチを切って実装を行います。
• 実装が完了し、コードレビューが通ったら、ローカルブランチをmasterブランチにマージします。
2. QAと安定化:
• 定期的に、ある時点のmasterブランチを基にQAを行います。
• QA中に発見されたバグや問題を修正し、安定した状態にします。
3. リリースプロセス:
• 安定したmasterブランチからstableブランチを切ります。
• stableブランチの最新コミットにタグを付けます。
• このタグ付きのコミットを正式にリリースします。
4. 1から3を繰り返す

例えば、「TODOリスト」というアプリをリリースする場合、以下のようになります。

バージョン1.0.0では基本的なTODOリスト機能を提供し、バージョン1.1.0では締め切り機能を追加しています。

hotfixのフロー

次に不具合が発生した場合の例を挙げたいと思います。

例えば、バージョン1.1.0のQA進行中の時点である文言が「DODO」となっていることに気づいたとしましょう。

その場合、QA中の最新のmasterブランチもstable1.0.0ブランチもその文言は「DODO」になっています。

とりあえず世の中に出ているアプリの文言を1.1.0のリリースを待たずに「TODO」に直したい心情だとします。

そのときはstable1.0.0ブランチからブランチを切ってhotfix修正を行います。

現在のmasterブランチにはQA中の締め切り機能が含まれているため、ここからブランチを切って修正作業を行うと、hotfixに新機能が混ざってしまう恐れがありますので注意が必要です。

修正後は検証を行い、stable1.0.0ブランチにマージします。

すると、最新のstable1.0.0ブランチでは文言がTODOに修正された状態になります。

この最新コミットに改めてタグ（v1.0.1）を付けてリリースします。

これで急場はしのげました。

しかし、masterブランチはまだ不具合が解消されていないままです。

このままバージョン1.1.0をリリースすると、文言の不具合が再び発生してしまうため、masterブランチにもhotfix修正を反映する必要があります。

そのときはcherry-pickを活用するの方法も一つの手段となります。

stable1.0.0ブランチの最新のコミットを現在のmasterブランチにcherry-pickすることで、修正内容のみをmasterブランチに取り込むことができます。

これにより、masterブランチの文言も「TODO」に修正されます。

おわりに

いかがでしたか。

この記事が少しでも参考になれば嬉しいです。。。

自分は手書きでグラフを頑張って描いたおかげで、概念がより明瞭になった気がします(.^.)

ここまで読んでいただき、ありがとうございました。