root
/
gitlab-ce
mirror of https://gitlab.com/free-releases/gitlab-ce.git
1
0
Fork 0
Code Issues Actions Packages Projects Releases Wiki Activity

Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2025-06-06 03:07:50 +00:00
parent 8315cdd9e1
commit df2aa631de
554 changed files with 3620 additions and 2519 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
GITLAB_KAS_VERSION
View File

@ -1 +1 @@
3f4f571017c2c86de35d1d7c4c1a7dded9a42e82
1ae70272d95c4c8128d8e8eb7c3dd0569f9980e4

3
argo_translation.yml
View File

@ -10,3 +10,6 @@ components:
target: 'doc-locale/{{language}}/'
ignored_paths:
- 'doc/.*/**'
- 'doc/architecture/**'
- 'doc/drawers/**'
- 'doc/development/**'

2
db/docs/batched_background_migrations/backfill_bulk_import_export_uploads_group_id.yml
View File

@ -5,4 +5,4 @@ feature_category: importers
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/175723
milestone: '17.8'
queued_migration_version: 20241213150054
finalized_by: # version of the migration that finalized this BBM
finalized_by: 20250529030137

2
db/docs/batched_background_migrations/backfill_bulk_import_export_uploads_project_id.yml
View File

@ -5,4 +5,4 @@ feature_category: importers
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/175723
milestone: '17.8'
queued_migration_version: 20241213150049
finalized_by: # version of the migration that finalized this BBM
finalized_by: 20250529030008

2
db/docs/batched_background_migrations/backfill_design_management_designs_versions_namespace_id.yml
View File

@ -5,4 +5,4 @@ feature_category: design_management
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/180220
milestone: '17.9'
queued_migration_version: 20250204151108
finalized_by: # version of the migration that finalized this BBM
finalized_by: 20250529030200

2
db/docs/batched_background_migrations/backfill_project_relation_export_uploads_project_id.yml
View File

@ -5,4 +5,4 @@ feature_category: importers
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/182116
milestone: '17.10'
queued_migration_version: 20250220130531
finalized_by: # version of the migration that finalized this BBM
finalized_by: 20250529030226

26
db/post_migrate/20250529030008_finalize_backfill_bulk_import_export_uploads_project_id.rb Normal file
View File

@ -0,0 +1,26 @@
# frozen_string_literal: true
class FinalizeBackfillBulkImportExportUploadsProjectId < Gitlab::Database::Migration[2.3]
disable_ddl_transaction!
restrict_gitlab_migration gitlab_schema: :gitlab_main
milestone '18.1'
def up
ensure_batched_background_migration_is_finished(
job_class_name: 'BackfillBulkImportExportUploadsProjectId',
table_name: :bulk_import_export_uploads,
column_name: :id,
job_arguments: [
:project_id,
:bulk_import_exports,
:project_id,
:export_id
],
finalize: true
)
end
def down
# no-op
end
end

26
db/post_migrate/20250529030137_finalize_backfill_bulk_import_export_uploads_group_id.rb Normal file
View File

@ -0,0 +1,26 @@
# frozen_string_literal: true
class FinalizeBackfillBulkImportExportUploadsGroupId < Gitlab::Database::Migration[2.3]
disable_ddl_transaction!
restrict_gitlab_migration gitlab_schema: :gitlab_main
milestone '18.1'
def up
ensure_batched_background_migration_is_finished(
job_class_name: 'BackfillBulkImportExportUploadsGroupId',
table_name: :bulk_import_export_uploads,
column_name: :id,
job_arguments: [
:group_id,
:bulk_import_exports,
:group_id,
:export_id
],
finalize: true
)
end
def down
# no-op
end
end

26
db/post_migrate/20250529030200_finalize_design_management_designs_versions_namespace_id.rb Normal file
View File

@ -0,0 +1,26 @@
# frozen_string_literal: true
class FinalizeDesignManagementDesignsVersionsNamespaceId < Gitlab::Database::Migration[2.3]
disable_ddl_transaction!
restrict_gitlab_migration gitlab_schema: :gitlab_main
milestone '18.1'
def up
ensure_batched_background_migration_is_finished(
job_class_name: 'BackfillDesignManagementDesignsVersionsNamespaceId',
table_name: :design_management_designs_versions,
column_name: :id,
job_arguments: [
:namespace_id,
:design_management_designs,
:namespace_id,
:design_id
],
finalize: true
)
end
def down
# no-op
end
end

26
db/post_migrate/20250529030226_finalize_queue_backfill_project_relation_export_uploads_project_id.rb Normal file
View File

@ -0,0 +1,26 @@
# frozen_string_literal: true
class FinalizeQueueBackfillProjectRelationExportUploadsProjectId < Gitlab::Database::Migration[2.3]
disable_ddl_transaction!
restrict_gitlab_migration gitlab_schema: :gitlab_main
milestone '18.1'
def up
ensure_batched_background_migration_is_finished(
job_class_name: 'BackfillProjectRelationExportUploadsProjectId',
table_name: :project_relation_export_uploads,
column_name: :id,
job_arguments: [
:project_id,
:project_relation_exports,
:project_id,
:project_relation_export_id
],
finalize: true
)
end
def down
# no-op
end
end

1
db/schema_migrations/20250529030008 Normal file
View File

@ -0,0 +1 @@
2f23ab0a1cd16bbe3d2aacc9e4d0914381110389f0156a3057d249c2dd6beff4

1
db/schema_migrations/20250529030137 Normal file
View File

@ -0,0 +1 @@
c608596bb4a32a0405427db248ac740561a3e34e5ae91b9f947ba9242340f9b4

1
db/schema_migrations/20250529030200 Normal file
View File

@ -0,0 +1 @@
6d9d95480c3f4c461473fc10a90524f507a5af0c1e0b77bd730423064e269100

1
db/schema_migrations/20250529030226 Normal file
View File

@ -0,0 +1 @@
8015a31907d1cf8a306599e05b74cbf26b5190a0f46d565d1eb095ab234ec486

7
doc-locale/ja-jp/development/_index.md Normal file
View File

@ -0,0 +1,7 @@
---
stage: none
group: unassigned
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
description: 'Development Guidelines: learn how to contribute to GitLab.'
title: Contribute to development
---

6
doc-locale/ja-jp/development/activitypub/_index.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: Create
group: Source Code
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: ActivityPub
---

6
doc-locale/ja-jp/development/activitypub/actors/_index.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: Create
group: Source Code
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Implement an ActivityPub actor
---

6
doc-locale/ja-jp/development/activitypub/actors/releases.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: Create
group: Source Code
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Activities for following releases actor
---

6
doc-locale/ja-jp/development/adding_service_component.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: none
group: unassigned
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Adding a new Service Component to GitLab
---

6
doc-locale/ja-jp/development/advanced_search.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: Foundations
group: Global Search
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/development/development_processes/#development-guidelines-review.
title: Advanced search development guidelines
---

6
doc-locale/ja-jp/development/advanced_search/tips.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: Foundations
group: Global Search
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Advanced search development tips
---

6
doc-locale/ja-jp/development/ai_architecture.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: AI-powered
group: AI Framework
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: AI Architecture
---

6
doc-locale/ja-jp/development/ai_features/_index.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: AI-powered
group: AI Framework
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: AI features based on 3rd-party integrations
---

6
doc-locale/ja-jp/development/ai_features/actions.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: AI-powered
group: AI Framework
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: AI actions
---

7
doc-locale/ja-jp/development/ai_features/ai_development_license.md Normal file
View File

@ -0,0 +1,7 @@
---
stage: AI-powered
group: AI Framework
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
description: Documentation about GitLab Duo licensing options for local development
title: GitLab Duo licensing for local development
---

6
doc-locale/ja-jp/development/ai_features/ai_feature_development_playbook.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: AI-powered
group: AI Framework
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: AI feature development playbook
---

6
doc-locale/ja-jp/development/ai_features/amazon_q_integration.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: AI-powered
group: Custom Models
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Amazon Q integration for testing and evaluation
---

7
doc-locale/ja-jp/development/ai_features/code_suggestions.md Normal file
View File

@ -0,0 +1,7 @@
---
stage: Create
group: Code Creation
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
description: Code Suggestions documentation for developers interested in contributing features or bugfixes.
title: Code Suggestions development guidelines
---

6
doc-locale/ja-jp/development/ai_features/composite_identity.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: AI-powered
group: AI Framework
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Composite Identity
---

6
doc-locale/ja-jp/development/ai_features/duo_chat.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: AI-powered
group: Duo Chat
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: GitLab Duo Chat
---

6
doc-locale/ja-jp/development/ai_features/embeddings.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: Foundations
group: Global Search
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Embeddings
---

6
doc-locale/ja-jp/development/ai_features/evaluation_runner/_index.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: AI-powered
group: AI Framework
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Evaluation runner
---

6
doc-locale/ja-jp/development/ai_features/glossary.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: AI-powered
group: AI Framework
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: GitLab Duo Glossary
---

6
doc-locale/ja-jp/development/ai_features/local_models.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: AI-powered
group: Custom Models
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Serve Large Language Models APIs Locally
---

6
doc-locale/ja-jp/development/ai_features/logged_events.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: AI-powered
group: AI Framework
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Logged events
---

6
doc-locale/ja-jp/development/ai_features/logging.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: AI-powered
group: AI Framework
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: LLM logging
---

6
doc-locale/ja-jp/development/ai_features/model_migration.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: AI-powered
group: AI Framework
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Model Migration Process
---

6
doc-locale/ja-jp/development/ai_features/testing_and_validation.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: AI-powered
group: AI Framework
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Testing and Validation
---

6
doc-locale/ja-jp/development/ai_features/vertex_model_enablement_process.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: AI-powered
group: AI Framework
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Vertex AI Model Enablement Process
---

6
doc-locale/ja-jp/development/api_graphql_styleguide.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: none
group: unassigned
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Backend GraphQL API guide
---

6
doc-locale/ja-jp/development/api_styleguide.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: none
group: unassigned
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: API style guide
---

6
doc-locale/ja-jp/development/application_limits.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: Systems
group: Distribution
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Application limits development
---

6
doc-locale/ja-jp/development/application_secrets.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: none
group: unassigned
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Application secrets
---

6
doc-locale/ja-jp/development/application_settings.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: none
group: unassigned
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Application settings development
---

6
doc-locale/ja-jp/development/application_slis/_index.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: Platforms
group: Scalability
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: GitLab Application Service Level Indicators (SLIs)
---

6
doc-locale/ja-jp/development/application_slis/rails_request.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: Platforms
group: Scalability
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Rails request SLIs (service level indicators)
---

6
doc-locale/ja-jp/development/application_slis/sidekiq_execution.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: Platforms
group: Scalability
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Sidekiq execution SLIs (service level indicators)
---

1092
doc-locale/ja-jp/development/architecture.md
View File

File diff suppressed because it is too large Load Diff

6
doc-locale/ja-jp/development/audit_event_guide/_index.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: Software Supply Chain Security
group: Compliance
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Audit event development guidelines
---

6
doc-locale/ja-jp/development/auto_devops.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: Deploy
group: Environments
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Auto DevOps development guidelines
---

6
doc-locale/ja-jp/development/avoiding_required_stops.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: Systems
group: Distribution
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Avoiding required stops
---

6
doc-locale/ja-jp/development/backend/create_source_code_be/_index.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: Create
group: Source Code
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Source Code Management
---

6
doc-locale/ja-jp/development/backend/create_source_code_be/gitaly_touch_points.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: Create
group: Source Code
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Source Code - Gitaly Touch Points
---

6
doc-locale/ja-jp/development/backend/ruby_style_guide.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: none
group: unassigned
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Ruby style guide
---

6
doc-locale/ja-jp/development/backup_and_restore/backup_gitlab.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: Tenant Scale
group: Geo
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: How GitLab backups work?
---

6
doc-locale/ja-jp/development/bitbucket_cloud_importer.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: none
group: unassigned
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Bitbucket Cloud importer developer documentation
---

6
doc-locale/ja-jp/development/bitbucket_server_importer.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: none
group: unassigned
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Bitbucket Server importer developer documentation
---

6
doc-locale/ja-jp/development/build_test_package.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: Systems
group: Distribution
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Building a package for testing
---

6
doc-locale/ja-jp/development/bulk_import.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: Foundations
group: Import and Integrate
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Group migration by direct transfer
---

6
doc-locale/ja-jp/development/bulk_imports/contributing.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: Foundations
group: Import and Integrate
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Add new relations to the direct transfer importer
---

6
doc-locale/ja-jp/development/cached_queries.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: Systems
group: Cloud Connector
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Cached queries guidelines
---

6
doc-locale/ja-jp/development/caching.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: none
group: unassigned
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Caching guidelines
---

6
doc-locale/ja-jp/development/cascading_settings.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: Foundations
group: Personal Productivity
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Cascading Settings
---

6
doc-locale/ja-jp/development/cells/_index.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: Tenant Scale
group: Cells Infrastructure
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: GitLab Cells Development Guidelines
---

6
doc-locale/ja-jp/development/cells/application_settings_analysis.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: Tenant Scale
group: Cells Infrastructure
info: Analysis of Application Settings for Cells 1.0.
title: Application Settings analysis
---

6
doc-locale/ja-jp/development/cells/configuration.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: Tenant Scale
group: Cells Infrastructure
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Configuration
---

6
doc-locale/ja-jp/development/cells/topology_service.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: Tenant Scale
group: Cells Infrastructure
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Topology Service
---

152
doc-locale/ja-jp/development/changelog.md
View File

@ -2,155 +2,5 @@
stage: none
group: unassigned
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: 変更履歴エントリ
title: Changelog entries
---
このガイドでは、変更履歴エントリファイルを生成するタイミングと方法、および変更履歴プロセスに関する情報と履歴について説明します。
## 概要
[`CHANGELOG.md`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/CHANGELOG.md)ファイル内の各リスト項目、または**エントリ**は、Gitコミットのサブジェクト行から生成します。`Changelog` [Gitトレーラー](https://git-scm.com/docs/git-interpret-trailers)を収容できる場合には、コミットを含みます。変更履歴の生成時には、作成者とマージリクエストの詳細を自動的に追加します。
`Changelog`トレーラーは、次の値を受け入れます。
- `added`:新機能
- `fixed`:バグ修正
- `changed`:機能変更
- `deprecated`:新規非推奨
- `removed`:機能削除
- `security`:セキュリティ修正
- `performance`:パフォーマンス改善
- `other`:その他
変更履歴に含めるGitコミットの例を次に示します。
```plaintext
Update git vendor to gitlab
Now that we are using gitaly to compile git, the git version isn't known
from the manifest, instead we are getting the gitaly version. Update our
vendor field to be `gitlab` to avoid cve matching old versions.
Changelog: changed
```
マージリクエストに複数のコミットがある場合、[`Changelog`エントリを最初のコミットに追加していることを確認します](changelog.md#how-to-generate-a-changelog-entry)。こうしておくとコミットをスカッシュしたときに正しいエントリを生成します。
### 関連するマージリクエストをオーバーライドする
GitLabは、変更履歴を生成するときに、自動的にマージリクエストをコミットにリンクします。リンクするマージリクエストをオーバーライドする場合は、`MR`トレーラーを使用して代替マージリクエストを指定できます。
```plaintext
Update git vendor to gitlab
Now that we are using gitaly to compile git, the git version isn't known
from the manifest, instead we are getting the gitaly version. Update our
vendor field to be `gitlab` to avoid cve matching old versions.
Changelog: changed
MR: https://gitlab.com/foo/bar/-/merge_requests/123
```
その値は、マージリクエストのフルURLである必要があります。
### GitLab Enterpriseを変更する
変更がGitLab Enterpriseエディション専用である場合は、トレーラー`EE: true`を**追加する必要**があります。
```plaintext
Update git vendor to gitlab
Now that we are using gitaly to compile git, the git version isn't known
from the manifest, instead we are getting the gitaly version. Update our
vendor field to be `gitlab` to avoid cve matching old versions.
Changelog: changed
MR: https://gitlab.com/foo/bar/-/merge_requests/123
EE: true
```
EEとCEの両方に適用する変更については、トレーラーを追加**しない**でください。
## 変更履歴エントリが必要な場合
- データベース移行が行われる変更では、定期的な移行であれデプロイ後の移行であれデータ移行であれ、変更履歴エントリが無効な機能フラグの背後にあっても、変更履歴エントリが**必要**です。
- [セキュリティ修正](https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/engineer.md)には、`security`に設定された`Changelog`トレーラーを含む変更履歴エントリが**必要**です。
- ユーザーに影響する変更には、すべて変更履歴エントリが**必要**です。例:「GitLabでは、すべてのテキストにシステムフォントを使用するようになりました。」
- RESTやGraphQL APIへのクライアントに影響する変更には、すべて変更履歴エントリが**必要**です。[GraphQLの互換性を維持しない変更を構成する完全なリスト](api_graphql_styleguide.md#breaking-changes)を参照してください。
- [高度な検索移行](search/advanced_search_migration_styleguide.md#create-a-new-advanced-search-migration)を行う変更には、すべて変更履歴エントリが**必要**です。
- （月次リリースの候補版で行ったバグの修正など）同じリリースで発生してデバッグしたリグレッションの修正には、変更履歴エントリを行っては**なりません**。
- （リファクタリング、技術的負債の修正、Testスイートの変更など）デベロッパーに影響する変更には、一切変更履歴エントリを行っては**なりません**。例:「サイクル分析モデル仕様で作成したデータベースレコードを削減します。」
- コミュニティメンバーからの_なんらかの_コントリビュートはたとえ小さくても、コントリビューターが希望するなら、ガイドラインに関係なく変更履歴エントリを行っても**かまいません**。
- [実験](experiment_guide/_index.md)の変更には、変更履歴エントリを行っては**なりません**。
- ドキュメントの変更のみを含むMR（マージリクエスト）には、変更履歴エントリを行っては**なりません**。
詳細については、[機能フラグで変更履歴エントリを処理する方法](feature_flags/_index.md#changelog)を参照してください。
## 優れた変更履歴エントリを作成する
優れた変更履歴エントリは、説明的で簡潔でなければなりません。これは変更に関する_背景状況をまったく知らない_読者に、変更内容を説明するものです。簡潔さと説明性の両立が難しい場合は、説明を優先させてください。
- **悪い例: **プロジェクトの順序に移動します。
- **良い例:**「プロジェクトへ移動」ドロップダウンリストの一番上に、ユーザーのお気に入りプロジェクトを表示します。
最初の例では、変更が行われた箇所、その理由、ユーザーにどのように役立つのかといった背景状況が不明です。
- **悪い例: **（一部のテキスト）をクリップボードにコピーします。
- **良い例:**「クリップボードにコピー」ツールチップを更新して、コピーする内容を示すようにします。
これも最初の例はあいまいすぎて、背景状況が分かりません。
- **悪い例: **ミニパイプライングラフのCSSとHTMLの問題を修正し改善し、ドロップダウンリストをビルドします。
- **良い例:**ミニパイプライングラフのツールチップとホバー状態を修正し、ドロップダウンリストをビルドします。
最初の例は、実装の詳細に焦点を当てすぎています。ユーザーは、CSSやHTMLの変更は気にせず、その変更の_最終結果_を気にします。
- **悪い例: **`find_commits_by_message_with_elastic`から返されるコミットオブジェクトの配列で`nil`を取り除きます
- **良い例: **ガベージコレクションしたコミットを参照するElasticsearchの結果により、500のエラーを修正します
最初の例は、_何_を修正したのかではなく、_どのように_修正したかに焦点を当てています。書き換えられたバージョンでは、ユーザーにとっての_最終的なメリット_（500のエラーを削減）と、_いつ_（Elasticsearchでコミットを検索したとき）を明確に説明しています。
最善の判断を下し、列挙した変更履歴を読んでいる人の考え方を理解するように努めてください。このエントリは価値を追加しますか？変更を行った_場所_と_理由_についての背景状況を提供していますか？
## 変更履歴エントリの生成方法
Gitトレーラーは、変更をコミットするときに追加します。これは選択したテキストエディタで実行できます。既存のコミットにトレーラーを追加するには、（最新のコミットである場合）コミットへの修正、または`git rebase -i`によるインタラクティブなリベースが必要です。
最終のコミットを更新するには、次の命令を実行します。
```shell
git commit --amend
```
これでコミットメッセージに`Changelog`トレーラーを追加できます。以前のコミットをremoteブランチにすでにプッシュしていた場合は、以下のように新しいコミットを強制的にプッシュする必要があります。
```shell
git push -f origin your-branch-name
```
古い（または複数の）コミットを編集するには`git rebase -i HEAD~N`を使用します。ここで`N`はリベースする最終コミット数です。たとえばブランチに3つのコミットA、B、Cがあるとします。コミットBを更新する場合は、次のコマンドを実行する必要があります。
```shell
git rebase -i HEAD~2
```
これで最後の2つのコミットのインタラクティブなリベースセッションを開始します。開始すると、Gitは次の行に沿ってコンテンツを含むテキストエディタを表示します。
```plaintext
pick B Subject of commit B
pick C Subject of commit C
```
コミットBを更新するには、単語`pick`を`reword`に変更し、エディターを保存して終了します。いったん閉じると、Gitは新しいテキストエディタインスタンスを表示し、コミットBのコミットメッセージを編集できます。トレーラーを追加し、次にエディターを保存して終了します。すべてうまくいけば、コミットBが更新されます。
remoteブランチにすでに存在するコミットを変更したため、remoteブランチにプッシュするときには次のように`--force-with-lease`フラグを使用する必要があります。
```shell
git push origin your-branch-name --force-with-lease
```
インタラクティブなリベースの詳細については、[Gitドキュメント](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)を参照してください。
---
[開発ドキュメントに戻る](_index.md)

6
doc-locale/ja-jp/development/chaos_endpoints.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: none
group: unassigned
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Generating chaos in a test GitLab instance
---

6
doc-locale/ja-jp/development/chatops_on_gitlabcom.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: Deploy
group: Environments
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: ChatOps on GitLab.com
---

6
doc-locale/ja-jp/development/cicd/_index.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: Verify
group: Pipeline Execution
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: CI/CD development guidelines
---

6
doc-locale/ja-jp/development/cicd/cicd_reference_documentation_guide.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: Verify
group: Pipeline Authoring
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Documenting pipeline configuration keywords
---

6
doc-locale/ja-jp/development/cicd/cicd_tables.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: Verify
group: Pipeline Execution
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Add new tables to the CI database
---

6
doc-locale/ja-jp/development/cicd/components.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: Verify
group: Pipeline Authoring
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Development guide for GitLab official CI/CD components
---

6
doc-locale/ja-jp/development/cicd/configuration.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: Verify
group: Pipeline Authoring
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Contribute to the CI/CD configuration
---

6
doc-locale/ja-jp/development/cicd/pipeline_wizard.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: none
group: unassigned
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Pipeline Wizard
---

6
doc-locale/ja-jp/development/cicd/schema.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: Verify
group: Pipeline Authoring
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Contribute to the CI/CD Schema
---

378
doc-locale/ja-jp/development/cicd/templates.md
View File

@ -2,381 +2,5 @@
stage: Verify
group: Pipeline Authoring
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: GitLab CI/CDテンプレートの作成ガイド（非推奨）
title: Development guide for GitLab CI/CD templates (Deprecated)
---
{{< alert type="note" >}}
GitLabは、[CI/CDカタログ](../../ci/components/_index.md#cicd-catalog)の導入により、コードベースに対する新たなCI/CDテンプレートのコントリビュートの受け付けを終了しました。それに代わるものとして、カタログ用の[CI/CDコンポーネント](../../ci/components/_index.md)をチームメンバーが作成することを推奨します。この移行に伴い、共有のCI/CDリソースのモジュール性と保守性が向上します。また、新たなCI/CDテンプレートをコントリビュートする際の複雑性を回避できます。既存のテンプレートを更新する必要がある場合は、それに対応するCI/CDコンポーネントも更新する必要があります。CI/CDテンプレートに対応するコンポーネントがまだ存在しない場合は、[対応するコンポーネントの作成](components.md)を検討してください。これを行うことで、GitLabの新しい開発プラクティスに沿って、テンプレートとコンポーネントの機能の同期を保つことができます。
{{< /alert >}}
このドキュメントでは、[GitLabのCI/CDテンプレート](../../ci/examples/_index.md#cicd-templates)の作成方法について説明します。
## CI/CDテンプレートの要件
CI/CDテンプレートの新規作成または更新の際、マージリクエスト（MR）を送信する前に以下のことを行う必要があります。
- テンプレートを適切な[ディレクトリ](#template-directories)に配置します。
- [CI/CDテンプレートの作成ガイドライン](#template-authoring-guidelines)に従います。
- テンプレートの名前を`*.gitlab-ci.yml`形式に沿って設定します。
- 有効な[`.gitlab-ci.yml`構文](../../ci/yaml/_index.md)を用います。[CI/CD lintツール](../../ci/yaml/lint.md)を使って、構文の有効性を検証します。
- [テンプレートメトリクスを追加](#add-metrics)します。
- マージリクエストでユーザー向けの変更が生じる場合には、[変更履歴](../changelog.md)を含めます。
- [テンプレートレビュープロセス](#contribute-cicd-template-merge-requests)に従います。
- （オプション、ただし強く推奨）レビュアーがアクセス可能なサンプルのGitLabプロジェクトで、テンプレートをテストします。テンプレートが必要とするデータや設定は、レビュアー自身で作成できない場合があります。サンプルのプロジェクトがあると、レビュアーがテンプレートの正確性を検証する際に役立ちます。レビュー用のマージリクエストの送信に先立ち、サンプルのプロジェクトでパイプラインを成功させておく必要があります。
## テンプレートディレクトリ
テンプレートファイルはすべて`lib/gitlab/ci/templates`に保存します。一般的なテンプレートは、このディレクトリに保存します。ただし、一部の種類のテンプレートは、それぞれ専用の特定のディレクトリに保存します。[新しいファイルUIでテンプレートを選択](#make-sure-the-new-template-can-be-selected-in-ui)できるかどうかは、テンプレートのあるディレクトリによって決まります。
| サブディレクトリ | UIで選択可能か | テンプレートの種類 |
|----------------|------------------|---------------|
| `/*`（ルート） | 可 | 一般的なテンプレート。 |
| `/AWS/*` | 不可 | クラウドデプロイメント（AWS）関連のテンプレート。 |
| `/Jobs/*` | 不可 | Auto DevOps関連のテンプレート。 |
| `/Pages/*` | 可 | GitLab Pagesで静的サイトジェネレーターを使用するためのサンプルのテンプレート。 |
| `/Security/*` | 可 | セキュリティスキャナー関連のテンプレート。 |
| `/Terraform/*` | 不可 | Infrastructure as Code（Terraform）関連のテンプレート。 |
| `/Verify/*` | 可 | テスト機能に関連するテンプレート。 |
| `/Workflows/*` | 不可 | 「`workflow:`」キーワードを使用するためのサンプルのテンプレート。 |
## テンプレート作成ガイドライン
以下のガイドラインに従って、標準に準拠したテンプレートを送信するようにしてください。
### テンプレートの種類
テンプレートには2つの種類があり、それによってテンプレートの記述方法と使用方法が異なります。テンプレートの記述方式は、次の2種類のいずれかに1つに従う必要があります。
**パイプラインテンプレート**は、プロジェクトの構造や言語などに合わせた、エンドツーエンドのCI/CDワークフローを提供します。通常、他の`.gitlab-ci.yml`ファイルが存在しないプロジェクトで、独立して使用します。
パイプラインテンプレートを作成する場合:
- `image`や`before_script`などの[グローバルキーワード](../../ci/yaml/_index.md#global-keywords)を、テンプレート上部の[`default`](../../ci/yaml/_index.md#default)セクションに配置します。
- 既存の`.gitlab-ci.yml`ファイルで`includes`キーワードを使用してテンプレートを作成するかどうかを、[コードコメント](#explain-the-template-with-comments)で明確に指定します。
**ジョブテンプレート**は、既存のCI/CDワークフローに追加できる特定のジョブを提供し、特定のタスクを実行します。通常は[`includes`](../../ci/yaml/_index.md#global-keywords)キーワードを使用して、既存の`.gitlab-ci.yml`ファイルに追加して使用します。またコンテンツをコピーして既存の`.gitlab-ci.yml`ファイルに貼り付けることもできます。
ユーザーがほとんど、またはまったく変更せずに現在のパイプラインに追加できるよう、ジョブテンプレートを設定します。他のパイプライン設定と競合するリスクを軽減するように設定する必要があります。
ジョブテンプレートを作成する場合:
- [グローバル](../../ci/yaml/_index.md#global-keywords)キーワードや[`default`](../../ci/yaml/_index.md#default)キーワードを使用しないでください。ルート`.gitlab-ci.yml`にテンプレートが含まれている場合、グローバルキーワードやデフォルトキーワードが上書きされ、予期しない動作が起こることがあります。ジョブテンプレートに特定のステージが必要な場合は、ユーザーがステージをメインの`.gitlab-ci.yml`設定に手動で追加する必要があることを、コードコメントで説明します。
- `includes`キーワードを使用するようにテンプレートを設計しているか、既存の設定にコピーするように設計しているかを、[コードコメント](#explain-the-template-with-comments)に明記します。
- 最新バージョンと安定バージョンでテンプレートを[バージョニング](#versioning)し、[下位互換性](#backward-compatibility)の問題の回避を検討します。このタイプのテンプレートのメンテナンスはより複雑になります。`includes`でインポートされたテンプレートの変更は、テンプレートを使用するすべてのプロジェクトのパイプラインを中断する場合があるためです。
テンプレートを作成する際に留意すべきその他のポイント:
| テンプレート設計ポイント | パイプラインテンプレート | ジョブテンプレート |
|------------------------------------------------------|--------------------|---------------|
| `stages`を含むグローバルキーワードの使用 | 可 | 不可 |
| ジョブの定義 | 可 | 可 |
| 新しいファイルUI内での選択 | 可 | 不可 |
| `include`で他のジョブテンプレートを含める | 可 | 不可 |
| `include`で他のパイプラインテンプレートを含める | 不可 | 不可 |
### 構文のガイドライン
テンプレートをより簡単に追跡できるように、テンプレートはすべて一貫したフォーマットで、明確な構文スタイルを使用する必要があります。
各ジョブの`before_script`、`script`、`after_script`キーワードは [ShellCheck](https://www.shellcheck.net/)を使用してLintし、可能な限り[Shellスクリプトの標準とスタイルガイドライン](../shell_scripting_guide/_index.md)を遵守する必要があります。
ShellCheck は、[Bash](https://www.gnu.org/software/bash/)を使用して実行するようスクリプトを設計していることを想定しています。Bash ShellCheckルールと互換性のないシェルにスクリプトを使用するテンプレートは、ShellCheck Lintから除外できます。スクリプトを除外するには、[`scripts/lint_templates_bash.rb`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/scripts/lint_templates_bash.rb)の`EXCLUDED_TEMPLATES`リストに追加します。
#### デフォルトブランチをハードコード化しない
ハードコード化した`main`ブランチの代わりに[`$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH`](../../ci/variables/predefined_variables.md)を使用し、`master`は絶対に使用しないでください。
```yaml
job:
rules:
if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
script:
echo "example job"
```
#### `only`または`except`の代わりに`rules`を使用する
可能な限り[`only`や`except`](../../ci/yaml/_index.md#only--except)の使用を避けてください。[`rules`](../../ci/yaml/_index.md#rules)が推奨構文になり、onlyやexceptはもう使用しません。
```yaml
job2:
script:
- echo
rules:
- if: $CI_COMMIT_BRANCH
```
#### 長いコマンドを分割する
コマンドが非常に長い場合、または`-o`や`--option`のようなコマンドラインフラグが多い場合:
- フラグを複数行のコマンドに分割して、コマンドの各部を簡単に見られるようにします。
- フラグに長い名前が利用可能な場合は、それを使用します。
たとえば、`docker run --e SOURCE_CODE="$PWD" -v "$PWD":/code -v /var/run/docker.sock:/var/run/docker.sock "$CODE_QUALITY_IMAGE" /code`のような短いCLIフラグを持つ長いコマンドの場合:
```yaml
job1:
script:
- docker run
--env SOURCE_CODE="$PWD"
--volume "$PWD":/code
--volume /var/run/docker.sock:/var/run/docker.sock
"$CODE_QUALITY_IMAGE" /code
```
`|`や`>`YAMLオペレータを使用して[複数行コマンドを分割](../../ci/yaml/script.md#split-long-commands)することもできます。
### コメントでテンプレートを説明する
新しいファイルメニューからテンプレートの内容にアクセスできますが、それがテンプレートに関する情報をユーザーが確認できる唯一の場所である可能性があります。テンプレートの動作はテンプレート自体で明確にドキュメント化することが重要です。
次のガイドラインでは、すべてのテンプレート送信で想定される基本的なコメントについて説明します。コメントがユーザーや[テンプレートのレビュアー](#contribute-cicd-template-merge-requests)に役立つと思われる場合は、必要に応じてコメントを追加します。
#### 要件と期待値を説明する
ファイルの先頭にある`#`コメントで、テンプレートの使用方法の詳細を提示します。これには以下が含まれます。
- リポジトリ/プロジェクトの要件。
- 期待される動作。
- テンプレートを使用する前にユーザーが編集する必要がある箇所。
- テンプレートを設定ファイルにコピーして貼り付けるか、既存のパイプラインで`include`キーワードを用いてテンプレートを使用するか。
- 変数をプロジェクトの CI/CD 設定に保存する必要があるか。
```yaml
# Use this template to publish an application that uses the ABC server.
# You can copy and paste this template into a new `.gitlab-ci.yml` file.
# You should not add this template to an existing `.gitlab-ci.yml` file by using the `include:` keyword.
#
# Requirements:
# - An ABC project with content saved in /content and tests in /test
# - A CI/CD variable named ABC-PASSWORD saved in the project CI/CD settings. The value
# should be the password used to deploy to your ABC server.
# - An ABC server configured to listen on port 12345.
#
# You must change the URL on line 123 to point to your ABC server and port.
#
# For more information, see https://gitlab.com/example/abcserver/README.md
job1:
...
```
#### 変数がテンプレートの動作にどう影響するかを説明する
テンプレートが変数を使用する場合は、最初に定義している`#`コメントでその説明をします。変数が自明である場合は、コメントを省略できます。
```yaml
variables: # Good to have a comment here, for example:
TEST_CODE_PATH: <path/to/code> # Update this variable with the relative path to your Ruby specs
job1:
variables:
ERROR_MESSAGE: "The $TEST_CODE_PATH path is invalid" # (No need for a comment here, it's already clear)
script:
- echo ${ERROR_MESSAGE}
```
#### ローカル変数以外の変数には、すべて大文字の名前を使用する
変数をCI/CD設定または`variables`キーワードを介して提供することを想定している場合、その変数には、アンダースコア（`_`）で単語を区切ったすべて大文字の名前を使用する必要があります。
```yaml
.with_login:
before_script:
# SECRET_TOKEN should be provided via the project settings
- echo "$SECRET_TOKEN" | docker login -u my-user --password-stdin my-registry
```
小文字の名前は、`script`キーワードの1つでローカルに定義している変数にオプションとして使用できます。
```yaml
job1:
script:
- response="$(curl "https://example.com/json")"
- message="$(echo "$response" | jq -r .message)"
- 'echo "Server responded with: $message"'
```
### 下位互換性
`include:template:`キーワードでテンプレートを動的にインクルードする場合があります。*既存*のテンプレートを変更する場合は、**絶対に**既存のプロジェクトのCI/CDを中断しないようにします。
たとえばテンプレート内のジョブ名を変更すると、既存のプロジェクトのパイプラインを中断する可能性があります。次のコンテンツに`Performance.gitlab-ci.yml`という名前のテンプレートがあるとします。
```yaml
performance:
image: registry.gitlab.com/gitlab-org/verify-tools/performance:v0.1.0
script: ./performance-test $TARGET_URL
```
ユーザーは、`performance`ジョブに引数を渡してこのテンプレートを含めます。これは_ジョブ_の`.gitlab-ci.yml`でCI/CD変数`TARGET_URL`を指定すると実行できます。
```yaml
include:
template: Performance.gitlab-ci.yml
performance:
variables:
TARGET_URL: https://awesome-app.com
```
テンプレート内のジョブ名`performance`が`browser-performance`に名前変更されたら、ユーザーの`.gitlab-ci.yml`は、インクルードされたテンプレートに`performance`という名前のジョブがなくなったため、すぐにlintエラーが発生します。よってユーザーはワークフローを煩わせる可能性のある`.gitlab-ci.yml`を修正しなければなりません。
破壊的変更を安全に導入するには、[バージョニング](#versioning) セクションを参照してください。
## バージョニング
現在のテンプレートに依存している、既存のプロジェクトに影響を与えずに破壊的変更を導入するには、[安定](#stable-version)している[最新](#latest-version)のバージョンを使用します。
安定テンプレートは通常、メジャーバージョンリリースでのみ破壊的変更を受け入れますが、最新テンプレートは、どのリリースの破壊的変更でも受け入れることができます。メジャーリリースのマイルストーンでは、最新テンプレートが新しい安定テンプレートになります（最新テンプレートは削除される可能性があります）。
最新テンプレートの追加は安全ですが、メンテナンスの負担を伴います。
- GitLabは、GitLabの次のメジャーリリース時に最新テンプレートの内容で安定テンプレートを上書きする、DRIを選択する必要があります。DRIは変更に問題があるユーザーをサポートする責任を負います。
- 新たに非破壊的変更を加える場合は、可能な限り、安定テンプレートと最新テンプレートの両方を一致させるように更新する必要があります。
- 多くのユーザーが最新テンプレートの存在継続に直接的に依存している可能性があるため、最新テンプレートは想定よりも長く残ることがあります。
新たな最新テンプレートを追加する前に、変更が破壊的変更であっても、代わりに安定テンプレートに変更を加えることができるかを確認します。テンプレートがコピーペーストの使用のみを意図しているなら、安定バージョンを直接変更できる可能性があります。マイナーマイルストーンで安定テンプレートに破壊的変更を行う前に、以下を確認します。
- これは[パイプラインテンプレート](#template-types)であり、`includes`を使用するようには設計していないことを説明する[コードコメント](#explain-requirements-and-expectations)があること。
- [CI/CDテンプレート使用状況メトリクス](#add-metrics)に使用状況を表示しないこと。メトリクスがテンプレートの使用状況をゼロと表示する場合、テンプレートで`include`を積極的に使用していないこと。
### 安定バージョン
安定したCI/CDテンプレートは、メジャーリリースマイルストーンでのみ破壊的変更を導入するテンプレートです。テンプレートの安定バージョンには`<template-name>.gitlab-ci.yml`のような名前を付けます。たとえば`Jobs/Deploy.gitlab-ci.yml`などです。
`15.0`のようなGitLabのメジャーマイルストーンリリースで利用できる[最新テンプレート](#latest-version)をコピーして、新しい安定テンプレートを作成できます。すべての破壊的変更は、[バージョンごとの非推奨と削除](../../update/deprecations.md)ページで告知する必要があります。
次の場合、`15.1`のようなマイナーGitLabリリースで安定テンプレートバージョンを変更できます。
- 変更が[破壊的変更](#backward-compatibility)ではないこと。
- 変更を[最新のテンプレート](#latest-version)（存在する場合）に移植すること。
### 最新バージョン
`latest`とマークしたテンプレートは、[破壊的変更](#backward-compatibility)を加える場合でも、任意のリリースで更新できます。最新バージョンと見なされる場合は、テンプレート名に`.latest`を追加します（たとえば`Jobs/Deploy.latest.gitlab-ci.yml`）。
[破壊的変更](#backward-compatibility)を導入する場合は、**必ず**[アップグレードパス](#verify-breaking-changes)をテストしてドキュメント化してください。通常、予期しない問題でユーザーを驚かせる可能性があるため、最新テンプレートを最適なオプションとして推奨しないでください。
`latest`テンプレートがまだ存在しない場合、[安定テンプレート](#stable-version)をコピーできます。
### 以前の安定テンプレートを含める方法
ユーザーは、現在のGitLabパッケージにバンドルされていない、以前の[安定テンプレート](#stable-version)を使用することがあります。たとえばGitLab 15.0とGitLab 16.0の安定テンプレートは非常に異なっているかもしれず、その場合ユーザーはGitLab 16.0にアップグレードした後でもGitLab 15.0テンプレートを引き続き使用したいと考えます。
`include:remote`を使用して以前のテンプレートバージョンを含める方法を説明するメモをテンプレートまたはドキュメントに追加できます。他のテンプレートを`include: template`でインクルードする場合は、`include: remote`と組み合わせることができます。
```yaml
# To use the v13 stable template, which is not included in v14, fetch the specific
# template from the remote template repository with the `include:remote:` keyword.
# If you fetch from the GitLab canonical project, use the following URL format:
# https://gitlab.com/gitlab-org/gitlab/-/raw/<version>/lib/gitlab/ci/templates/<template-name>
include:
- template: Auto-DevOps.gitlab-ci.yml
- remote: https://gitlab.com/gitlab-org/gitlab/-/raw/v13.0.1-ee/lib/gitlab/ci/templates/Jobs/Deploy.gitlab-ci.yml
```
### さらに詳しく
GitLab CI/CDテンプレートにバージョニングの概念を導入することには、[未解決のイシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/17716)があります。そのイシューを確認して、経過を見守ります。
## テスト
各CI/CDテンプレートはテストして、公開しても安全であることを確認する必要があります。
### 手動QA
最小限のデモプロジェクトでテンプレートをテストすることを強く推奨します。これを行うには、次の手順に従います。
1. <https://gitlab.com>に公開サンプルプロジェクトを作成します。
1. 推奨テンプレートを使用し、`.gitlab-ci.yml`をプロジェクトに追加します。
1. パイプラインを実行し、起こり得るすべての事例（マージリクエストパイプライン、スケジュールなど）で、すべてが適切に実行されることを確認します。
1. 新しいテンプレートを追加するマージリクエストの説明で、プロジェクトにリンクします。
これはレビュアーがテンプレートを安全にマージできることを確認する際に役立つ情報です。
### 新しいテンプレートがUIで選択できることを確認する
一部のディレクトリにあるテンプレートは、[**新しいファイル**UI](#template-directories)でも選択できます。いずれかのディレクトリにテンプレートを追加する場合は、ドロップダウンリストに正しく表示されることを確認します。
![CI/CDテンプレートの選択](img/ci_template_selection_v13_1.png)
### RSpecテストを作成する
パイプラインジョブが正しく生成されることを確認するには、RSpecテストを作成する必要があります。
1. `spec/lib/gitlab/ci/templates/<template-category>/<template-name>_spec.rb`にテストファイルを追加します
1. `Ci::CreatePipelineService`を介してパイプラインジョブが適切に作成されるかテストします。
### 破壊的変更を確認する
[`latest`テンプレート](#latest-version)に破壊的変更を導入する場合は、以下を行う必要があります。
1. [安定テンプレート](#stable-version)からのアップグレードパスをテストします。
1. ユーザーがどのような種類のエラーに遭遇するかを確認します。
1. トラブルシューティングガイドとしてドキュメント化します。
この情報は、メジャーバージョンのGitLabリリースで[安定テンプレート](#stable-version)を更新した場合に、ユーザーにとって重要となります。
### メトリクスを追加する
すべてのCI/CDテンプレートには、その使用状況を追跡するよう定義したメトリクスも必要です。CI/CDテンプレートの月間使用状況レポートは、[Sisense（GitLab チームメンバーのみ）](https://app.periscopedata.com/app/gitlab/785953/Pipeline-Authoring-Dashboard?widget=13440051&udv=0)で確認できます。テンプレートを選択して、その単一のテンプレートのグラフを表示します。
新しいテンプレートのメトリクス定義を追加するには、次の手順を実行します。
1. [GitLab GDK](https://gitlab.com/gitlab-org/gitlab-development-kit#installation)をインストールして起動します。
1. GDKの`gitlab`ディレクトリで、新しいテンプレートを含むブランチをチェックアウトします。
1. 新しいテンプレートイベント名を、毎週および毎月のCI/CDテンプレートの合計数メトリクスに追加します。
- [`config/metrics/counts_7d/20210216184557_ci_templates_total_unique_counts_weekly.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/metrics/counts_7d/20210216184557_ci_templates_total_unique_counts_weekly.yml)
- [`config/metrics/counts_28d/20210216184559_ci_templates_total_unique_counts_monthly.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/metrics/counts_28d/20210216184559_ci_templates_total_unique_counts_monthly.yml)
1. [新しいメトリクス定義を追加](../internal_analytics/metrics/metrics_instrumentation.md#create-a-new-metric-instrumentation-class)するには、上記のイベント名と同じ名前を次のコマンドの最後の引数にします。
```shell
bundle exec rails generate gitlab:usage_metric_definition:redis_hll ci_templates <template_metric_event_name>
```
出力は次のようになります。
```shell
$ bundle exec rails generate gitlab:usage_metric_definition:redis_hll ci_templates p_ci_templates_my_template_name
create config/metrics/counts_7d/20220120073740_p_ci_templates_my_template_name_weekly.yml
create config/metrics/counts_28d/20220120073746_p_ci_templates_my_template_name_monthly.yml
```
1. 新しく生成された両方のファイルを次のように編集します。
- `name:`と`performance_indicator_type:`: 削除します（不要）。
- `introduced_by_url:`: テンプレートを追加するMRのURL。
- `data_source:`: `redis_hll`に設定します。
- `description`: このメトリクスが何を計測するのか簡単な説明を追加します。例: `Count of pipelines using the latest Auto Deploy template`
- `product_*`: [セクション、ステージ、グループ、機能カテゴリ](https://handbook.gitlab.com/handbook/product/categories/#devops-stages)を、[メトリクスディクショナリガイド](../internal_analytics/metrics/metrics_dictionary.md#metrics-definition-and-validation)に従って設定します。こういったキーワードに何を使用すべきかわからない場合は、マージリクエストでヘルプを求めることができます。
- 各ファイルの末尾に以下を追加します。
```yaml
options:
events:
- p_ci_templates_my_template_name
```
1. 変更をコミットしてプッシュします。
たとえば、これらは[5つの詳細な本番環境アプリテンプレート](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/5-Minute-Production-App.gitlab-ci.yml)のメトリクス設定ファイルです。
- 毎週および毎月のメトリクス定義:
- [`config/metrics/counts_7d/20210901223501_p_ci_templates_5_minute_production_app_weekly.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/1a6eceff3914f240864b2ca15ae2dc076ea67bf6/config/metrics/counts_7d/20210216184515_p_ci_templates_5_min_production_app_weekly.yml)
- [`config/metrics/counts_28d/20210901223505_p_ci_templates_5_minute_production_app_monthly.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/metrics/counts_28d/20210216184517_p_ci_templates_5_min_production_app_monthly.yml)
- メトリクスのカウント総数:
- [`config/metrics/counts_7d/20210216184557_ci_templates_total_unique_counts_weekly.yml#L19`](https://gitlab.com/gitlab-org/gitlab/-/blob/4e01ef2b094763943348655ef77008aba7a052ae/config/metrics/counts_7d/20210216184557_ci_templates_total_unique_counts_weekly.yml#L19)
- [`config/metrics/counts_28d/20210216184559_ci_templates_total_unique_counts_monthly.yml#L19`](https://gitlab.com/gitlab-org/gitlab/-/blob/4e01ef2b094763943348655ef77008aba7a052ae/config/metrics/counts_28d/20210216184559_ci_templates_total_unique_counts_monthly.yml#L19)
## セキュリティ
テンプレートには、悪意のあるコードが含まれている可能性があります。たとえばジョブに`export`シェルコマンドを含むテンプレートは、ジョブログでシークレットプロジェクトのCI/CD変数を誤って公開する可能性があります。安全かどうか不明な場合は、セキュリティの専門家にクロス検証を依頼する必要があります。
## CI/CDテンプレートのマージリクエストにコントリビュートする
CI/CDテンプレートのMRを作成して`ci::templates`をラベル付けしたら、DangerBotがコードをレビューできる1人のレビュアーと1人のメンテナーを提案します。マージリクエストのレビューの準備ができたら、レビュアーに[メンション](../../user/discussions/_index.md#mentions)し、CI/CDテンプレートの変更のレビューを依頼します。[CI/CD テンプレートMRのDangerBotタスク](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/44688)を追加した、マージリクエストの詳細を参照してください。

6
doc-locale/ja-jp/development/cicd/testing.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: Verify
group: Pipeline Authoring
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Testing guide for CI/CD Rails application code
---

6
doc-locale/ja-jp/development/cloud_connector/_index.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: Systems
group: Cloud Connector
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Cloud Connector
---

6
doc-locale/ja-jp/development/cloud_connector/architecture.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: Systems
group: Cloud Connector
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: 'Cloud Connector: Architecture'
---

6
doc-locale/ja-jp/development/cloud_connector/configuration.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: Systems
group: Cloud Connector
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: 'Cloud Connector: Configuration'
---

6
doc-locale/ja-jp/development/code_comments.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: none
group: unassigned
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Code comments
---

7
doc-locale/ja-jp/development/code_intelligence/_index.md Normal file
View File

@ -0,0 +1,7 @@
---
stage: Create
group: Code Review
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
description: Developer documentation for the Code Intelligence feature.
title: Code intelligence development guidelines
---

6
doc-locale/ja-jp/development/code_owners/_index.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: Create
group: Source Code
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Code Owners development guidelines
---

620
doc-locale/ja-jp/development/code_review.md
View File

@ -2,623 +2,5 @@
stage: none
group: unassigned
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: コードレビューガイドライン
title: Code Review Guidelines
---
このガイドでは、コードレビューの実施と、コードレビューを受ける上でのアドバイスとベストプラクティスを紹介します。
GitLab CEとEEのマージリクエストはどれも、GitLabチームメンバーが作成したか、広範なコミュニティメンバーが作成したかにかかわらず、コードレビュー処理を行い、コードが効果的で、理解しやすく、保守しやすく、安全であることを確認する必要があります。
## マージリクエストのレビュー、承認、マージの実施
開始前に:
- [コントリビュートの承認基準](contributing/merge_request_workflow.md#contribution-acceptance-criteria)をよく理解します。
- ガイダンスが必要な場合（たとえば初めてのマージリクエストの場合）は、[マージリクエストコーチ](https://about.gitlab.com/company/team/?department=merge-request-coach)の1人にお気軽にお問い合わせください。
レビューするコードができたらすぐに、[レビュアー](https://handbook.gitlab.com/handbook/engineering/workflow/code-review/#reviewer)のコード**レビュー**を受けます。このレビュアーは、グループやチームのメンバー、または[特定領域のエキスパート](#domain-experts)である場合があります。レビュアーは以下を行います。
- 選択したソリューションと実装について、セカンドオピニオンを提供します。
- バグ、ロジックの問題、または未解決のエッジケースを探す支援をします。
マージリクエストが小規模でレビューが簡単な場合は、レビュアーのステップをスキップして、直接[メンテナー](https://handbook.gitlab.com/handbook/engineering/workflow/code-review/#maintainer)に依頼できます。
何が「小規模で簡単」であるかはグレーゾーンです。小規模で簡単な変更の例を次に示します。
- タイプミスを修正したり、コピーを少し変更したりする場合（[例](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/121337#note_1399406719)）。
- 動作やデータを変更しない、ごくわずかなリファクタリング。
- 1か月以上デフォルトで有効になっている機能フラグへの参照の削除。
- 未使用のメソッドやクラスの削除。
- コードの5行未満の変更を必要とする、よく理解されているロジックの変更。
それ以外の場合、マージリクエスト（MR）は、MRが影響を与える各[カテゴリ（バックエンド、データベースなど）](#approval-guidelines)のレビュアーによる最初のレビューを受ける必要があります。なぜならメンテナーは関連する特定領域の知識を持っていない可能性があるためです。これはワークロードの分散にも役立ちます。
セキュリティスキャンやコメントの支援については、アプリケーションセキュリティチーム（`@gitlab-com/gl-security/appsec`）を含めます。
レビュアーは、サイドバーの[レビュアー機能](../user/project/merge_requests/reviews/_index.md)を使用します。レビュアーは、[追加で承認](../user/project/merge_requests/approvals/_index.md#approve-a-merge-request)して承認を追加できます。
マージリクエストが影響を与える領域に応じて、1人以上の[メンテナー](https://handbook.gitlab.com/handbook/engineering/workflow/code-review/#maintainer)による**承認**が必要となります。**承認**ボタンは、マージリクエストウィジェットにあります。
マージリクエストを**マージ**するには、メンテナーも必要です。複数の承認が必要な場合、レビューし承認する最後のメンテナーがマージします。
一部の特定領域（`Verify`など）では、CODEOWNERSルールに基づいて、特定領域エキスパートの承認が必要です。CODEOWNERSセクションは独立した承認ルールであるため、他のより一般的な承認ルール（`backend`など）のサブセットである、特定のルール（`Verify`など）が存在する可能性があります。より効率的に処理するには、作成者が一般的な承認の前に特定領域固有の承認を求める必要があります。特定領域固有の承認者はメンテナーでもある可能性があり、その場合は特定領域固有の変更と、より広範な変更を同時にレビューし、両方のロールに対して1回承認することとします。
詳細は以下の[作成者の責任](#the-responsibility-of-the-merge-request-author)をお読みください。
### 特定領域エキスパート
特定領域エキスパートは、特定の技術、製品機能、またはコードベースの領域で豊富な経験を持つチームメンバーです。チームメンバーは、特定領域エキスパートとしてのアイデンティティを持ち、それを[チームプロファイル](https://handbook.gitlab.com/handbook/engineering/workflow/code-review/#how-to-self-identify-as-a-domain-expert)に追加することを推奨します。
特定領域エキスパートとしてアイデンティティを持つ場合は、`.yml`ファイルを変更するMRを、すでに確立されている特定領域エキスパートまたは該当するエンジニアリングマネージャーがマージするように割り当てることを推奨します。
次のような場合には、自動的に特定領域エキスパートと見なすと想定しています。
- 特定のステージ/グループ（ソースコードの作成など）で作業しているチームメンバーは、作業しているアプリの領域の特定領域エキスパートと見なします。
- 特定の機能（検索など）に取り組んでいるチームメンバーは、その機能の特定領域エキスパートと見なします。
コードレビューについては自動的に、特定領域の専門知識を持つチームメンバーにレビューを割り当てます。UXレビューは自動的に、レビュールーレット（ランダム選択）で推奨されたレビュアーに割り当てます。デザイナーのキャパシティの制限により、製品デザイナーがサポートしていない領域では、コミュニティへのコントリビュートでない限り、UXレビューは不要になります。適切な[特定領域エキスパート](#domain-experts)を割り当てられない場合は、チームメンバーの誰かを選択してMRをレビューするか、[レビュアールーレット](#reviewer-roulette)（ランダム選択）の推奨に従います（UXレビューについては上記を参照）。割り当てる前に、その人が不在でないか再確認します。
特定領域エキスパートは次の手順で見つけます。
- マージリクエスト承認ウィジェットで、[適格な承認者を表示](../user/project/merge_requests/approvals/rules.md#eligible-approvers)を選択します。このウィジェットは、コードベースの領域ごとに推奨される承認と必要な承認を表示します。そのルールは[コードオーナー](../user/project/merge_requests/approvals/rules.md#code-owners-as-eligible-approvers)で定義しています。
- マージリクエストに関連する[ステージやグループ](https://handbook.gitlab.com/handbook/product/categories/#devops-stages)で作業するチームメンバーのリストを表示します。
- [エンジニアリングプロジェクト](https://handbook.gitlab.com/handbook/engineering/projects/)ページまたは[GitLabチームページ](https://about.gitlab.com/company/team/)に、チームメンバーの特定領域での専門知識を表示します。特定領域は自分で識別するため、自分の判断でマージリクエストの変更を特定領域にマッピングします。
- マージリクエストの対象ファイルに貢献したチームメンバーを探します。`git log <file>`を実行してログを表示します。
- ファイルをレビューしたチームメンバーを探します。関連するマージリクエストは、次の方法で見つけます。
1. `git log <file>`を使用して、コミットSHAを取得します。
1. `https://gitlab.com/gitlab-org/gitlab/-/commit/<SHA>`に移動します。
1. コミットに表示される、関連するマージリクエストを選択します。
### レビュアールーレット
{{< alert type="note" >}}
レビュアールーレットは、GitLab.comで使用するための社内ツールであり、お客様のインストール環境では使用できません。
{{< /alert >}}
[Dangerボット](dangerbot.md)は、マージリクエストが影響を与えると思われるコードベースの各領域に対して、レビュアーとメンテナーをランダムに選択します。そうしてボットがデベロッパーのレビュアーを**推奨**します。他の人がより適していると思う場合は、推奨を上書きする必要があります。
[承認ガイドライン](#approval-guidelines)は、[特定領域エキスパート](#domain-experts)の選択に役立ちます。
製品デザイナーを含むチームからのMRにのみ、UXレビューを実施します。そのようなチームからのユーザー向け変更には、機能フラグの背後にある場合でも、UXレビューが必要です。基本的には、推奨される人をUXレビュアーとします。
レビュアーとメンテナーは、[エンジニアリングプロジェクト](https://handbook.gitlab.com/handbook/engineering/projects/)ページのリストから、以下の条件で選択します。
- Slackまたは[GitLabステータス](../user/profile/_index.md#set-your-status)が次のいずれかのユーザーは、選択肢から外します。
- 文字列`OOO`、`PTO`、`Parental Leave`、`Friends and Family`、または`Conference`が含まれている。
- 絵文字が次のカテゴリのいずれかである。
- **休暇中** \- 🌴 `palm_tree`、🏖️ `beach`、⛱ `beach_umbrella`、🏖 `beach_with_umbrella`、🌞 `sun_with_face`、🎡 `ferris_wheel`、🏙 `cityscape`
- **病欠** \- 🌡️ `thermometer`、🤒 `face_with_thermometer`
- 重要: ステータスの絵文字は、フリーテキスト入力の**ステータスメッセージ**に表示されている場合は検出されません。テキスト入力の横にある絵文字セレクターをクリックして、GitLabの**ステータス絵文字**で設定する必要があります。
- 選択した「レビュー制限」以上の数のレビューがすでに割り当てられている人は選択肢から外します。レビュー制限とは、人が一度に処理できるレビューの最大数です。Slackまたは[GitLabステータス](../user/profile/_index.md#set-your-status)として次のいずれかを使用して、レビュー制限を設定します。
- 2️⃣ - `two`
- 3️⃣ - `three`
- 4️⃣ - `four`
- 5️⃣ - `five`
最小レビュー制限は2️⃣です。レビューをを完全にオフにできない理由は、[このイシュー](https://gitlab.com/gitlab-org/quality/engineering-productivity/team/-/issues/377)で議論しています。
[セキュリティグループ](https://gitlab.com/gitlab-org/security/)下の、プロジェクトのデフォルトブランチをターゲットとしないマージリクエストのレビューリクエストは、カウントしません。このようなMRは通常はバックポートで、メンテナーやレビュアーは通常、レビューに多くの時間を費やす必要がないからです。
- ポイント1で示すようにオフィス不在（`OOO`）ステータスが変わらない限り、同じブランチ名には常に同じレビュアーとメンテナーを選択します。また先頭の`ce-`と`ee-`、末尾の`-ce`と`-ee`を削除し、バックポートブランチが安定するようにします。
- Slackまたは[GitLabステータス](../user/profile/_index.md#set-your-status)の絵文字がⓂ `:m:`の人は、メンテナーであるプロジェクトのレビュアーとしてのみ提案されます。
[ルーレットダッシュボード](https://gitlab-org.gitlab.io/gitlab-roulette/)には次のものが含まれています。
- 過去7日間と30日間の割り当てイベント。
- 現在、1人あたりに割り当てられているマージリクエスト。
- さまざまな基準による並べ替え。
- 手動レビュアールーレット。
- 現地時間の情報。
詳細については、[ルーレットのREADME](https://gitlab.com/gitlab-org/gitlab-roulette/)をレビューしてください。
### 承認ガイドライン
以下のメンテナーの責任に関するセクションで説明しているように、[特定領域の専門知識](#domain-experts)を持つメンテナーにマージリクエストを承認し、マージしてもらうことを推奨します。最初のレビュアーのオプションとしての承認は、これには含まれません。ただしマージリクエストは、[概要](#getting-your-merge-request-reviewed-approved-and-merged)セクションで説明しているように、メンテナーに渡す前にレビュアーがレビューする必要があります。
| マージリクエストに以下が含まれている場合 | 以下の担当者による承認が必要 |
| ------------------------------- | ------------------------ |
| `~backend`の変更<sup>1</sup> | [バックエンドメンテナー](https://handbook.gitlab.com/handbook/engineering/projects/#gitlab_maintainers_backend)。 |
| `~database`の移行またはコストのかかるクエリの変更<sup>2</sup> | [データベースメンテナー](https://handbook.gitlab.com/handbook/engineering/projects/#gitlab_maintainers_database)。詳細は[データベースレビューガイドライン](database_review.md)を参照してください。 |
| `~workhorse`の変更 | [Workhorseメンテナー](https://handbook.gitlab.com/handbook/engineering/projects/#gitlab_maintainers_workhorse)。 |
| `~frontend`の変更<sup>1</sup> | [フロントエンドメンテナー](https://handbook.gitlab.com/handbook/engineering/projects/#gitlab_maintainers_frontend)。 |
| `~UX`ユーザー向け変更<sup>3</sup> | [製品デザイナー](https://handbook.gitlab.com/handbook/engineering/projects/#gitlab_reviewers_UX)。詳細については、[設計とユーザーインターフェイスのガイドライン](contributing/design.md)を参照してください。 |
| 新しいJavaScriptライブラリの追加<sup>1</sup> | \- ライブラリが[バンドルサイズ](https://gitlab.com/gitlab-org/frontend/playground/webpack-memory-metrics/-/blob/main/doc/report.md)を大幅に増やす場合は、[フロントエンドデザインシステムのメンバー](https://about.gitlab.com/direction/foundations/design_system/)。<br/>\- 新しいライブラリで使用するライセンスが、GitLabでの使用の承認を得ていない場合は、[法務部門のメンバー](https://handbook.gitlab.com/handbook/legal/)。<br/><br/>ライセンスの互換性に関する詳細については、[GitLabライセンスと互換性に関するドキュメント](licensing.md)を参照してください。 |
| 新しい依存関係またはファイルシステムの変更 | - [配布チームメンバー](https://about.gitlab.com/company/team/)。詳細は[配布チーム](https://handbook.gitlab.com/handbook/engineering/infrastructure/core-platform/systems/distribution/#how-to-work-with-distribution)との作業方法を参照してください。<br/>\- RubyGemsの場合は、[AppSecレビュー](gemfile.md#request-an-appsec-review)をリクエストします。 |
| `~documentation`または`~UI text`の変更 | 適切な[DevOpsステージグループ](https://handbook.gitlab.com/handbook/product/categories/#devops-stages)の割り当てに基づく[テクニカルライター](https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments)。 |
| 開発ガイドラインの変更 | [レビュープロセス](development_processes.md#development-guidelines-review)に従い、それに応じて承認を取得します。 |
| エンドツーエンドの変更**と**非エンドツーエンドの変更<sup>4</sup> | [テスト担当ソフトウェアエンジニア](https://handbook.gitlab.com/handbook/engineering/quality/#individual-contributors)。 |
| エンドツーエンドの変更のみ<sup>4</sup>**または**MR作成者が[テスト担当ソフトウェアエンジニア](https://handbook.gitlab.com/handbook/engineering/quality/#individual-contributors)の場合 | [品質メンテナー](https://handbook.gitlab.com/handbook/engineering/projects/#gitlab_maintainers_qa)。 |
| [アプリケーション制限](https://handbook.gitlab.com/handbook/product/product-processes/#introducing-application-limits)の新規作成または更新 | [製品マネージャー](https://about.gitlab.com/company/team/)。 |
| 分析機器（遠隔測定または分析）の変更 | [分析機器のエンジニア](https://gitlab.com/gitlab-org/analytics-section/analytics-instrumentation/engineers)。 |
| [機能仕様](testing_guide/testing_levels.md#frontend-feature-tests)の追加または変更 | [品質メンテナー](https://handbook.gitlab.com/handbook/engineering/projects/#gitlab_maintainers_qa)または[品質レビュアー](https://handbook.gitlab.com/handbook/engineering/projects/#gitlab_reviewers_qa)。 |
| GitLabへの新しいサービス（Puma、Sidekiq、Gitalyなど） | [製品マネージャー](https://about.gitlab.com/company/team/)。詳細は、[GitLabにサービスコンポーネントを追加するプロセス](adding_service_component.md)を参照してください。 |
| 認証に関連する変更 | [管理: 認証](https://about.gitlab.com/company/team/)。詳細については、[グループページのコードレビューセクション](https://handbook.gitlab.com/handbook/engineering/development/sec/software-supply-chain-security/authentication/#code-review)を確認してください。チームによるレビューが必要なことがわかっているファイルのパターンは、[`CODEOWNERS`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/CODEOWNERS)ファイルの`Authentication`セクションにリストしており、これらのファイルを変更するすべてのマージリクエストの承認者セクションに、チームをリスト表示します。 |
| カスタムロールまたはポリシーに関連する変更 | [管理: 承認エンジニア](https://gitlab.com/gitlab-org/software-supply-chain-security/authorization/approvers/)。 |
1. JavaScript仕様以外の仕様は、`~backend`コードと見なします。Hamlマークアップは`~frontend`コードと見なします。ただし、HamlテンプレートでのRubyコードは`~backend`コードと見なします。不明な場合は、フロントエンドとバックエンドの両方のレビューをリクエストします。
1. マージリクエストによってコストのかかるクエリが起こる可能性がある場合は、データベースメンテナーにガイダンスを求めることを推奨します。疑問のあるコードの行にSQLクエリでコメントするのが最も効率的で、そうするとメンテナーがアドバイスできます。
1. ユーザー向け変更には、視覚的な変更（変更の軽微さに無関係）と、スクリーンリーダーがコンテンツをアナウンスする方法に影響を与える、レンダリングしたDOMへの変更の両方が含まれます。専任の製品デザイナーがいないグループでは、変更がコミュニティへのコントリビュートでない限り、製品デザイナーが機能の変更を承認する必要はありません。
1. エンドツーエンドの変更には、`qa`ディレクトリ内の全ファイルが含まれます。
#### CODEOWNERSの承認
一部のマージリクエストでは、特定のグループによる必須の承認が必要です。定義については`.gitlab/CODEOWNERS`を参照してください。
`.gitlab/CODEOWNERS`の必須セクションは、次の理由により必要な場合にのみ制限する必要があります。
- コンプライアンス
- 可用性
- セキュリティ
必須セクションを追加するときは、マージリクエストの進行度に対する新しい必須セクションの影響を追跡する必要があります。その好例については、[Verifyイシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/411559)を参照してください。
その他のすべてのケースでは、[硬直性よりも責任](https://handbook.gitlab.com/handbook/values/#freedom-and-responsibility-over-rigidity)を優先するため、必須セクションを使用しないでください。
さらに一枚岩的な現在の構造は、マージリクエストが見かけ上無関係な部分に影響する可能性が高いことを意味します。複数の承認が必須であるとは、そのようなマージリクエストでは作成者が承認を求める必要があることを意味しますが、それは効率的ではありません。
これを改善するための取り組みは次のとおりです。
- <https://gitlab.com/groups/gitlab-org/-/epics/11624>
- <https://gitlab.com/gitlab-org/gitlab/-/issues/377326>
#### 受け入れチェックリスト
<!-- When editing, remember to announce the change to Engineering Division -->
このチェックリストを使用して、マージリクエスト（MR）の作成者、レビュアー、メンテナーが、品質、パフォーマンス、信頼性、セキュリティ、可観測性、保守性に対する影響の大きいリスクについて変更を分析したことを確認してください。
チェックリストを使用すると、ソフトウェアエンジニアリングの品質が向上します。このチェックリストは、GitLabコードベースへのコントリビューターのスキルをサポートし、強化するための明快なツールです。
##### 品質
品質ガイドラインの詳細については、[テストエンジニアリングプロセス](https://handbook.gitlab.com/handbook/engineering/infrastructure/test-platform/test-engineering/)を参照してください。
1. [コードレビューガイドライン](code_review.md)に従って、このMRを自己レビューしました。
1. コードは[ソフトウェア設計ガイドライン](software_design.md)に従っています。
1. [テストピラミッド](testing_guide/testing_levels.md)に従って、[自動テスト](testing_guide/_index.md)の存在を確認します。不足しているテストを追加するか、テストギャップを文書化するイシューを作成します。
1. GitLab.com、Dedicated、Self-Managedに対する技術的な影響を検討しました。
1. 必要に応じて、システムのフロントエンド、バックエンド、データベースの一部分へのこの変更の影響を検討し、それに応じて`~ux`、`~frontend`、`~backend`、`~database`のラベルを付けました。
1. [サポートされているすべてのブラウザ](../install/requirements.md#supported-web-browsers)でこのMRをテストしました。あるいはこのテストは不要と判断しました。
1. この変更が[アップデート間で下位互換性がある](multi_version_compatibility.md)ことを確認しました。あるいはこの変更は該当しないと判断しました。
1. [EEコンテンツ](ee_features.md)（存在する場合）をFOSSから適切に分離しました。[FOSSコンテキストでCIパイプラインを実行](ee_features.md#run-ci-pipelines-in-a-foss-context)することを検討します。
1. 既存のデータが実に多様であるかもしれないことを検討しました。たとえば、新しいモデル検証を追加する場合は、既存のデータではオプションにすることを検討します。
1. このMRに関連するFlakyテストを修正したか、または無視できる理由を説明しました。Flakyテストには`Flaky test '<path/to/test>' was found in the list of files changed by this MR.`というエラーがありますが、警告付きでパスするジョブに存在する可能性があります。
##### パフォーマンス、信頼性、可用性
1. このMRがパフォーマンスを損なうことはないと確信しているか、あるいはレビュアーにパフォーマンスへの影響の評価のサポートを依頼しました。（[マージリクエストのパフォーマンスガイドライン](merge_request_concepts/performance.md)）
1. [MRの説明にデータベースのレビュアー向けの情報](database_review.md#required)を追加したか、不要であると判断しました。
- [このMRにはデータベース関連の変更が含まれていますか？](database_review.md)
1. この変更による可用性と信頼性のリスクを検討しました。
1. 将来予測される成長に基づいて、スケーラビリティのリスクを検討しました。
1. 平均的なお客様よりも大幅に多くのデータを持つ可能性のある大規模なお客様に対する、この変更によるパフォーマンス、信頼性、可用性への影響を検討しました。
1. [最小システム](../install/requirements.md)で GitLab を実行する可能性のあるお客様に対する、この変更によるパフォーマンス、信頼性、可用性への影響を検討しました。
##### 可観測性の計測機器
1. 観測によりデバッグとプロアクティブなパフォーマンス改善を促進する機器を十分に含めました。機能フラグ、ログの生成、機器の追加の[例](https://gitlab.com/gitlab-org/gitlab/-/issues/346124#expectations)を参照してください。
##### ドキュメント
1. 変更履歴トレーラーを含めたか、または不要であると判断しました。
- [このMRには変更履歴が必要ですか？](changelog.md#what-warrants-a-changelog-entry)
1. ドキュメントを追加/更新したか、またはこのMRではドキュメントの変更は不要であると判断しました。
- [ドキュメントは必須ですか？](https://handbook.gitlab.com/handbook/product/ux/technical-writing/workflow/#documentation-for-a-product-change)
##### セキュリティ
1. このMRに認証情報やトークン、承認、認証方法、または[セキュリティレビューガイドライン](https://handbook.gitlab.com/handbook/security/product-security/application-security/appsec-reviews/#what-should-be-reviewed)に記載されているその他の項目の処理や保存に対する変更が含まれている場合、`~security`ラベルを追加し、`@`で`@gitlab-com/gl-security/appsec`にメンションしたことを確認しました。
1. セキュリティレビューをリクエストする**時期**と**方法**について、[内部アプリケーションセキュリティレビュー](https://handbook.gitlab.com/handbook/security/product-security/application-security/appsec-reviews/#internal-application-security-reviews)に関するドキュメントをレビューし、この変更で必要であれば、セキュリティレビューをリクエストしました。
1. [マージリクエスト承認ポリシー](https://gitlab.com/gitlab-com/gl-security/security-policies)により、MRをブロックしているセキュリティスキャン結果がある場合：
- 真陽性の結果については、マージリクエストをマージする前に修正する必要があります。この場合、マージリクエスト承認ポリシーで必要となるAppSec承認が不要となります。
- 偽陽性の結果、リスク許容について議論する必要があるもの、または疑わしいものについては、`@gitlab-com/gl-security/appsec`にpingします。
##### デプロイ
1. 変更が高リスクである可能性があるため、この変更に機能フラグを使用することを検討しました。
1. 機能フラグを使用している場合は、本番環境でテストする前にステージングで変更のテストを計画し、すべてのお客様に展開する前に、本番環境の顧客のサブセットで運用を開始することを検討しました。
- [機能フラグを使用する場合](https://handbook.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#when-to-use-feature-flags)
1. [完了の定義](contributing/merge_request_workflow.md#definition-of-done)に従って、デフォルト設定または新しい設定変更をインフラストラクチャ部門に通知したか、または不要であると判断しました。
##### コンプライアンス
1. 正しい[MRタイプラベル](labels/_index.md)が付けられいることを確認しました。
### マージリクエストの作成者の責任
最適なソリューションを見つけて実装する責任は、マージリクエストの作成者にあります。作成者または[直接の責任者](https://handbook.gitlab.com/handbook/people-group/directly-responsible-individuals/)（DRI）は、コードレビューのライフサイクル全体を通して、マージリクエストに担当者として割り当てられたままになります。自分を担当者として設定できない場合は、[レビュアー](https://handbook.gitlab.com/handbook/engineering/workflow/code-review/#reviewer)に依頼します。
メンテナーからのレビューをリクエストして、承認しマージする前に、以下を確認する必要があります。
- 解決すべき問題をそれで実際に解決すること。
- 最も適切な方法で解決すること。
- すべての要件を満たしていること。
- バグ、論理的な問題、未解決のエッジケース、または既知の脆弱性が残っていないこと。
これを行うための最良の方法として、またレビュアーとの不要なやり取りを避けるために、[コードレビュー](#reviewing-a-merge-request)ガイドラインに従って、自分自身のマージリクエストの自己レビューを実行します。この自己レビュー中には、決定やトレードオフが行われた行、またはコンテキストの説明によってレビュアーがコードをより簡単に理解するのに役立つ可能性がある行について、MR内にコメントを含めるようにします。
ソリューションに必要なレベルの信頼を得るために、作成者には、調査や実装プロセスに他の人を適宜関与させることを期待しています。
さまざまなソリューションについて話し合ったり、実装のレビューを受けるために[特定領域エキスパート](#domain-experts)に連絡したり、混乱の解消や最終結果が彼らが考えていたものと一致することを確認するために製品マネージャーやUXデザイナーに連絡したり、データモデルや特定のクエリに関する意見を得るためにデータベーススペシャリストに連絡したり、ソリューションの詳細なレビューを受けるために他の開発者に連絡したりすることを推奨します。
ある機能を達成するために多くのマージリクエストが必要になることがわかっている場合（たとえば概念実証を作成して、機能が10以上のマージリクエストで構成されることが明らかな場合）、その機能に必要な理解を持つレビュアーとメンテナーを特定し、コンテキストを彼らと共有することを検討します。次にすべてのマージリクエストをこれらのレビュアーに送信します。これらのレビュアーを見つける最適なDRIは、EMやスタッフエンジニアです。同じコンテキストの複数のマージリクエストに、安定したレビュアーという担当者を持つと、効率が向上します。
マージリクエストが複数の特定領域（たとえば動的な分析とGraphQL）に影響する場合は、各特定領域のエキスパートにレビューを依頼します。
作成者がマージリクエストに[特定領域エキスパート](#domain-experts)の意見が必要かどうかわからないのであれば、必要ということです。意見を求めなければ、ソリューションに必要なレベルの信頼性を得られる可能性は低まりす。
レビューの前に作成者はマージリクエストの差分の程度に関するコメントを送信して、重要なものや、さらなる説明や注意が必要なものについてレビュアーに警告するように求められます。コメントを必要とする可能性のあるコンテンツの例を次に示します。
- Lintルール（RuboCop、JSなど）の追加。
- ライブラリ（Ruby gem、JS libなど）の追加。
- 明白でない場合は、親クラスまたはメソッドへのリンク。
- 変更を補足するために実行したベンチマーク。
- 安全でない可能性があるコード。
レビュアーがソリューションを検証するにあたって必要なプロジェクト、スニペット、またはその他の資産がある場合、レビューをリクエストする前に、レビュアーがその資産へのアクセス権を持っていることを確認します。
レビュアーを割り当てる際には、次のような点が役立ちます。
- どの*タイプ*のレビューをそのレビュアーに求めているかを示すコメントをMRに追加します。
- たとえばMRがデータベースクエリを変更し、バックエンドコードを更新する場合、MR作成者は最初に`~backend`レビューと`~database`レビューを必要とします。レビュアーを割り当てる際に作成者は、各レビュアーにどの特定領域をレビューする必要があるかを知らせるコメントをMRに追加します。
- 多くのGitLabチームメンバーは複数の特定領域でのエキスパートであるため、このタイプのコメントがないと、どのタイプのレビューを提供するように求められているのかが曖昧になる場合があります。
- MRレビュータイプを明確に示すと、MR作成者にとっては求めているタイプのレビューが得られるために効率的で、またMRレビュアーにとっては、どのタイプのレビューを提供するかをすぐに知ることができるため効率的です。
- [例1](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/75921#note_758161716)
- [例2](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/109500#note_1253955051)
避けるべきこと：
- TODOコメント（上記参照）をソースコードに直接追加すること（レビュアーが要求する場合を除く）。実行可能なタスクのためにTODOコメントを追加する場合は、[関連するイシューへのリンクを含めます](code_comments.md)。
- コードが行っていることを説明するだけのコメントを追加すること。TODO以外のコメントを追加する場合は、[_その理由を説明すべきで、内容の説明は不要です_](https://blog.codinghorror.com/code-tells-you-how-comments-tell-you-why/)。
- 失敗したテストを含むマージリクエストのメンテナーレビューをリクエストすること。テストが失敗し、レビューをリクエストする必要がある場合は、必ず説明を含むコメントを残してください。
- メールやSlackを通じて過度にメンテナーにメンションすること（メンテナーがSlackを通じて連絡できる場合）。マージリクエストのレビュアーを追加できない場合は、`@`コメントでメンテナーへのメンションは許容されますが、それ以外の場合はレビュアーの追加で十分です。
これでレビュアーの時間を節約し、作成者がより早くミスを把握できるようになります。
### レビュアーの責任
レビュアーには、選択されたソリューションの詳細をレビューする責任があります。
[レビュー応答 SLO](https://handbook.gitlab.com/handbook/engineering/workflow/code-review/#review-response-slo)内で割り当てられたマージリクエストをレビューできない場合：
1. レビューできないことを作成者に通知します。
1. [GitLabレビューワークロードダッシュボード](https://gitlab-org.gitlab.io/gitlab-roulette/)を使用して、新しいレビュアーを選択します。
1. マージリクエストに新しいレビュアーを割り当てます。
これは[迅速な行動](https://handbook.gitlab.com/handbook/values/#operate-with-a-bias-for-action)の実践で、効率的なMRレビューの進行を保証します。
次のようなコメントを追加します。
```plaintext
Hi <@mr-author>, I'm unavailable for review but I've [spun the roulette wheel](https://gitlab-org.gitlab.io/gitlab-roulette/) for this project and it has selected <@new-reviewer>.
@new-reviewer may you please review this MR when you have time? If you're unavailable, please [spin the roulette wheel](https://gitlab-org.gitlab.io/gitlab-roulette/) again and select and assign a new reviewer, thank-you.
/assign_reviewer <@new-reviewer>
/unassign_reviewer me
```
徹底的に[マージリクエストをレビュー](#reviewing-a-merge-request)します。
マージリクエストがすべての[コントリビュートの受入基準](contributing/merge_request_workflow.md#contribution-acceptance-criteria)を満たしていることを確認します。
マージリクエストによっては、特定領域エキスパートが細部を支援する必要がある場合があります。レビュアーは、その特定領域のエキスパートでない場合、次のいずれかを行うことができます。
- マージリクエストをレビューし、別のレビューの特定領域エキスパートに最新情報を伝えます。このエキスパートは、別のレビュアーまたはメンテナーのいずれかになります。
- より適切と思われる別のレビュアーにレビューを渡します。
- 特定領域エキスパートを起用できない場合は、できる範囲内で最善のレビューをします。
以下の場合に、マージリクエストをより小さなマージリクエストに分割するよう作成者を誘導する必要があります。
- 大きすぎる。
- 複数の問題を修正する。
- 複数の機能を実装する。
- 複雑性が高く、追加のリスクが発生する。
作成者は、現在のメンテナーとレビュアーが分割したMRをレビューするようリクエストするか、新しいメンテナーとレビュアーのグループをリクエストするかを選択できます。
作成者がローカル検証ステップを追加した場合は通知します。それでメンテナーはその検証を行ったか、また結果がどうだったかを把握できます。
すべての要件を満たしていると確信した場合は、以下を実行する必要があります。
- **承認**を選択します。
- `@`で作成者にメンションしてTo Do通知を生成し、マージリクエストがレビューされ承認されたことを通知します。
- メンテナーのレビューをリクエストします。基本的には[特定領域の専門知識](#domain-experts)を持つメンテナーを選択しますが、起用できない場合、またはそのマージリクエストには[特定領域エキスパート](#domain-experts)によるレビューが不要だと思われる場合は、[レビュアールーレット](#reviewer-roulette)の推奨事項に従います。
### メンテナーの責任
メンテナーは、特定領域と製品分野全体にわたって、GitLabコードベースの全体的な健全性、品質、一貫性について責任を負います。
したがって彼らのレビューは主に、全体的なアーキテクチャ、コード構成、懸念点の分離、テスト、難解さ、一貫性、読みやすさなどの点に焦点を当てます。
メンテナーの仕事は具体的な特定領域に関する知識ではなく、GitLabコードベース全体の知識にのみ依存しているため、どのチームのどの製品分野のMRでもレビュー、承認、マージできます。
メンテナーは、マージリクエストの受け入れ基準が妥当に満たされていることを保証するDRIです。一般に、[品質はすべての人の責任](https://handbook.gitlab.com/handbook/engineering/quality/)ですが、MRのメンテナーは、MRがそういった一般的な品質基準を満たしていることを**確認**する責任を負います。
これには[フォローアップイシューでの技術的負債の発生の回避](contributing/issue_workflow.md#technical-debt-in-follow-up-issues)が含まれます。
メンテナーがMRに十分な価値があると感じる場合、または[特定領域エキスパート](#domain-experts)が必要な場合、メンテナーは別のレビュアーや別のメンテナーからのレビューをリクエストする裁量権を持ちます。レビュー中にメンテナーがこれをプロアクティブに行う例を次に示します。
- <https://gitlab.com/gitlab-org/gitlab/-/merge_requests/82708#note_872325561>
- <https://gitlab.com/gitlab-org/gitlab/-/merge_requests/38003#note_387981596>
- <https://gitlab.com/gitlab-org/gitlab/-/merge_requests/14017#note_178828088>
メンテナーは、マージする前に選択したソリューションの詳細のレビューにも最善を尽くしますが、必ずしも[特定領域エキスパート](#domain-experts)であるとは限らないため、妥当な時間的投資に見合ってそうすることが難しい場合があります。そのような場合、彼らは作成者と以前のレビュアーの判断に従い、主な責任に注力することを優先します。
たまたまメンテナーでもある開発者がレビュアーとしてマージリクエストに関与した場合、最終的に承認してマージするメンテナーとしても起用しないことを推奨します。
メンテナーはマージする前に、マージリクエストを必要な承認者が承認しているかを確認する必要があります。他からさらに承認をまだ待っている場合は、`@`で作成者にメンションし、コメントで理由を説明します。
特定のマージリクエストは安定したブランチをターゲットにしている可能性があります。このようなリクエストの処理方法の概要については、[パッチリリース手順書](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/patch/engineers.md)を参照してください。
マージ後、メンテナーはマージリクエストにリストされているレビュアーであり続ける必要があります。
### レビュアー機能のドッグフーディング
当社のコードレビュープロセスは、[マージリクエストのレビュー機能](../user/project/merge_requests/reviews/_index.md)をドッグフーディングしています。概要を以下に示します。これは他のセクションにも反映します。
- マージリクエストの作成者とDRIは、担当者であり続けます。
- マージリクエストのレビュアーは、レビュー後もレビュアーであり続けます。
- 作成者は、ユーザーをレビュアーとして割り当てて、[レビューをリクエスト](../user/project/merge_requests/reviews/_index.md#request-a-review)します。
- 作成者が変更を加えてレビュアーに再レビューを依頼する場合は、[レビューを再リクエスト](../user/project/merge_requests/reviews/_index.md#re-request-a-review)します。
- レビュアーは、[レビュー機能](../user/project/merge_requests/reviews/_index.md#start-a-review)を使用してフィードバックを送信します。MRの任意のコメントコンテキストで、**コメントを今すぐ追加**ではなく、**レビューを開始**または**あるレビューを開始**を選択します。
## ベストプラクティス
### 全員
- 思いやりを持ちます。
- 多くのプログラミング判断は見解であることを受け入れます。トレードオフやどちらを好むかについて話し合い、迅速に解決策を見つけます。
- 質問をし、要求はしません。（「この`:user_id`という名前の付け方についてどう思いますか？」）
- 明確化を求めます。（「理解できませんでした。明確にしてもらえますか？」）
- コードの所有権の選択を避けます。（「私のもの」、「私のものじゃない」、「あなたのもの」）
- 個人の特性を指すと見なされる可能性のある用語（「ばか」、「愚か」）の使用は避けます。誰もが知的で善意を持っていると想定します。
- はっきり表現します。人はオンラインで必ずしもあなたの意図を理解しているとは限らないことを忘れないでください。
- 謙虚でいます。（「よくわかりません。調べてみましょう。」）
- 誇張しません。（「常に」、「決して」、「際限なく」、「何もない」）
- 皮肉の使用には注意してください。私たちが行うことはすべて公開されています。あなたと長年の同僚にとって悪意のない有効的なからかいのように見えることは、プロジェクトに不慣れな人にとっては意地悪で歓迎されないように見えるかもしれません。
- 「理解できませんでした」または「代替ソリューション: 」コメントが多すぎる場合は、1対1のチャットまたはビデオ通話を検討します。1対1のディスカッションを要約するフォローアップコメントを投稿します。
- 特定の人物に質問する場合は、常にコメントの冒頭でその人物にメンションします。そうすると通知レベルが「メンション済み」に設定されていればその人物が確実に参照でき、他の人々は応答する必要がないことを理解します。
### 変更をより迅速にマージするためのMR作成者への推奨事項
1. ベストプラクティスに従っていることを確認します。
- 効率的な手順を記述し、スクリーンショット、検証手順などを追加します。
- `dangerbot`が追加したコメントを読んで対処します。
- [受け入れチェックリスト](#acceptance-checklist)でチェックします。
1. より良い方法があると思っても、GitLabのパターンに従います。
- 議論はコードのマージを遅らせることがよくあります。議論が長すぎる場合は、文書化アプローチまたはメンテナーの提案に従うことを検討してから、ベストプラクティスの一部としてご自分のアプローチを実装するために別のMRを開き、そこで議論を行います。
1. 大きなMRを小さく分割することを検討します。約`200`行が適切な目安となります。
- 小さいMRは、作成者とレビュアーの認知負荷を軽減します。
- レビュアーは、最初のレビューには小さいMRを選択する傾向があります（多数のファイルは嫌われることがあります）。
- コードの特定の部分に関する議論は、コードの他の部分のマージを妨げません。
- 小さめのMRは多くの場合単純で、最初のレビューをスキップして[メンテナーに直接送信](#getting-your-merge-request-reviewed-approved-and-merged)したり、提案されたコンピテンシーエリア（たとえばフロントエンドやバックエンド）の1つをスキップすることを検討できます。
- モックは、後で別のMRを追加するとしても、良いアプローチになる可能性があります。モックをサーバーリクエストに置き換えれば、通常、MRを迅速にレビューできます。
- モックデータを含むUIは、必ず[機能フラグ](feature_flags/_index.md)の背後に配置します。
- 過剰なリベースを避けるため、共通の依存関係を最初のMRに取り込みます。
- シーケンシャルMRの場合は、[スタックされた差分](../user/project/merge_requests/stacked_diffs.md)を使用します。
- 従属的なMR（たとえば`A` -> `B` -> `C`）の場合、ブランチは`master`の代わりにお互いをターゲットにします。たとえば`C`が`B`を、`B`が`A`を、`A`が`master`をターゲットにします。こうすると各MRには該当する`diff`のみが含まれます。
- ⚠️ MRの分割で注意すべきなのは、MRが**小さすぎる**とレビューの総数が増え、逆効果となる可能性があることです。
1. 単一のMRでのレビュアー数を最小限に抑えます。
- 例: DBレビュアーはバックエンドやテストもレビューできます。フルスタックエンジニアはフロントエンドとバックエンドの両方のレビューができます。
- モックを使用すると最初のMRは`frontend`のみになり、後でサーバーリクエストの`backend`レビューをリクエストできます（上記の「MR の分割」を参照）。
### マージリクエストのレビューを受ける
コードレビューは複数回イテレーションすることがあるプロセスで、レビュアーは初回では見落とした点を後になって見つける可能性があることに留意してください。
- コードの最初のレビュアーは_あなた_です。新しく作成したブランチを最初にプッシュする前に、差分全体に目をとおします。内容に矛盾はないですか？変更の全体的な目的に無関係なものが含まれていませんか？デバッグコードの削除を忘れていませんか？
- [マージリクエストのガイドライン](contributing/merge_request_workflow.md#merge-request-guidelines-for-contributors)で概説しているように、詳細な説明を記述してください。レビュアーによっては、製品の機能やコードベースの分野に詳しくない場合があります。十分な説明は、すべてのレビュアーがリクエストを理解し、効果的にテストするのに役立ちます。
- 変更が先に行う変更のマージに依存していることがわかっている場合は、説明にそれを記述し、[マージリクエストの依存関係](../user/project/merge_requests/dependencies.md)を設定します。
- レビュアーの提案に感謝します。（「おっしゃるとおりです。そのように変更します。」）
- 個人への意見と受け止めないでください。レビューはコードに対して行うもので、あなたに対してではありません。
- コードが存在する理由を説明します。（「こういう理由により、こうなっています。このクラス/ファイル/メソッド/変数の名前を変更した方がわかりやすくなりますか？」）
- 関係のない変更とリファクタリングを、将来のマージリクエスト/イシューに抽出します。
- レビュアーの視点を理解するように努めます。
- すべてのコメントに返信するよう努めます。
- マージリクエストの作成者は、完全に対応したスレッドのみを解決します。未解決の返信、未解決のスレッド、提案、質問などがある場合、スレッドを残しておき、レビュアーがそれを解決する必要があります。
- すべてのフィードバックに、マージ前にMRに取り入れる変更を推奨する必要があると想定すべきではありません。それが必要かどうか、またはフォローアップイシューを作成して問題のMRがマージされた後に将来的にフィードバックに対応する必要があるかどうかは、MR作成者とレビュアーによる判断となります。
- 以前のフィードバック過程に基づくコミットを、別のコミットとしてブランチにプッシュします。ブランチをマージする準備ができるまで、スカッシュしないでください。以前のフィードバックに基づいて、レビュアーが個々の更新を読めるようにしておきます。
- 別のレビュー過程の準備ができたら、レビュアーに新しいレビューをリクエストします。レビューをリクエストする機能がない場合、代わりに`@`でレビュアーをメンションします。
### レビューのリクエスト
マージリクエストのレビューを受ける準備ができたら、[承認ガイドライン](#approval-guidelines)に基づいてレビュアーを選択し、[最初のレビューをリクエスト](../user/project/merge_requests/reviews/_index.md)する必要があります。
マージリクエストに複数のレビュー領域がある場合は、レビュアーがどの領域を、どのステージ（第1または第2）でレビューする必要があるかを指定することを推奨します。こうすると複数の領域のレビュアーとして適格なチームメンバーは、どの領域のレビューをリクエストされているかを知ることができます。たとえば、マージリクエストに`backend`と`frontend`の両方の懸念がある場合、`@john_doe can you please review ~backend?`または`@jane_doe - could you please give this MR a ~frontend maintainer review?`のようにレビュアーにメンションできます。
`workflow::ready for review`ラベルも使用できます。これは、マージリクエストのレビューの準備ができており、どのレビュアーもそれを選択できることを意味します。時間的なプレッシャーがない場合にのみそのラベルを使用し、マージリクエストがレビュアーに割り当てられていることを確認することを推奨します。
レビューを再度リクエストする場合は、レビュアーの名前の横にある[**レビューを再リクエスト**アイコン](../user/project/merge_requests/reviews/_index.md#re-request-a-review)（{{< icon name="redo" >}}）をクリックするか、`/request_review @user`クイックアクションを使用します。これでマージリクエストは、レビュアーのマージリクエストのホームページの**リクエスト済みレビュー**セクションに表示されるようになります。
マージリクエストが最初のレビュアーからの承認を受けたら、メンテナーに渡すことができます。基本的には[特定領域の専門知識](#domain-experts)を持つメンテナーを選択することとし、それ以外の場合は、レビュアールーレットの推奨事項に従うか、ラベル`ready for merge`を使用します。
場合によっては、メンテナーがレビューに対応できないことがあります。オフィスを不在にしていたり、[他の業務で忙しい](https://handbook.gitlab.com/handbook/engineering/workflow/code-review/#review-response-slo)場合などです。メンテナーの対応可能状況はプロファイルで確認できます。ルーレットで推奨されるメンテナーが対応できない場合は、そのリストから他の人を選択します。
それはレビューするマージリクエストの作成者の責任です。`ready for review`状態が長すぎる場合は、特定のレビュアーにレビューをリクエストすることを推奨します。
### レビューへのボランティア
業務量に余裕のあるGitLabエンジニアは、[レビュー対象のマージリクエスト](https://gitlab.com/groups/gitlab-org/-/merge_requests?state=opened&label_name%5B%5D=workflow%3A%3Aready%20for%20review)のリストを定期的にチェックし、レビューしたいマージリクエストのレビュアーとして自分自身を追加できます。
### マージリクエストのレビュー
変更が必要な理由（バグの修正、ユーザーエクスペリエンスの向上、既存のコードのリファクタリング）を理解します。次に、
- レビューを徹底的に行ない、イテレーションの回数を減らすようにします。
- どのアイデアを優れていると感じ、どれを感じないかを伝えます。
- 問題を解決しながら、コードを簡素化する方法を特定します。
- 代替の実装を提案しますが、作成者がすでにそれらを検討していると想定します。（「ここでカスタムバリデーターを使用することについてどう思いますか？」）
- 作成者の視点を理解するように努めます。
- ブランチをチェックアウトし、ローカルで変更をテストします。実行する手動テストの量を決定できます。テストによっては、自動テストを追加する機会が得られる場合があります。
- コードの一部が理解できない場合は、_そう言います_。他の人も同様に混乱している可能性があります。
- 提案に対処/解決するために作成者から必要なものが何かを、作成者が理解していることを確認します。
- 意図を伝えるために、[通常のコメント形式](https://conventionalcomments.org#format)の使用を検討します。
- 必須ではない提案の場合は（ノンブロッキング）で装飾すれば、作成者はマージリクエスト内でオプションとして解決するか、後日フォローアップすると判断できます。提案がノンブロッキングのみの場合はMRを次のステージに進め、非同期サイクルを削減します。最初のラウンドのレビュアーである場合は、レビューするようにメンテナーに渡します。最終承認メンテナーである場合は、ノンブロッキングな提案からフォローアップを生成し、マージするか、自動マージを設定します。次に作成者が、ノンブロッキングな提案を実装して自動マージをキャンセルするか、MRのマージ後にフォローアップMRを提供するか、提案を実装しないかを決定します。
- [Chrome/Firefox アドオン](https://gitlab.com/conventionalcomments/conventional-comments-button)を使用すると、[通常のコメント](https://conventionalcomments.org/)のプレフィックスを適用できます。
- 未解決の依存関係がないことを確認します。ブロッカーの[リンクしたイシュー](../user/project/issues/related_issues.md)をチェックします。必要に応じて作成者に確認します。未解決のMRによってブロックされている場合は、[MR依存関係](../user/project/merge_requests/dependencies.md)を設定します。
- 行をひととおりチェックした後、「問題ありません」や「対処すべき点が少しあります」などの要約メモを投稿すると役立つ場合があります。
- レビュー後、変更が必要かどうかを作成者に知らせます。
{{< alert type="warning" >}}
**マージリクエストがフォークからのものである場合は、[コミュニティコントリビュートの追加ガイドライン](#community-contributions)も確認します。**
{{< /alert >}}
### マージリクエストのマージ
マージの決定を下す前に以下を行います。
- マイルストーンを設定します。
- 正しい[MRタイプラベル](labels/_index.md#type-labels)を付けていることを確認します。
- Danger ボット、Code Quality、その他のレポートからの警告とエラーを検討します。違反に対して強力なケースを作成できない限り、マージする前にそれらを解決する必要があります。MRを失敗したジョブとマージする場合は、コメントを投稿する必要があります。
- MRに品質関連の変更と品質関連以外の変更の両方が含まる場合、テスト担当ソフトウェアエンジニアが品質関連の変更を承認した後、ユーザー向けの変更（バックエンド、フロントエンド、またはデータベース）を担当するメンテナーがMRをマージすることとします。
マージするには、少なくとも1人のメンテナーがMRを承認する必要があります。MRの作成者とMRにコミットを追加する人は、MRを承認する権限がなく、MRにコントリビュートしていないメンテナーにその承認を求める必要があります。一般に、最終的な必須承認者がMRをマージします。
最終承認者がMRをマージしない状況としては、以下があります。
- 承認者が承認後に自動マージの設定を忘れた場合。
- 承認者が自分が最終承認者であることに気付かない場合。
- 承認者が自動マージを設定したが、GitLabが設定を解除した場合。
このいずれかの状況が発生した場合、MR作成者は、必要とするすべての承認を得ていて、リポジトリに対するマージ権限を持っていれば、自分のMRをマージできます。これはGitLabの[迅速な行動](https://handbook.gitlab.com/handbook/values/#bias-for-action)の価値観にも沿っています。
このポリシーは、GitLabの[変更管理コントロール](https://handbook.gitlab.com/handbook/security/security-and-technology-policies/change-management-policy/)のCHG-04コントロールを満たすように導入しています。
`gitlab-org/gitlab`でこのポリシーを実装するために、次の設定を有効にして、MRがトップレベルのCODEOWNERSメンテナーから承認を得られるようにしました。
- [作成者による承認を防止](../user/project/merge_requests/approvals/settings.md#prevent-approval-by-author)。
- [コミットを追加するユーザーによる承認を防止](../user/project/merge_requests/approvals/settings.md#prevent-approvals-by-users-who-add-commits)。
- [マージリクエストでの承認ルールの編集を防止](../user/project/merge_requests/approvals/settings.md#prevent-editing-approval-rules-in-merge-requests)。
- [コミットがソースブランチに追加されたときにすべての承認を削除](../user/project/merge_requests/approvals/settings.md#remove-all-approvals-when-commits-are-added-to-the-source-branch)。
`gitlab-org/gitlab`の`CODEOWNERS`ファイルでコードオーナーを更新するには、[コードオーナー承認ハンドブックセクション](https://handbook.gitlab.com/handbook/engineering/workflow/code-review/#code-owner-approvals)で説明しているプロセスに従います。
ローカルでのリベースや提案の適用などの一部のアクションは、コミットの追加と同様と見なされ、既存の承認をリセットする場合があります。UIからのリベースや[`/rebase`クイックアクション](../user/project/quick_actions.md)では、承認は削除されません。
マージする準備ができたら:
{{< alert type="warning" >}}
**マージリクエストがフォークからのものである場合は、[コミュニティコントリビュートの追加ガイドライン](#community-contributions)も確認します。**
{{< /alert >}}
- マージリクエストに多数のコミットがある場合は、[スカッシュしてマージ](../user/project/merge_requests/squash_and_merge.md)機能の使用を検討します。コードをマージする際には、メンテナーは、作成者がすでにこのオプションを設定している場合、またはマージリクエストに乱雑なコミット履歴が明らかに含まれている場合にのみ、スカッシュ機能を使用します。それを作成者に連絡するよりも、コミットをスカッシュする方が効率的です。それ以外の場合で、MRにコミットが数個しかないならそれらをスカッシュせず、作成者の設定を尊重します。
- マージリクエストの**パイプライン**タブに移動し、**パイプラインの実行**を選択します。次に**概要**タブで**自動マージ**を有効にします。次の情報を考慮してください。
- **[デフォルトブランチが壊れている](https://handbook.gitlab.com/handbook/engineering/workflow/#broken-master)場合、[非常に特殊なケース](https://handbook.gitlab.com/handbook/engineering/workflow/#criteria-for-merging-during-broken-master)を除き、マージリクエストをマージしないでください**。その他のケースについては、[ハンドブックの手順](https://handbook.gitlab.com/handbook/engineering/workflow/#merging-during-broken-master)に従ってください。
- 最新のパイプラインがマージリクエストの承認前に作成された場合は、新しいパイプラインを開始し、完全なRSpecスイートが実行されていることを確認します。マージリクエストにバックエンドの変更が含まれていない場合にのみ、この手順をスキップできます。
- **最新の[マージ結果パイプライン](../ci/pipelines/merged_results_pipelines.md)**が作成されて**8時間（安定ブランチの場合は72時間）未満の場合**、マージリクエストはターゲットブランチに十分に近いため、新しいパイプラインを開始せずにマージできます。
- MRを自動マージに設定したら、その後見つかったものについては、後続のリビジョンを引き継ぐ必要があります。
- [スカッシュしてマージ](../user/project/merge_requests/squash_and_merge.md)が設定されているマージリクエストの場合、スカッシュしたコミットのデフォルトのコミットメッセージは、マージリクエストのタイトルから取得されます。マージする前に、[より有益なコミットメッセージを含むコミットを選択](../user/project/merge_requests/squash_and_merge.md)することを推奨します。
**マージ結果パイプライン**のおかげで、作成者はブランチを頻繁にリベースする必要がなくなりました（競合がある場合のみ）。マージ結果パイプラインがすでに`main`からの最新の変更を取り込んでいるからです。これでメンテナーは最終的なリベースを要求する必要がなくなり、代わりにMRパイプラインを開始して自動マージを設定するだけで済むため、レビュー/マージサイクルを高速化できます。このステップにより、パイプラインの作成時に最新の`main`に対してマージ結果をテストすれば、実際のマージトレイン機能に非常に近づけられます。
### コミュニティコントリビュート
{{< alert type="warning" >}}
**悪意のあるコードがないか、すべての変更を徹底的にレビューしてから、[マージ結果パイプライン](../ci/pipelines/merge_request_pipelines.md#run-pipelines-in-the-parent-project)を開始します**。
{{< /alert >}}
より広範なコミュニティコントリビューターが追加したマージリクエストをレビューする場合:
- 新しい依存関係と依存関係の更新（Ruby gemやNodeパッケージなど）に特に注意します。`Gemfile.lock`や`yarn.lock`などのファイルへの変更は軽微に見えるかもしれませんが、悪意のあるパッケージのフェッチにつながる可能性があります。
- リンクと画像を（特にドキュメントのMRでは）確認します。
- 疑わしい場合は、`@gitlab-com/gl-security/appsec`の誰かに**マージリクエストパイプラインを手動で開始する前に**マージリクエストを確認するように依頼します。
- マージリクエストが現在のマイルストーンに含まれる可能性が高い場合にのみ、マイルストーンを設定します。これはいつマージされるかについての混乱を避け、まだ準備ができていない場合にマイルストーンを頻繁に移動することを避けるためです。
#### コミュニティマージリクエストの引き継ぎ
MRでさらに変更が必要な場合でも、作成者が長期間応答しない場合や、MRを完了できない場合、GitLabが引き継げます。GitLabエンジニア（通常はマージリクエストのコーチ）は以下を行います。
1. MRにコメントを追加して、マージできるように引き継ぐことを伝えます。
1. MRにラベル`~"coach will finish"`を追加します。
1. mainブランチから新しいフィーチャーブランチを作成します。
1. ブランチを新しいフィーチャーブランチにマージします。
1. 新しいマージリクエストを開き、フィーチャーブランチをmainブランチにマージします。
1. MRからコミュニティMRにリンクし、`~"Community contribution"`とラベルを付けます。
1. 必要な最終調整を行い、コントリビューターにpingして変更をレビューする機会を与え、コンテンツがmainブランチにマージされていることを通知します。
1. コンテンツがすべてのマージリクエストガイドラインに準拠していることを確認します。
1. 通常のマージリクエストと同様に、標準のレビュープロセスに従います。
### 適切なバランス
コードレビュー中に最も難しいことの1つは、作成者が作成したコードに、レビュアーがどの程度深く介入できるかという、適切なバランスを見つけることです。
- 適切なバランスを見つける方法を学ぶには時間がかかります。そのため、マージリクエストのレビューに一定期間費やした後、メンテナーになるレビュアーがいます。
- バグを見つけることは重要ですが、優れた設計について考えることも同様に重要です。抽象化と優れた設計の構築によって、複雑さを隠し、将来の変更が容易に行えるようになります。
- [コードスタイル](contributing/style_guides.md)の順守と改善は、レビューコメントではなく、主に[自動化](https://handbook.gitlab.com/handbook/values/#cleanup-over-sign-off)を通じて行う必要があります。
- 作成者への設計変更の依頼は、コントリビュートされたコードの完全な書き換えを意味する場合があります。それを行う前に別のメンテナーやレビュアーに相談することをお勧めしますが、それが重要であると信じる場合は、実行する勇気を持ってください。
- [イテレーション](https://handbook.gitlab.com/handbook/values/#iteration)の利点ために、レビューでの提案がノンブロッキングな変更、または個人的な好みである（文書化または合意された要件ではない）場合は、作成者に返す前にマージリクエストの承認を検討します。こうすると作成者は自身が同意すればその提案を実装でき、メンテナーにすぐにレビューを依頼できます。これはマージまでの全体的な時間の短縮に役立ちます。
- 物事を正しく行うことと、物事を今すぐ行うことには違いがあります。理想的には前者を実行する必要がありますが、現実の世界では後者も必要です。その良い例として、できるだけ早くリリースする必要があるセキュリティ修正があります。緊急の修正であるマージリクエストで、作成者に対して大規模なリファクタリング実行の依頼は避けるべきです。
- 今日物事をうまく行うことは、大抵、明日何かを完璧に行うことよりも良いものです。一方、間に合わせのものを今日出荷すると、大抵、明日ましなものを出すよりも事態が悪化します。適切なバランスを見つけることができない場合は、他の人に意見を求めてください。
### GitLab 固有の考慮事項
GitLabは多くの場所で使用されています。多くのユーザーが[Omnibus パッケージ](https://about.gitlab.com/install/)を使用していますが、[Dockerイメージ](../install/docker/_index.md)を使用する人もいれば[ソースからインストール](../install/installation.md)する人もいますし、他のインストール方法もあります。GitLab.com自体は大規模なEnterprise Editionのインスタンスです。これにはいくつかの意味合いがあります。
1. **クエリを変更**した場合、GitLab.comの規模でパフォーマンスが悪化しないことを確認するために、次のようなテストする必要があります。
1. ローカルで大量のデータを生成してみます。
1. GitLab.comからのクエリプランの要求は、その検証に最も信頼性の高い方法です。
1. **データベースの移行**においては、以下を確認します。
1. 可逆的であること。
1. GitLab.comの規模でパフォーマンスが高いこと。確信がない場合は、メンテナーにステージング環境で移行をテストするように依頼します。
1. 正しく分類されていること。
- 標準の移行は、新しいコードをインスタンスで実行する前に実施します。
- [デプロイ後の移行](database/post_deployment_migrations.md)は、インスタンスをそのように構成している場合、新しいコードをデプロイした_後_に実行します。
- [バッチ化したバックグラウンド移行](database/batched_background_migrations.md)はSidekiqで実行し、[デプロイ後の移行時間制限](migration_style_guide.md#how-long-a-migration-should-take)GitLab.comスケールを超える移行に使用する必要があります。
1. **Sidekiqワーカー**は、[下位互換性のない方法では変更できません](sidekiq/compatibility_across_updates.md)。
1. デプロイを行う前にSidekiqキューをドレインしないため、キューには以前のバージョンのGitLabからのワーカーが残っています。
1. メソッドシグネチャを変更する必要がある場合は、2つのリリースで変更し、最初のリリースで新旧両方の引数を受け入れるようにします。
1. 同様に、ワーカーを削除する必要がある場合は、1つのリリースでスケジューリングを停止してから、次のリリースで削除します。こうすると既存のジョブを実行できます。
1. すべてのインスタンスがすべての中間バージョンにアップグレードされるわけではないことにご注意ください（ユーザーによってはX.1.0からX.10.0に移行したり、より大幅なアップグレードを試す可能性があります）。よって古いフォーマットの受け入れが困難でなければ、そうしてください。
1. **キャッシュした値**は、リリースをまたいで永続化される場合があります。キャッシュした値が返すタイプを変更する場合（たとえば文字列やnilから配列に）、同時にキャッシュキーを変更します。
1. **設定**の追加は[最後の手段](https://handbook.gitlab.com/handbook/product/product-principles/#convention-over-configuration)とすべきです。[GitLab Railsへの新しい設定の追加](architecture.md#adding-a-new-setting-in-gitlab-rails)を参照してください。
1. **ファイルシステムへのアクセス**は、[クラウドネイティブアーキテクチャ](architecture.md#adapting-existing-and-introducing-new-components)ではできません。実行する必要のあるファイルストレージに対して、オブジェクトストレージをサポートしていることを確認します。詳細については、[アップロードのドキュメント](uploads/_index.md)を参照してください。
### お客様にとって重要なマージリクエスト
マージリクエストは、それを行うとビジネスに大きなメリットがあるため、お客様が重要な優先事項と見なすこということから、利点が生まれます。
お客様にとって重要なマージリクエストの性質:
- 開発のシニアディレクター以上が、あるマージリクエストがお客様にとって極めて重要であるとの評価を承認する必要があります。あるいは2人の直属の部下が承認した場合も、承認として機能します。
- DRIは、`customer-critical-merge-request`ラベルをマージリクエストに付けます。
- お客様にとって重要なマージリクエストに関与するレビュアーとメンテナーは、この決定が下されたらすぐに関与する必要があります。
- お客様にとって重要なマージリクエストに関与する人の作業を優先して、彼らがそれに集中するために必要な時間を確保する必要があります。
- お客様にとって重要なマージリクエストに取り組む際は、GitLabの[価値観](https://handbook.gitlab.com/handbook/values/)とプロセスを遵守し、家族や友人を最優先して仕事を二の次とし、完了の定義、イテレーション、準備ができたらリリースすることに特に注意する必要があります。
- お客様にとって重要なマージリクエストでは、[技術的な決定を優先する](https://handbook.gitlab.com/handbook/engineering/development/principles/#prioritizing-technical-decisions)プロセスごとに、セキュリティを低下させたり、データ損失のリスクをもたらしたり、可用性を低下させたり、既存の機能を損なったりしないようにする必要があります。
- お客様にとって重要なリクエストについては、関与する人がたとえ[効率](https://handbook.gitlab.com/handbook/company/culture/all-remote/asynchronous/#evaluating-efficiency)を犠牲にする_場合がある_としても、マージまでの経過時間を短縮できると考えているのであれば、Zoom、Slackには同期して、さらにマージリクエストのコメントには非同期での調整を_検討_することを_推奨_しています。
- お客様にとって重要なマージリクエストをマージした後、将来のお客様にとって重要となるマージリクエストの頻度の低減を目的として、レトロスペクティブを完了する必要があります。
## パイプラインの失敗のトラブルシューティング
パイプラインが、実施したコード変更とは関係のない理由で失敗する場合があります。そういった事例の一部を、考えられる解決策とともに以下に示します。
レビューやヘルプを求めるには、パイプラインを通す必要はないことを常に覚えておいてください。パイプラインが通らず、その理由がわからない場合は、お気軽にチームに連絡するか、テキストとして`@gitlab-bot help`を使用してMRにコメントを残してMRコーチに支援を求めるか、`contribute`チャンネルで[コミュニティディスコード](https://discord.gg/gitlab)に連絡してください。
- **変更とは関係がないと思われる理由でテストに失敗した場合**: デフォルトブランチでも発生するかを確認します。その場合、「マスターの破損」が原因であるため、デフォルトブランチでの障害の修正を待つ必要があります。修正後にブランチをリベースするか、[マージした結果のパイプライン](../ci/pipelines/merged_results_pipelines.md)が有効になっていれば、単に別のパイプラインを実行します。
- **`danger-review` ジョブが失敗した場合**: MRに20を超えるコミットがあるか確認します。その場合は、コミット数が少なくなるようにリベースしてスカッシュするか、`danger-review`ジョブを再度実行します。一時的な障害が発生しただけかもしれません。
## 例
コードレビューの実施方法は、新しいコントリビューターを驚かせるかもしれません。何が期待されているかの理解に役立つコードレビューの例を次に示します。
**[「デザインに再利用するために`DiffNote`を変更」](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/13703): **改行に関する細かい点から、デザインのバージョンとは何か、特定のファイル（親と空白の`sha`と 空のツリー）の以前のバージョンがない場合にどのように比較するかについてまで、それにはすべてが含まれていました。
**[「複数行の提案をサポート」](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/25211)**:MR自体はFEとBEの間のコラボレーションで構成されており、レビュアーへの作成者のコメントを文書化しています。いくつかの細かい点、情報に関するいくつかの質問、そして最後にはセキュリティの脆弱性を記述しています。
**[「プロジェクトごとに複数のリポジトリを許可する」](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/10251)**: ZJは、これがおそらく影響を与える他のプロジェクト（workhorse）を参照して、一貫性を保つための改善点をいくつか提案しました。そしてJamesのコメントは、全体的なコード品質（委任の使用、`&.`などのタイプ）に役立ち、コードをより堅牢化しました。
**[「マージリクエストの複数の担当者をサポートする」](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/10161)**: コードベースの複数の部分に影響するMRでのコラボレーションの優良例。Nickは興味深いエッジケースを指摘し、James Lopezもインポート/エクスポート機能に関する懸念の提起に関与しました。
### クレジット
主に[`thoughtbot`コードレビューガイド](https://github.com/thoughtbot/guides/tree/main/code-review)に基づいています。

4
doc-locale/ja-jp/development/code_suggestions/_index.md Normal file
View File

@ -0,0 +1,4 @@
---
redirect_to: '../ai_features/code_suggestions.md'
remove_date: '2025-06-05'
---

6
doc-locale/ja-jp/development/contributing/_index.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: none
group: unassigned
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Contribute to GitLab development
---

6
doc-locale/ja-jp/development/contributing/design.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: none
group: unassigned
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Design and user interface changes
---

6
doc-locale/ja-jp/development/contributing/first_contribution/_index.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: none
group: unassigned
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: 'Tutorial: Make a GitLab contribution'
---

6
doc-locale/ja-jp/development/contributing/first_contribution/configure-dev-env-gdk-in-a-box.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: none
group: unassigned
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Configure GDK-in-a-box
---

6
doc-locale/ja-jp/development/contributing/first_contribution/configure-dev-env-gdk.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: none
group: unassigned
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Install the GDK development environment
---

6
doc-locale/ja-jp/development/contributing/first_contribution/configure-dev-env-gitpod.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: none
group: unassigned
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Configure the Gitpod development environment
---

6
doc-locale/ja-jp/development/contributing/first_contribution/contribute-gdk.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: none
group: unassigned
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Contribute code with GDK
---

6
doc-locale/ja-jp/development/contributing/first_contribution/contribute-gitpod.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: none
group: unassigned
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Contribute code with Gitpod
---

6
doc-locale/ja-jp/development/contributing/first_contribution/contribute-web-ide.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: none
group: unassigned
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Contribute code with the Web IDE
---

6
doc-locale/ja-jp/development/contributing/first_contribution/mr-review.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: none
group: unassigned
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Create a merge request
---

6
doc-locale/ja-jp/development/contributing/issue_workflow.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: none
group: unassigned
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Issues workflow
---

6
doc-locale/ja-jp/development/contributing/merge_request_coaches.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: none
group: unassigned
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: How GitLab Merge Request Coaches can help you
---

6
doc-locale/ja-jp/development/contributing/merge_request_workflow.md Normal file
View File

@ -0,0 +1,6 @@
---
stage: none
group: unassigned
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
title: Merge requests workflow
---

Some files were not shown because too many files have changed in this diff Show More