기능 분류
각 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 파일은 Skalability 팀이 유지 관리하고 있습니다. 파일이 오래되면 Slack을 통해 자동으로 알림을 받게 됩니다.
Gemfile
각 Ruby gem 의존성에 대해 이 의존성을 필요로 하는 기능 범주를 지정해야 합니다. 이는 소유권을 명확히 하고 해당 기능을 소유하는 그룹에 업그레이드를 위임할 수 있게 합니다.
도구 기능 범주
Engineering Productivity 내부 도구의 경우 feature_category: :tooling을 사용합니다. 예를 들어, knapsack 및 crystalball은 모두 CI에서 RSpec 테스트 스위트를 실행하는 데 사용되며, 특정 제품 그룹에 속하지 않습니다.
테스트 플랫폼 기능 범주
Test Platform 하위 부서에 의해 주로 유지되는 gem의 경우 feature_category: :test_platform을 사용합니다. 예를 들어, UI 관련 테스트를 실행하기 위해 capybara가 Gemfile과 qa/Gemfile 모두에 정의되어 있습니다. 이들은 특정 제품 그룹에 속하지 않습니다.
공유 기능 범주
다양한 제품 그룹에서 사용되는 gem에 대해 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 cop는 유효한 feature_category가 정의되었는지 확인합니다.
Rails 컨트롤러
컨트롤러 액션에 feature category를 지정하는 것은 feature_category 클래스 메서드를 사용하여 수행할 수 있습니다.
전체 컨트롤러에 대해 feature category를 지정할 수 있습니다:
class Boards::ListsController < ApplicationController
feature_category :kanban_boards
end
feature category는 두 번째 인수를 사용하여 액션 목록으로 제한할 수 있습니다:
class DashboardController < ApplicationController
feature_category :team_planning, [:issues, :issues_calendar]
feature_category :code_review_workflow, [:merge_requests]
end
이 양식은 혼합될 수 없습니다: 컨트롤러에 여러 개의 카테고리가 있는 경우 모든 액션을 나열해야 합니다.
컨트롤러 액션의 feature 카테고리에서 제외하기
드물게 액션을 feature category에 연결할 수 없는 경우 not_owned feature category를 사용하여 수행할 수 있습니다.
class Admin::LogsController < ApplicationController
feature_category :not_owned
end
feature categories의 유효성 확인
spec/controllers/every_controller_spec.rb는 모든 정의된 경로를 반복하고
컨트롤러를 확인하여 모든 액션에 카테고리가 할당되어 있는지 확인합니다.
이 스펙은 또한 사용된 feature categories가 알려진 것인지 검증합니다.
그리고 설정에서 사용된 액션이 여전히 경로로 존재하는지 검증합니다.
API 엔드포인트
현재 GraphQL API는 not_owned로 분류됩니다.
현재로서는 추가 사양이 필요하지 않습니다. 추가 정보는
gitlab-com/gl-infra/scalability#583를 참조하십시오.
Grape API 엔드포인트는 feature_category 클래스 메서드를 사용할 수 있으며,
Rails 컨트롤러와 같은 방식으로 사용됩니다:
module API
class Issues < ::API::Base
feature_category :team_planning
end
end
두 번째 인수는 특정 경로에 대한 feature categories를 지정하는 데 사용할 수 있습니다:
module API
class Users < ::API::Base
feature_category :user_profile, ['/users/:id/custom_attributes', '/users/:id/custom_attributes/:key']
end
end
또는 액션 자체에서 feature category를 지정할 수 있습니다:
module API
class Users < ::API::Base
get ':id', feature_category: :user_profile do
end
end
end
Rails 컨트롤러와 마찬가지로, API 클래스는 해당 클래스 내의 모든 액션에 대해
각각 카테고리를 지정해야 합니다.
RSpec 예제
각 RSpec 예제에 대해 feature category 메타데이터를 설정해야 합니다.
이 정보는 flaky 테스트 문제를 해결하기 위해 기능이 소속된 그룹을 식별하는 데 사용됩니다.
feature_category는 config/feature_categories.yml에서
값을 가져와야 합니다.
feature_category 메타데이터는 다음과 같이 설정할 수 있습니다:
동일한 파일에서 여러 가지 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 표기법을 사용하여 적절하게 주석을 달도록 해야 합니다.
도움말