기능 분류

각 Sidekiq worker, Batched Background migrations, controller action, 테스트 예제 또는 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을 가져와 구문 분석하여 파일의 새 버전을 생성하며, 이를 저장소에 커밋해야 합니다.

확장성 팀이 현재 feature_categories.yml 파일을 유지합니다. 파일이 오래된 경우에는 자동으로 슬랙으로 알림을 받습니다.

Gemfile

각 루비 젬 종속성에 대해 어떤 기능 범주가 이 종속성을 요구하는지 지정해야 합니다. 이로써 소유권을 명확하게 하고 해당 기능을 소유한 그룹에 업그레이드를 위임할 수 있습니다.

도구 기능 범주

Engineering Productivity 내부 도구에는 feature_category: :tooling을 사용합니다. 예를 들어, knapsack과 crystalball은 모두 CI에서 RSpec 테스트 스위트를 실행하는 데 사용되며 어떤 제품 그룹에도 속하지 않습니다.

공유 기능 범주

여러 제품 그룹에서 사용되는 젬의 경우 feature_category: :shared를 사용합니다. 예를 들어, rails는 응용 프로그램 전체에서 사용되며 여러 그룹과 공유됩니다.

Sidekiq worker

아래와 같이 feature_category 클래스 메소드를 사용하여 선언합니다. 

class SomeScheduledTaskWorker
  include ApplicationWorker

  # 이 worker가 `continuous_integration` 기능 범주의 일부임을 선언함
  feature_category :continuous_integration

  # ...
end

feature_category를 사용하여 지정된 기능 범주는 config/feature_categories.yml에 정의되어야 합니다. 그렇지 않으면 스펙이 실패합니다.

Sidekiq worker의 기능 범주 제외

하나의 기능에 대한 몇 가지 Sidekiq worker는 단일 범주로 매핑될 수 없는 특정한 경우가 있습니다. 이러한 경우에는 다음과 같이 feature_category :not_owned 선언을 사용하여 해당 worker를 선언해야 합니다. 

class SomeCrossCuttingConcernWorker
  include ApplicationWorker

  # 이 worker가 기능 범주에 매핑되지 않음을 선언합니다.
  feature_category :not_owned # rubocop:disable Gitlab/AvoidFeatureCategoryNotOwned

  # ...
end

가능하다면 “소유하지 않음”으로 표시된 worker는 메트릭 및 로그에서 호출자의 범주(Worker 또는 HTTP 엔드포인트)를 사용합니다. 예를 들어, ReactiveCachingWorker는 메트릭 및 로그에서 여러 기능 범주를 가질 수 있습니다.

Batched background migrations

시간 제한 가이드라인에 따른 긴 실행 마이그레이션은 batched background migrations으로 추출됩니다. 이러한 마이그레이션은 다음과 같이 feature_category를 정의해야 합니다. 

# 파일명: lib/gitlab/background_migration/my_background_migration_job.rb

class MyBackgroundMigrationJob < BatchedMigrationJob
  feature_category :gitaly

  #...
end

참고: RuboCop::Cop::BackgroundMigration::FeatureCategory는 유효한 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는 정의된 모든 경로를 반복하여 모든 액션에 카테고리가 할당되었는지 확인합니다.

이 스펙은 사용된 기능 카테고리가 알려진지도 확인합니다. 또한 구성에서 사용된 액션이 여전히 경로로 존재하는지도 유효성을 검사합니다.

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 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 feature category

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

예를 들어 spec/tooling/danger/specs_spec.rb에서 사용하고 있습니다.

공유 기능 카테고리

개발자를 지원하고 제품 그룹에 특정하지 않은 기능에는 feature_category: :shared를 사용합니다. 예를 들어 spec/lib/gitlab/job_waiter_spec.rb입니다.

관리자 섹션

새로운 부분을 관리자 섹션에 추가할 때 기능 카테고리를 추가하는 것이 매우 중요합니다. 과거에는 관리자 섹션을 코드에서 종종 not_owned로 표시했습니다. 이제는 관리자 섹션에 새로운 추가사항마다 feature_category 표기를 사용하여 적절하게 표시되도록 해야 합니다.