diff --git a/.rubocop.yml b/.rubocop.yml
index a92ab7129c9..2adbb1a270c 100644
--- a/.rubocop.yml
+++ b/.rubocop.yml
@@ -69,6 +69,11 @@ Rails:
     - 'tooling/danger/**/*'
     - 'rubocop/**/*'
 
+Rails/Date:
+  Exclude:
+    # See https://gitlab.com/gitlab-org/gitlab/-/issues/502580
+    - danger/database/Dangerfile
+
 RSpec:
   Language:
     Includes:
diff --git a/.rubocop_todo/lint/unused_method_argument.yml b/.rubocop_todo/lint/unused_method_argument.yml
index c4800ac7be7..0a6a0ed3381 100644
--- a/.rubocop_todo/lint/unused_method_argument.yml
+++ b/.rubocop_todo/lint/unused_method_argument.yml
@@ -370,7 +370,6 @@ Lint/UnusedMethodArgument:
     - 'lib/gitlab/database/each_database.rb'
     - 'lib/gitlab/database/load_balancing/connection_proxy.rb'
     - 'lib/gitlab/database/load_balancing/primary_host.rb'
-    - 'lib/gitlab/database/load_balancing/session.rb'
     - 'lib/gitlab/database/lock_writes_manager.rb'
     - 'lib/gitlab/database/migrations/instrumentation.rb'
     - 'lib/gitlab/database/migrations/lock_retries_helpers.rb'
diff --git a/.rubocop_todo/style/if_unless_modifier.yml b/.rubocop_todo/style/if_unless_modifier.yml
index b1273e54a51..0b9f598d444 100644
--- a/.rubocop_todo/style/if_unless_modifier.yml
+++ b/.rubocop_todo/style/if_unless_modifier.yml
@@ -224,7 +224,6 @@ Style/IfUnlessModifier:
     - 'config/initializers/validate_database_config.rb'
     - 'config/initializers_before_autoloader/002_sidekiq.rb'
     - 'config/routes.rb'
-    - 'danger/database/Dangerfile'
     - 'ee/app/controllers/admin/emails_controller.rb'
     - 'ee/app/controllers/admin/geo/application_controller.rb'
     - 'ee/app/controllers/admin/geo/settings_controller.rb'
diff --git a/.rubocop_todo/style/mutable_constant.yml b/.rubocop_todo/style/mutable_constant.yml
index c38c4357ec4..b9360631e0d 100644
--- a/.rubocop_todo/style/mutable_constant.yml
+++ b/.rubocop_todo/style/mutable_constant.yml
@@ -11,7 +11,6 @@ Style/MutableConstant:
     - 'app/services/packages/maven/metadata/append_package_file_service.rb'
     - 'app/workers/concerns/worker_context.rb'
     - 'danger/architecture/Dangerfile'
-    - 'danger/database/Dangerfile'
     - 'ee/app/services/elastic/indexing_control_service.rb'
     - 'ee/app/services/security/ingestion/tasks/ingest_vulnerability_statistics.rb'
     - 'ee/app/services/vulnerabilities/statistics/adjustment_service.rb'
diff --git a/.rubocop_todo/style/redundant_self.yml b/.rubocop_todo/style/redundant_self.yml
index 7e827feb1d4..6606f12e535 100644
--- a/.rubocop_todo/style/redundant_self.yml
+++ b/.rubocop_todo/style/redundant_self.yml
@@ -201,10 +201,6 @@ Style/RedundantSelf:
     - 'ee/lib/ee/gitlab/auth/ldap/sync/proxy.rb'
     - 'ee/lib/ee/gitlab/auth/ldap/sync/users.rb'
     - 'ee/lib/ee/gitlab/background_migration/delete_invalid_epic_issues.rb'
-    - 'ee/lib/elastic/latest/commit_config.rb'
-    - 'ee/lib/elastic/latest/issue_config.rb'
-    - 'ee/lib/elastic/latest/note_config.rb'
-    - 'ee/lib/elastic/migration.rb'
     - 'ee/lib/gem_extensions/elasticsearch/model/indexing/instance_methods.rb'
     - 'ee/lib/gitlab/analytics/cycle_analytics/summary/base_time.rb'
     - 'ee/lib/gitlab/auth/group_saml/response_check.rb'
diff --git a/GITLAB_KAS_VERSION b/GITLAB_KAS_VERSION
index d1b6f03cf9c..753af0e87dd 100644
--- a/GITLAB_KAS_VERSION
+++ b/GITLAB_KAS_VERSION
@@ -1 +1 @@
-fb36514b67173b5a16a386256a85203a0d14a76c
+ecf7544d81ceb3572d7b9afffb74c7389659caaa
diff --git a/danger/database/Dangerfile b/danger/database/Dangerfile
index b7f2151dcf9..ae2a37d68fe 100644
--- a/danger/database/Dangerfile
+++ b/danger/database/Dangerfile
@@ -2,7 +2,7 @@
 
 SCHEMA_NOT_UPDATED_MESSAGE_SHORT = "New %<migrations>s added but %<schema>s wasn't updated"
 
-SCHEMA_NOT_UPDATED_MESSAGE_FULL = <<~MSG
+SCHEMA_NOT_UPDATED_MESSAGE_FULL = <<~MSG.freeze
 **#{SCHEMA_NOT_UPDATED_MESSAGE_SHORT}**
 
 Usually, when adding new %<migrations>s, %<schema>s should be
@@ -25,7 +25,7 @@ DB_FILES_MESSAGE = <<~MSG
 The following files require a review from the Database team:
 MSG
 
-DB_REMOVE_MESSAGE = <<~MSG
+DB_REMOVE_MESSAGE = <<~MSG.freeze
 If you no longer require a database review, you can remove this suggestion
 by removing the ~database label and re-running the [`danger-review` job](#{ENV['CI_JOB_URL']}).
 MSG
@@ -91,9 +91,7 @@ if helper.mr_labels.include?('database') || database.changes.any?
     markdown(DB_REMOVE_MESSAGE)
   end
 
-  unless helper.has_scoped_label_with_scope?("database")
-    helper.labels_to_add << 'database::review pending'
-  end
+  helper.labels_to_add << 'database::review pending' unless helper.has_scoped_label_with_scope?("database")
 end
 
 cutoff = Date.today - 21 # Three weeks ago
diff --git a/db/docs/p_ci_build_trace_metadata.yml b/db/docs/p_ci_build_trace_metadata.yml
index 7048b25ba98..86b819c6c49 100644
--- a/db/docs/p_ci_build_trace_metadata.yml
+++ b/db/docs/p_ci_build_trace_metadata.yml
@@ -8,4 +8,13 @@ description: Routing table for ci_build_trace_metadata
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/162310
 milestone: '14.2'
 gitlab_schema: gitlab_ci
-sharding_key_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/458479
+desired_sharding_key:
+  project_id:
+    references: projects
+    backfill_via:
+      parent:
+        foreign_key: build_id
+        table: p_ci_builds
+        sharding_key: project_id
+        belongs_to: build
+        foreign_key_name: fk_rails_aebc78111f_p
diff --git a/doc/administration/operations/rails_console.md b/doc/administration/operations/rails_console.md
index 3b1da930937..f273b66e28e 100644
--- a/doc/administration/operations/rails_console.md
+++ b/doc/administration/operations/rails_console.md
@@ -448,7 +448,7 @@ We also see that the save operation triggered some other action -- in this case
 a background job to deliver an email notification. This is an example of an
 [Active Record callback](https://guides.rubyonrails.org/active_record_callbacks.html)
 -- code which is designated to run in response to events in the Active Record
-object life cycle. This is also why using the Rails console is preferred when
+object lifecycle. This is also why using the Rails console is preferred when
 direct changes to data is necessary as changes made via direct database queries
 do not trigger these callbacks.
 
diff --git a/doc/development/api_graphql_styleguide.md b/doc/development/api_graphql_styleguide.md
index ab0cf51587c..5fe118ab631 100644
--- a/doc/development/api_graphql_styleguide.md
+++ b/doc/development/api_graphql_styleguide.md
@@ -1233,7 +1233,7 @@ end
 
 While you can use the same resolver class in two different places,
 such as in two different fields where the same object is exposed,
-you should never re-use resolver objects directly. Resolvers have a complex life-cycle, with
+you should never re-use resolver objects directly. Resolvers have a complex lifecycle, with
 authorization, readiness and resolution orchestrated by the framework, and at
 each stage [lazy values](#laziness) can be returned to take advantage of batching
 opportunities. Never instantiate a resolver or a mutation in application code.
diff --git a/doc/development/application_slis/index.md b/doc/development/application_slis/index.md
index 489772766f6..13f05896fea 100644
--- a/doc/development/application_slis/index.md
+++ b/doc/development/application_slis/index.md
@@ -71,7 +71,7 @@ Gitlab::Metrics::Sli::Apdex.initialize_sli(:received_email, [
 ```
 
 Metrics must be initialized before they get scraped for the first time.
-This currently happens during the `on_master_start` [life-cycle event](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/cluster/lifecycle_events.rb).
+This currently happens during the `on_master_start` [lifecycle event](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/cluster/lifecycle_events.rb).
 Since this delays application readiness until metrics initialization returns, make sure the overhead
 this adds is understood and acceptable.
 
diff --git a/doc/development/database/insert_into_tables_in_batches.md b/doc/development/database/insert_into_tables_in_batches.md
index f2829c7d596..2377a5805df 100644
--- a/doc/development/database/insert_into_tables_in_batches.md
+++ b/doc/development/database/insert_into_tables_in_batches.md
@@ -119,7 +119,7 @@ MyModel.bulk_insert!(records, skip_duplicates: true)
 ### Requirements for safe bulk insertions
 
 Large parts of ActiveRecord's persistence API are built around the notion of callbacks. Many
-of these callbacks fire in response to model life cycle events such as `save` or `create`.
+of these callbacks fire in response to model lifecycle events such as `save` or `create`.
 These callbacks cannot be used with bulk insertions, since they are meant to be called for
 every instance that is saved or created. Since these events do not fire when
 records are inserted in bulk, we prevent their use.
diff --git a/doc/development/distributed_tracing.md b/doc/development/distributed_tracing.md
index c793ce69775..eb7260a9956 100644
--- a/doc/development/distributed_tracing.md
+++ b/doc/development/distributed_tracing.md
@@ -14,7 +14,7 @@ According to [Open Tracing](https://opentracing.io/docs/overview/what-is-tracing
 > monitor applications, especially those built using a microservices architecture. Distributed
 > tracing helps to pinpoint where failures occur and what causes poor performance.
 
-Distributed tracing is especially helpful in understanding the life cycle of a request as it passes
+Distributed tracing is especially helpful in understanding the lifecycle of a request as it passes
 through the different components of the GitLab application. At present, Workhorse, Rails, Sidekiq,
 and Gitaly support tracing instrumentation.
 
diff --git a/doc/development/fe_guide/getting_started.md b/doc/development/fe_guide/getting_started.md
index 95aaec53ca1..429ad749ec1 100644
--- a/doc/development/fe_guide/getting_started.md
+++ b/doc/development/fe_guide/getting_started.md
@@ -10,7 +10,7 @@ This page will guide you through the Frontend development process and show you w
 
 There are a lot of things to consider for a first merge request and it can feel overwhelming. The [Frontend onboarding course](onboarding_course/index.md) provides a 6-week structured curriculum to learn how to contribute to the GitLab frontend.
 
-## Development life cycle
+## Development lifecycle
 
 ### Step 1: Preparing the issue
 
diff --git a/doc/development/feature_flags/controls.md b/doc/development/feature_flags/controls.md
index 6f76d38030a..f8f8b78ab7a 100644
--- a/doc/development/feature_flags/controls.md
+++ b/doc/development/feature_flags/controls.md
@@ -477,7 +477,7 @@ and reduces confidence in our testing suite covering all possible combinations.
 Additionally, a feature flag overwritten in some of the environments can result
 in undefined and untested system behavior.
 
-`development` type feature flags should have a short life-cycle because their purpose
+`development` type feature flags should have a short lifecycle because their purpose
 is for rolling out a persistent change. `development` feature flags that are older
 than 2 milestones are reported to engineering managers. The
 [report tool](https://gitlab.com/gitlab-org/gitlab-feature-flag-alert) runs on a
diff --git a/doc/development/geo/proxying.md b/doc/development/geo/proxying.md
index 85520bbd91a..4ae833ad4cf 100644
--- a/doc/development/geo/proxying.md
+++ b/doc/development/geo/proxying.md
@@ -17,7 +17,7 @@ Proxying of Git over HTTP requests is handled by the [`gitlab-workhorse`](../../
 
 Proxying of Git over SSH traffic is handled by the [`gitlab-shell`](../../development/architecture.md#gitlab-shell) component, but the decision to proxy or not is handled by the Rails application, taking into account whether the request is push or pull, and whether the desired Git data is up-to-date.
 
-## Request life cycle
+## Request lifecycle
 
 ### Top-level view
 
diff --git a/doc/development/testing_guide/frontend_testing.md b/doc/development/testing_guide/frontend_testing.md
index 8eb29ded2ff..d0f8ba4039d 100644
--- a/doc/development/testing_guide/frontend_testing.md
+++ b/doc/development/testing_guide/frontend_testing.md
@@ -1218,7 +1218,7 @@ testAction(
 <!-- vale gitlab_base.Spelling = NO -->
 
 The Axios Utils mock module located in `spec/frontend/__helpers__/mocks/axios_utils.js` contains two helper methods for Jest tests that spawn HTTP requests.
-These are very useful if you don't have a handle to the request's Promise, for example when a Vue component does a request as part of its life cycle.
+These are very useful if you don't have a handle to the request's Promise, for example when a Vue component does a request as part of its lifecycle.
 
 <!-- vale gitlab_base.Spelling = YES -->
 
diff --git a/doc/install/openshift_and_gitlab/index.md b/doc/install/openshift_and_gitlab/index.md
index 4c769789e71..b73a7a67751 100644
--- a/doc/install/openshift_and_gitlab/index.md
+++ b/doc/install/openshift_and_gitlab/index.md
@@ -10,7 +10,7 @@ OpenShift - GitLab compatibility can be addressed in three different aspects. Th
 
 ## What is OpenShift
 
-OpenShift helps you to develop, deploy, and manage container-based applications. It provides you with a self-service platform to create, modify, and deploy applications on demand, thus enabling faster development and release life cycles.
+OpenShift helps you to develop, deploy, and manage container-based applications. It provides you with a self-service platform to create, modify, and deploy applications on demand, thus enabling faster development and release lifecycles.
 
 ## Use OpenShift to run GitLab self-managed
 
diff --git a/doc/security/hardening_nist_800_53.md b/doc/security/hardening_nist_800_53.md
index 7ae909b40e1..b0a88ff25db 100644
--- a/doc/security/hardening_nist_800_53.md
+++ b/doc/security/hardening_nist_800_53.md
@@ -43,7 +43,7 @@ GitLab is a [DevSecOps platform](../devsecops.md) that
 integrates security throughout the development lifecycle.
 At its core, you can use GitLab to address a wide range of controls within the SA control family.
 
-#### System development life cycle
+#### System development lifecycle
 
 You can use GitLab to meet the core of this requirement. GitLab provides
 a platform where work can be
diff --git a/doc/user/application_security/dast/index.md b/doc/user/application_security/dast/index.md
index 5a07a1cfa7d..da671dbd9a4 100644
--- a/doc/user/application_security/dast/index.md
+++ b/doc/user/application_security/dast/index.md
@@ -26,7 +26,7 @@ other security tools cannot detect.
 DAST is completely language agnostic and examines your application from the outside in. With a
 running application in a test environment, DAST scans can be automated in a CI/CD pipeline,
 automated on a schedule, or run independently by using on-demand scans. Using DAST during the
-software development life cycle enables teams to uncover vulnerabilities before their applications
+software development lifecycle enables teams to uncover vulnerabilities before their applications
 are in production. DAST is a foundational component of software security and should be used in
 tandem with SAST, dependency and license scanning, and secret detection, to provide a comprehensive
 security assessment of your applications.
diff --git a/doc/user/application_security/dast/on-demand_scan.md b/doc/user/application_security/dast/on-demand_scan.md
index 4ba68d01ce9..9442b72f308 100644
--- a/doc/user/application_security/dast/on-demand_scan.md
+++ b/doc/user/application_security/dast/on-demand_scan.md
@@ -20,7 +20,7 @@ Only run DAST scans against a test server.
 > - Runner tags selection [enabled on GitLab.com and self-managed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111499) in GitLab 16.3.
 > - Browser based on-demand DAST scans available from GitLab 17.0 since [proxy-based DAST was removed in the same version](../../../update/deprecations.md#proxy-based-dast-deprecated).
 
-An on-demand DAST scan runs outside the DevOps life cycle. Changes in your repository don't trigger
+An on-demand DAST scan runs outside the DevOps lifecycle. Changes in your repository don't trigger
 the scan. You must either start it manually, or schedule it to run. For on-demand DAST scans,
 a [site profile](#site-profile) defines **what** is to be scanned, and a
 [scanner profile](#scanner-profile) defines **how** the application is to be scanned.
diff --git a/doc/user/application_security/dependency_scanning/dependency_scanning_sbom/index.md b/doc/user/application_security/dependency_scanning/dependency_scanning_sbom/index.md
index 7ad32895ae1..61b09041f67 100644
--- a/doc/user/application_security/dependency_scanning/dependency_scanning_sbom/index.md
+++ b/doc/user/application_security/dependency_scanning/dependency_scanning_sbom/index.md
@@ -29,7 +29,7 @@ aspects of inspecting the items your code uses. These items typically include ap
 dependencies that are almost always imported from external sources, rather than sourced from items
 you wrote yourself.
 
-Dependency scanning can run in the development phase of your application's life cycle. Every time a
+Dependency scanning can run in the development phase of your application's lifecycle. Every time a
 pipeline produces an SBOM report, security findings are identified and compared between the source
 and target branches. Findings and their severity are listed in the merge request, enabling you to
 proactively address the risk to your application, before the code change is committed. Security
diff --git a/doc/user/application_security/dependency_scanning/index.md b/doc/user/application_security/dependency_scanning/index.md
index 210611c440c..38480f4ce22 100644
--- a/doc/user/application_security/dependency_scanning/index.md
+++ b/doc/user/application_security/dependency_scanning/index.md
@@ -55,7 +55,7 @@ aspects of inspecting the items your code uses. These items typically include ap
 dependencies that are almost always imported from external sources, rather than sourced from items
 you wrote yourself.
 
-Dependency Scanning can run in the development phase of your application's life cycle. Every time a
+Dependency Scanning can run in the development phase of your application's lifecycle. Every time a
 pipeline runs, vulnerabilities are identified and compared between the source and target branches.
 Vulnerabilities and their severity are listed in the merge request, enabling you to proactively
 address the risk to your application, before the code change is committed.
diff --git a/doc/user/application_security/terminology/index.md b/doc/user/application_security/terminology/index.md
index 689a375365e..5e311aec1bf 100644
--- a/doc/user/application_security/terminology/index.md
+++ b/doc/user/application_security/terminology/index.md
@@ -346,7 +346,7 @@ When a [report finding](#report-finding) is stored to the database, it becomes a
 
 ## Vulnerability tracking
 
-Deals with the responsibility of matching findings across scans so that a finding's life cycle can
+Deals with the responsibility of matching findings across scans so that a finding's lifecycle can
 be understood. Engineers and security teams use this information to decide whether to merge code
 changes, and to see unresolved findings and when they were introduced.
 
diff --git a/doc/user/project/system_notes.md b/doc/user/project/system_notes.md
index 2df06e47819..966a272dae4 100644
--- a/doc/user/project/system_notes.md
+++ b/doc/user/project/system_notes.md
@@ -12,7 +12,7 @@ DETAILS:
 **Offering:** GitLab.com, Self-managed, GitLab Dedicated
 
 System notes are short descriptions that help you understand the history of events
-that occur during the life cycle of a GitLab object, such as:
+that occur during the lifecycle of a GitLab object, such as:
 
 - [Alerts](../../operations/incident_management/alerts.md).
 - [Designs](issues/design_management.md).
diff --git a/lib/gitlab/database/load_balancing/session.rb b/lib/gitlab/database/load_balancing/session.rb
index d6c7cf94fb2..c95fe1f98ee 100644
--- a/lib/gitlab/database/load_balancing/session.rb
+++ b/lib/gitlab/database/load_balancing/session.rb
@@ -19,8 +19,8 @@ module Gitlab
           RequestStore.delete(CACHE_KEY)
         end
 
-        def self.without_sticky_writes(&block)
-          current.ignore_writes(&block)
+        def self.without_sticky_writes(&)
+          current.ignore_writes(&)
         end
 
         def initialize
@@ -41,7 +41,7 @@ module Gitlab
           @use_primary = true
         end
 
-        def use_primary(&blk)
+        def use_primary
           used_primary = @use_primary
           @use_primary = true
           yield
@@ -49,7 +49,7 @@ module Gitlab
           @use_primary = used_primary || @performed_write
         end
 
-        def ignore_writes(&block)
+        def ignore_writes
           @ignore_writes = true
 
           yield
@@ -67,7 +67,7 @@ module Gitlab
         #
         # Write and ambiguous queries inside this block are still handled by
         # the primary.
-        def use_replicas_for_read_queries(&blk)
+        def use_replicas_for_read_queries
           previous_flag = @use_replicas_for_read_queries
           @use_replicas_for_read_queries = true
           yield
@@ -90,7 +90,7 @@ module Gitlab
         # - If the queries are about to write
         # - The current session already performed writes
         # - It prefers to use primary, aka, use_primary or use_primary! were called
-        def fallback_to_replicas_for_ambiguous_queries(&blk)
+        def fallback_to_replicas_for_ambiguous_queries
           previous_flag = @fallback_to_replicas_for_ambiguous_queries
           @fallback_to_replicas_for_ambiguous_queries = true
           yield