次世代EC開発プロジェクトの新管理画面開発 - リリース対応漏れを防ぐ仕組み

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

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

開発・導入の背景

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

if (IsDevelopment) {
   // 新機能
}

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

- if (IsDevelopment) {
    // 新機能
- }

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

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

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

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

// RELEASE_FLAG:ログイン機能
if (IsDevelopment) {
   // ログイン機能
}

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

- flagName: ログイン機能
  releaseDate: 2024-09-22

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

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

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

- flagName: ログイン機能
  releaseDate:

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

yamlファイルからフラグ名とリリース日を削除します
```
 - - flagName: ログイン機能
 -    releaseDate: 2024-09-22
```

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

 - // RELEASE_FLAG:ログイン機能
 - if (IsDevelopment) {
    // ログイン機能
 - }

コメントの消し忘れがあった場合は、yamlファイルに存在しないフラグ名のコメントととして、検出されます
yamlファイルに存在しないフラグ名のコメントととして検出された例
また、リリース対応を忘れてしまった場合は、リリース日を過ぎているコメントととして、検出されます
リリース日を過ぎているコメントとして検出された例