기능 분류

각 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 파일을 유지하고 있습니다. 이 파일이 오래된 경우 자동으로 Slack에 알림을 받게 됩니다.

Gemfile

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

Tooling 기능 범주

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

Test platform 기능 범주

주로 테스트 플랫폼 서브 부서에서 유지보수되는 젬을 위해 feature_category: :test_platform을 사용합니다. 예를 들어 capybara는 UI를 포함하는 테스트를 실행하기 위해 Gemfile 및 qa/Gemfile에 모두 정의되어 있습니다. 이는 특정 제품 그룹에 속하지 않습니다.

공유 기능 범주

다양한 제품 그룹에서 사용되는 젬에 대해 feature_category: :shared를 사용합니다. 예를 들어 rails는 전체 응용 프로그램에서 사용되며 여러 그룹과 공유되었습니다.

Sidekiq workers

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

class SomeScheduledTaskWorker
  include ApplicationWorker

  # 이 워커가 `continuous_integration` 기능 범주의 일부임을 선언합니다
  feature_category :continuous_integration

  # ...
end

feature_category를 사용하여 지정된 기능 범주는 무조건 config/feature_categories.yml에 정의되어 있어야 합니다. 그렇지 않으면 명세가 실패합니다.

Sidekiq workers를 기능 범주화에서 제외

몇몇 모든 기능에 걸쳐 사용되는 Sidekiq workers는 단일 범주로 매핑할 수 없습니다. 이런 경우 다음과 같이 feature_category :not_owned 선언을 사용하여 명시해야 합니다. 

class SomeCrossCuttingConcernWorker
  include ApplicationWorker

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

  # ...
end

가능한 경우 “소유되지 않은”로 표시된 워커는 메트릭 및 로그에서 호출자의 범주(워커 또는 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 클래스 메서드를 사용하여 수행됩니다.

전체 컨트롤러에 대해 기능 범주를 명시하려면 다음과 같이 사용합니다. ruby class Boards::ListsController < ApplicationController feature_category :kanban_boards end

두 번째 인수를 사용하여 기능 범주를 작업 목록에 제한할 수 있습니다. ruby class DashboardController < ApplicationController feature_category :team_planning, [:issues, :issues_calendar] feature_category :code_review_workflow, [:merge_requests] end

이러한 형식을 섞을 수 없습니다: 컨트롤러에 둘 이상의 범주가 있는 경우 모든 작업이 나열되어야 합니다.

기능 범주에서 컨트롤러 작업 제외

거의 사용되지 않는 경우 작업은 not_owned 기능 범주를 사용하여 명시할 수 있습니다. ruby 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 규칙을 통해 위반사항을 플래그 처리합니다.

도구 기능 카테고리

엔지니어링 생산성 내부 도구에서는 feature_category: :tooling을 사용합니다.

예를 들어, spec/tooling/danger/specs_spec.rb에 사용됩니다.

공유 기능 카테고리

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

관리자 섹션

새로운 관리자 섹션을 추가할 때도 기능 카테고리를 추가하는 것이 중요합니다. 과거에는 관리자 섹션은 코드에서 종종 not_owned로 표시되었습니다. 이제 새로운 관리자 섹션에 대한 각 추가가 feature_category 표기법을 사용하여 적절하게 주석 처리되었는지 확인해야 합니다.