【エンジニアブログ】リリース対応漏れを防ぐ仕組み

こんにちは、GMOメイクショップの黒木です。

現在弊社では次世代EC開発プロジェクトが進行しており、私は新管理画面の開発を担当しています。その開発の過程で、リリース対応漏れを防ぐ対策として、Linterを開発・導入しました。この記事では、開発・導入の背景、概要と使用例についてご紹介します。

• 開発・導入の背景
• 概要
• 使用例
• まとめ

開発・導入の背景

新管理画面の開発では、フィーチャーフラグを使って新機能の公開を制御しています。外部のフィーチャーフラグ製品は使用せずに、特定の環境下でtrueを返すフラグを使用しています。

新機能を公開する際は、フィーチャーフラグの条件分岐を削除することでリリースを行います。条件分岐を削除するだけなので、リリース対応は非常に容易です。

このようにフィーチャーフラグを導入することでメリットがありましたが、課題もありました。開発からリリースまでの期間が長くなると、どこにフィーチャーフラグを仕込んだかを忘れてしまう、消し忘れてしまうという課題です。

これをレビューで指摘できれば良いのですが、人の力ではどうしても漏れが発生するため、自動で検出する仕組みとしてLinterの開発・導入を行いました。

概要

今回開発したLinterは、コード内のコメントと、リリース日が記入されたyamlファイルをもとに、対応漏れを検出します。

コード内のコメントにはRELEASE_FLAG:に続けて、フラグ名を記入します。このコメントはフィーチャーフラグの近くに記入します。

yamlファイルにはフラグ名とリリース日を記入します。

Linterはフラグ名をもとに、コメントとリリース日を紐付けます。 リリース日を過ぎてもコメントが残っている場合は、Lintエラーになります。

上記の例だと、2024年9月22日を過ぎてもコード内にコメントが残っていたら、Lintエラーになります。

弊社の場合、開発時点ではリリース日が決まっていないことが多いため、リリース日は未設定でも登録できるようにしています。リリース日が確定したらyamlファイルに追記するようにしています。

使用例

このLinterを活用して以下の手順でリリース対応を行うことで、対応漏れを防いでいます。

1. yamlファイルからフラグ名とリリース日を削除します

2.フィーチャーフラグと一緒にコメントを削除します

3.コメントの消し忘れがあった場合は、yamlファイルに存在しないフラグ名のコメントととして、検出されます

4.また、リリース対応を忘れてしまった場合は、リリース日を過ぎているコメントととして、検出されます

まとめ

弊社では、このようにしてリリース対応漏れを防いでいます。

このLinterを導入して1ヶ月弱ですが、すでに多くのメンバーに使用していただき、以前よりも対応漏れを防げている実感がします。

今後はさらにLinterの改善を続け、さらなる漏れ防止に努めていきたいと思います。

◆　他のBlogはこちらから⇒ https://tech.makeshop.co.jp/◆　

最後までお読みいただきましてありがとうございました。ご応募お待ちしております！