こんにちは。 GROOVE X のふるまいチームのscnshです。 この記事では、ソフトウェアリリースのためのふるまい試験で見つかった不具合の修正（HOTFIX）のために採用している、ちょっとした自動化のしくみについて話します。
HOTFIXにかかる手間
ふるまいチームでは「NeoDM」という意思決定と動作生成を行うソフトウェアを開発しており、そのコードをgithub上で管理しています。 開発モデルは Scaled trunk-based development を採用していて、developブランチを使わずにmasterブランチを常に最新に保つような形で開発を続けてきました。
ふるまいの試験は、releaseブランチを作成した後に実施していますが、試験実施中に発生した不具合はHOTFIXという形で masterとrelease の両ブランチにマージされます。 具体的には以下の手順で作業しますが、ほぼ同じ作業をそれぞれ行う必要があり、無駄に感じていました。
- masterブランチに対して修正し、PullRequest(PR)を通じてmergeする
- 同様の内容をPRにしてreleaseブランチに対してmergeする
さらに、リリーススケジュールの中で締切が迫っていたり、他のチームの作業をブロックすることなどもあり、担当者は焦りやすくミスをしやすい状況でもありました。
Github Actions を使った auto-hotfix
そこで、Github Actions を使った 仕組みを導入して活用しています。
基本的な流れは、以下となります。
Label機能を使って、対応したソフトウェアバージョンのラベルをHOTFIX対象となるPRに割り当てる
1.17 バージョンに対して、 `needs-hotfix/1.17` のラベルを設定する - HOTFIX対象となるPRをmasterブランチにマージする
- [自動化] masterブランチに追加したコミットを
release/1.17ブランチに適用するPRを作成する
自動生成されたPR - 生成されたPRをレビューしてHotfixを
release/1.17ブランチにマージする
また、自動生成されたPRのdescriptionに以下の情報が自動で含まれることで、レビューワーが背景を理解しやすくなりコミュニケーションミスを減らすことにも役立っています。
- 生成元のPRのリンク
- 誰がマージしたか
- コミットhash
さらに、PRのレビューワーも自動でアサインされるようになっています。 自動アサイン先はチーム内のロール（リリース担当者）に紐付いて設定されます。 このレビューワーアサインに関しては社内の独自ルールに基づいているため管理が煩雑になるデメリットはありますが、レビューの催促がタイムリーにできるメリットを活用しています。
実装と問題点
この仕組みの実装ですが、
という形で実装しています。
また、お気づきの方もいると思いますが、以下の状況では動作しないためやむを得ず手動作業になっています。
- コンフリクトの解消
- 複数のPRに対しての実行
上記の問題はありますが、実際に運用してみると自動で作成できる機会もあるので重宝しています。
ちなみに...
検索すれば、 3rdParty製のものもあります。 が、我々の開発では独自のPRレビューシステムを導入している影響で自分たちで実装しています。 できれば作らずに導入したほうがメンテナンスコストはかからなくて良さそう。。。
最後に
ご覧いただきありがとうございました！ GROOVE X では 一緒にLOVOTの開発をするメンバーを募集しています。 ふるまいを開発してはいますが、今回紹介したような開発を効率化するような活動も行っています。 興味のある方はぜひこちらからご連絡ください！
