特徴の分類

GitLab 13.2 で導入されました。

各 Sidekiq ワーカー、Batched Background マイグレーション、コントローラーアクション、テストサンプル、API エンドポイントは、feature_category 属性を宣言する必要があります。この属性は、それぞれを機能カテゴリにマッピングします。これは、エラー予算、アラートルーティング、チーム帰属のために行われます。

機能カテゴリのリストは、ファイルconfig/feature_categories.yml にあります。このファイルは、GitLabハンドブックや他のGitLabリソースで使われているstages.yml データファイルから生成されています。

更新config/feature_categories.yml

GitLabのステージやグループ、製品カテゴリーに新しい機能が追加されることがあります。このような場合は、scripts/update-feature-categories を実行することでconfig/feature_categories.yml を自動的に更新することができます。このスクリプトはstages.yml を取得・解析して新しいバージョンのファイルを生成し、リポジトリにコミットする必要があります。

現在、Scalability チームが feature_categories.yml ファイルをメンテナーしています。ファイルが古くなると、Slackで自動的に通知されます。

Sidekiqワーカー

この宣言では、feature_category クラスメソッドを使用しています。

class SomeScheduledTaskWorker
  include ApplicationWorker

  # Declares that this worker is part of the
  # `continuous_integration` feature category
  feature_category :continuous_integration

  # ...
end

feature_category を使用して指定された機能カテゴリは、config/feature_categories.yml で定義されている必要があります。

Sidekiqワーカーをフィーチャーカテゴライズから除外する方法

すべてのフィーチャーで使用されるいくつかのSidekiqワーカーは、1つのカテゴリーにマッピングできません。これらは、feature_category :not_owned 宣言を使って、以下のように宣言してください：

class SomeCrossCuttingConcernWorker
  include ApplicationWorker

  # Declares that this worker does not map to a feature category
  feature_category :not_owned # rubocop:disable Gitlab/AvoidFeatureCategoryNotOwned

  # ...
end

可能であれば、”not owned” とマークされたワーカーは、メトリクスとログで呼び出し元のカテゴリ（ワーカーまたはHTTPエンドポイント）を使用します。例えば、ReactiveCachingWorker はメトリクスとログで複数の機能カテゴリを持つことができます。

バックグラウンドでの一括マイグレーション

(時間制限のガイドラインに従って)長時間実行されるマイグレーションはバッチバックグラウンドマイグレーションとして引き出されます。feature_categoryを定義する必要があります：

# File name: lib/gitlab/background_migration/my_background_migration_job.rb

class MyBackgroundMigrationJob < BatchedMigrationJob
  feature_category :gitaly

  #...
end
note
RuboCop::Cop::BackgroundMigration::FeatureCategorycop は有効なfeature_category が定義されていることを保証します。

Railsコントローラ

コントローラのアクションで機能カテゴリを指定するには、feature_category クラスメソッドを使用します。

機能カテゴリは、コントローラ全体で指定することができます：

class Boards::ListsController < ApplicationController
  feature_category :kanban_boards
end

機能カテゴリは、第2引数を使用してアクションのリストに制限できます：

class DashboardController < ApplicationController
  feature_category :team_planning, [:issues, :issues_calendar]
  feature_category :code_review_workflow, [:merge_requests]
end

コントローラが複数のカテゴリを持つ場合、すべてのアクションをリストする必要があります。

コントローラのアクションをフィーチャーカテゴライズから除外する方法

アクションをフィーチャカテゴリに結び付けられない場合は、not_owned フィーチャカテゴリを使用します。

class Admin::LogsController < ApplicationController
  feature_category :not_owned
end

機能カテゴリが有効であることの確認

spec/controllers/every_controller_spec.rb は、定義されたすべてのルートを繰り返し、コントローラをチェックして、すべてのアクションにカテゴリが割り当てられているかどうかを確認します。

この仕様では、使用される機能カテゴリが既知かどうかも検証します。また、設定に使用されたアクションがルートとして存在するかどうかも検証します。

APIエンドポイント

GraphQL APIは現在、not_owned に分類されています。今のところ、特別な指定は必要ありません。詳細については、gitlab-com/gl-infra/scalability#583 を参照してください。

Grape API エンドポイントは、Rails コントローラのようにfeature_category クラスメソッドを使用できます：

module API
  class Issues < ::API::Base
    feature_category :team_planning
  end
end

2番目の引数は、特定のルートにフィーチャーカテゴリを指定するために使うことができます：

module API
  class Users < ::API::Base
    feature_category :user_profile, ['/users/:id/custom_attributes', '/users/:id/custom_attributes/:key']
  end
end

あるいは、アクション自体に特徴カテゴリを指定することもできます：

module API
  class Users < ::API::Base
    get ':id', feature_category: :user_profile do
    end
  end
end

Railsコントローラと同様、APIクラスは、そのクラス内のすべてのアクションで同じカテゴリが使われない限り、アクションごとにカテゴリを指定する必要があります。

RSpecの例

各 RSpec サンプルにフィーチャー・カテゴリーのメタデータを設定する必要があります。こ の情報は、 フ レーキ テ ス ト イシューで、 その機能を所有す る グルー プを識別する ために使用 さ れます。

feature_category にはconfig/feature_categories.yml の値を指定します。

feature_category のメタデータを設定できます：

同じファイルに複数のフィーチャカテゴリがある場合は、ファイルの分割を検討してください。

使用例：

RSpec.describe Admin::Geo::SettingsController, :geo, feature_category: :geo_replication do

feature_category が設定されていない例については、ローカル環境で実行する際に警告を追加します。

この警告を無効にするには、RSpec テストを実行する際にRSPEC_WARN_MISSING_FEATURE_CATEGORY=false を使用してください：

RSPEC_WARN_MISSING_FEATURE_CATEGORY=false bin/rspec spec/<test_file>

さらに、RSpec/MissingFeatureCategory RuboCop ルールによって違反にフラグを立てます。

ツール機能カテゴリ

エンジニアリング生産性内部ツールには、feature_category: :tooling を使用しています。

例えばspec/tooling/danger/specs_spec.rb。

共有機能カテゴリ

開発者をサポートする機能で、製品グループに固有でないものにはfeature_category: :shared を使用します。spec/lib/gitlab/job_waiter_spec.rb

管理セクション

機能カテゴリを追加することは、Admin セクションに新しいパーツを追加するときにも同様に重要です。歴史的に、Adminセクションはしばしばコード内でnot_owned 。現在では、Admin セクションに新しく追加される各パーツがfeature_category 記法で適切に注釈されていることを確認する必要があります。