각 Sidekiq 워커, Batched Background 마이그레이션, 컨트롤러 액션, 테스트 예제, API 엔드포인트는 feature_category 속성을 선언해야 합니다. 이 속성은 각 항목을 기능 카테고리에 매핑합니다. 이는 오류 예산 관리, 알림 라우팅, 팀 귀속을 위해 수행됩니다.

기능 카테고리 목록은 config/feature_categories.yml 파일에서 확인할 수 있습니다. 이 파일은 GitLab 핸드북 및 기타 GitLab 리소스에서 사용되는 stages.yml 데이터 파일로부터 생성됩니다.

config/feature_categories.yml 업데이트#

GitLab Stage, 그룹, 제품 카테고리에 새 기능이 추가되는 경우가 있습니다. 이런 경우 scripts/update-feature-categories를 실행하면 config/feature_categories.yml을 자동으로 업데이트할 수 있습니다. 이 스크립트는 stages.yml을 페치하고 파싱하여 새 버전의 파일을 생성하며, 이 파일은 리포지터리에 커밋해야 합니다.

Observability 팀이 현재 feature_categories.yml 파일을 유지 관리합니다. 파일이 오래되면 Slack을 통해 자동으로 알림이 전송됩니다.

Gemfile#

각 Ruby gem 의존성에 대해 해당 의존성을 필요로 하는 기능 카테고리를 지정해야 합니다. 이를 통해 소유권을 명확히 하고, 해당 기능을 소유한 그룹에 업그레이드를 위임할 수 있습니다.

Tooling 기능 카테고리#

Developer Experience 내부 툴링에는 feature_category: :tooling을 사용합니다. 예를 들어, knapsack과 gitlab-crystalball은 모두 CI에서 RSpec 테스트 스위트를 실행하는 데 사용되며 특정 제품 그룹에 속하지 않습니다.

Test platform 기능 카테고리#

엔드-투-엔드 테스트 인프라와 관련된 gem은 Development Experience 섹션에서 유지 관리합니다. feature_category: :test_platform 라벨을 사용합니다. 예를 들어, capybara는 UI를 포함하는 테스트를 실행하기 위해 Gemfile과 qa/Gemfile 모두에 정의되어 있습니다. 이는 특정 제품 그룹에 속하지 않습니다.

Rails platform 기능 카테고리#

Rails 핵심 프레임워크 gem은 주로 Backend Maintainer가 유지 관리합니다. 예를 들어, rails와 zeitwerk는 :rails_platform으로 정의해야 합니다.

Shared 기능 카테고리#

:shared 기능 카테고리는 gem에 대해 더 이상 지원되지 않습니다.

gem의 적절한 유지 관리를 위한 노력의 일환으로, 모든 gem은 특정 기능 카테고리를 사용해야 합니다. gem의 소유권이 불분명한 경우 #backend_maintainers 채널에서 도움을 요청하세요.

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에 정의되어 있어야 합니다. 그렇지 않으면 spec이 실패합니다.

기능 분류에서 Sidekiq 워커 제외#

모든 기능에 걸쳐 사용되는 일부 Sidekiq 워커는 단일 카테고리에 매핑할 수 없습니다. 이런 워커는 아래와 같이 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는 메트릭과 로그에서 여러 기능 카테고리를 가질 수 있습니다.

Batched background 마이그레이션#

장기 실행 마이그레이션(시간 제한 가이드라인 참고)은 batched background 마이그레이션으로 분리됩니다. 다음과 같이 feature_category를 정의해야 합니다.

# Filename: lib/gitlab/background_migration/my_background_migration_job.rb

class MyBackgroundMigrationJob < BatchedMigrationJob
  feature_category :gitaly

  #...
end

RuboCop::Cop::BackgroundMigration::FeatureCategory cop은 유효한 feature_category가 정의되어 있는지 확인합니다.

Rails 컨트롤러#

컨트롤러 액션에 기능 카테고리를 지정하려면 feature_category 클래스 메서드를 사용합니다.

다음과 같이 전체 컨트롤러에 기능 카테고리를 지정할 수 있습니다.

class Boards::ListsController < ApplicationController
  feature_category :kanban_boards
end

두 번째 인수를 사용하여 기능 카테고리를 특정 액션 목록으로 제한할 수 있습니다.

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는 정의된 모든 라우트를 순회하며 모든 액션에 카테고리가 할당되어 있는지 컨트롤러를 확인합니다.

이 spec은 사용된 기능 카테고리가 알려진 것인지도 검증합니다. 그리고 설정에 사용된 액션이 여전히 라우트로 존재하는지도 확인합니다.

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

두 번째 인수를 사용하여 특정 라우트에 기능 카테고리를 지정할 수 있습니다.

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 블록에서.

• describe 블록에서.

동일한 파일에 여러 기능 카테고리가 있는 경우 파일을 분리하는 것을 고려하세요.

예제:

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/FeatureCategory RuboCop 규칙을 통해 위반 사항을 플래그로 표시합니다.

Tooling 기능 카테고리#

Engineering Productivity 내부 툴링에는 feature_category: :tooling을 사용합니다.

예를 들어 spec/tooling/danger/specs_spec.rb에서 확인할 수 있습니다.

Shared 기능 카테고리#

:shared 기능 카테고리는 테스트에 대해 더 이상 지원되지 않습니다.

플레이키 및 격리된 테스트 자동화 간소화 노력의 일환으로, 모든 spec은 특정 기능 카테고리를 사용해야 합니다. spec의 소유권이 불분명한 경우 #g_test_governance 팀에 도움을 요청하세요. shared 소유권을 가진 기존 테스트 마이그레이션에 대해서는 자세한 내용을 위해 이 이슈를 참고하세요.

Admin 섹션#

Admin 섹션에 새로운 부분을 추가할 때도 기능 카테고리를 추가하는 것이 똑같이 중요합니다. 역사적으로 Admin 섹션은 코드에서 종종 not_owned로 표시되었습니다. 이제 Admin 섹션에 추가되는 모든 새 항목이 feature_category 표기를 사용하여 적절히 주석 처리되어야 합니다.