기능 카테고리화
- GitLab 13.2에서 소개되었습니다.
각 Sidekiq 워커, 일괄 배경 마이그레이션, 컨트롤러 액션, 테스트 예제 또는 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 의존성에 대해 해당 기능 카테고리를 명시해야 합니다. 이렇게 함으로써 소유권이 명확해지고 해당 기능을 소유한 그룹에 업그레이드를 위임할 수 있습니다.
도구 기능 카테고리
Engineering Productivity 내부 도구에는 feature_category: :tooling을 사용합니다. 예를 들어 knapsack과 crystalball은 CI에서 RSpec 테스트 스위트를 실행하는 데 사용되며 어떠한 제품 그룹에도 속하지 않습니다.
공유 기능 카테고리
여러 제품 그룹에서 사용되는 젬에는 feature_category: :shared를 사용합니다. 예를 들어 rails는 응용 프로그램 전반에서 사용되며 여러 그룹과 공유됩니다.
Sidekiq 워커
아래와 같이 feature_category 클래스 메소드를 사용하여 선언합니다.
class SomeScheduledTaskWorker
include ApplicationWorker
# 이 워커가 `continuous_integration` 기능 카테고리의 일부임을 선언합니다
feature_category :continuous_integration
# ...
end
feature_category를 사용하여 지정한 기능 카테고리는 반드시 config/feature_categories.yml에 정의되어 있어야 합니다. 그렇지 않으면 스펙이 실패합니다.
기능 카테고리에서 Sidekiq 워커 제외
몇몇 모든 기능에서 사용되는 Sidekiq 워커는 특정 카테고리에 매핑되지 않을 수 있습니다. 이 경우 아래와 같이 feature_category :not_owned 선언을 사용하여 명시해야 합니다.
class SomeCrossCuttingConcernWorker
include ApplicationWorker
# 이 워커가 기능 카테고리에 매핑되지 않음을 선언합니다
feature_category :not_owned # rubocop:disable Gitlab/AvoidFeatureCategoryNotOwned
# ...
end
가능하다면 “소유하지 않은”으로 표시된 워커는 메트릭 및 로그에서 호출자의 카테고리(워커 또는 HTTP 엔드포인트)를 사용합니다. 예를 들어 ReactiveCachingWorker는 메트릭 및 로그에서 여러 기능 카테고리를 가질 수 있습니다.
일괄 배경 마이그레이션
시간 제한 지침에 따라 장기 실행 마이그레이션은 일괄 배경 마이그레이션으로 분리됩니다. 이러한 마이그레이션에는 다음과 같이 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 예시에 대해 특성 범주(metadata)를 설정해야 합니다. 이 정보는 불안정한 테스트 문제를 식별하기 위해 사용되며 해당 기능을 소유한 그룹을 식별하는 데 사용됩니다.
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 규칙을 통해 위반 사항을 플래그 처리합니다.
도구 특성 범주
Engineering Productivity 내부 도구에 대해서는 feature_category: :tooling을 사용합니다.
예를 들면 spec/tooling/danger/specs_spec.rb에서 확인할 수 있습니다.
공유 특성 범주
개발자를 지원하는 기능이며 특정 제품 그룹에 속하지 않는 기능에 대해서는 feature_category: :shared를 사용합니다.
예를 들면 spec/lib/gitlab/job_waiter_spec.rb에서 확인할 수 있습니다.
관리자 섹션
새로운 관리자 섹션 부분을 추가할 때 feature_category 주석을 사용하여 올바르게 주석을 다는 것이 매우 중요합니다. 역사적으로, 관리자 섹션은 코드에서 종종 not_owned로 표시되었습니다. 이제는 관리자 섹션에 새로운 추가 사항을 할 때마다 feature_category 표기를 사용하여 올바르게 어노테이트해야 합니다.
도움말