diff options
Diffstat (limited to 'doc/development')
| -rw-r--r-- | doc/development/application_slis/index.md | 2 | ||||
| -rw-r--r-- | doc/development/backend/ruby_style_guide.md | 2 | ||||
| -rw-r--r-- | doc/development/database/loose_foreign_keys.md | 2 | ||||
| -rw-r--r-- | doc/development/feature_flags/controls.md | 24 | ||||
| -rw-r--r-- | doc/development/merge_request_performance_guidelines.md | 2 | ||||
| -rw-r--r-- | doc/development/performance.md | 4 | ||||
| -rw-r--r-- | doc/development/rails_update.md | 2 | ||||
| -rw-r--r-- | doc/development/ruby_upgrade.md | 4 | ||||
| -rw-r--r-- | doc/development/stage_group_dashboards.md | 4 | ||||
| -rw-r--r-- | doc/development/testing_guide/best_practices.md | 6 | ||||
| -rw-r--r-- | doc/development/testing_guide/review_apps.md | 1 |
11 files changed, 27 insertions, 26 deletions
diff --git a/doc/development/application_slis/index.md b/doc/development/application_slis/index.md index 5bc6fffdb48..87c0bcfede5 100644 --- a/doc/development/application_slis/index.md +++ b/doc/development/application_slis/index.md @@ -180,7 +180,7 @@ alerts about the SLI in specified Slack channels. For more information, read the [alert routing documentation](https://gitlab.com/gitlab-com/runbooks/-/blob/master/docs/uncategorized/alert-routing.md). In [this project](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/614) we are extending this so alerts for SLIs with a `feature_category` -label in the souce metrics can also be routed. +label in the source metrics can also be routed. For any question, please don't hesitate to create an issue in [the Scalability issue tracker](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues) diff --git a/doc/development/backend/ruby_style_guide.md b/doc/development/backend/ruby_style_guide.md index 461bb9aafde..419db628b0d 100644 --- a/doc/development/backend/ruby_style_guide.md +++ b/doc/development/backend/ruby_style_guide.md @@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w This is a GitLab-specific style guide for Ruby code. -Generally, if a style is not covered by [existing rubocop rules or styleguides](../contributing/style_guides.md#ruby-rails-rspec), it shouldn't be a blocker. +Generally, if a style is not covered by [existing Rubocop rules or style guides](../contributing/style_guides.md#ruby-rails-rspec), it shouldn't be a blocker. Before adding a new cop to enforce a given style, make sure to discuss it with your team. When the style is approved by a backend EM or by a BE staff eng, add a new section to this page to document the new rule. For every new guideline, add it in a new section and link the discussion from the section's diff --git a/doc/development/database/loose_foreign_keys.md b/doc/development/database/loose_foreign_keys.md index fb84a004f23..19f5ccebf74 100644 --- a/doc/development/database/loose_foreign_keys.md +++ b/doc/development/database/loose_foreign_keys.md @@ -214,5 +214,5 @@ permission checks. We considered using these Rails features as an alternative to foreign keys but there are several problems which include: 1. These run on a different connection in the context of a transaction [which we do not allow](multiple_databases.md#removing-cross-database-transactions). -1. These can lead to severe performance degredation as we load all records from PostgreSQL, loop over them in Ruby, and call individual `DELETE` queries. +1. These can lead to severe performance degradation as we load all records from PostgreSQL, loop over them in Ruby, and call individual `DELETE` queries. 1. These can miss data as they only cover the case when the `destroy` method is called directly on the model. There are other cases including `delete_all` and cascading deletes from another parent table that could mean these are missed. diff --git a/doc/development/feature_flags/controls.md b/doc/development/feature_flags/controls.md index abb100c659e..4843b58c3fd 100644 --- a/doc/development/feature_flags/controls.md +++ b/doc/development/feature_flags/controls.md @@ -12,7 +12,8 @@ info: "See the Technical Writers assigned to Development Guidelines: https://abo To be able to turn on/off features behind feature flags in any of the GitLab Inc. provided environments such as staging and production, you need to have access to the [ChatOps](../chatops_on_gitlabcom.md) bot. The ChatOps bot -is currently running on the ops instance, which is different from <https://gitlab.com> or <https://dev.gitlab.org>. +is currently running on the ops instance, which is different from +[GitLab.com](https://gitlab.com) or [`dev.gitlab.org`](https://dev.gitlab.org). Follow the ChatOps document to [request access](../chatops_on_gitlabcom.md#requesting-access). @@ -35,12 +36,12 @@ This allows you to separate rolling out a feature from a deploy, making it easier to measure the impact of both separately. The GitLab feature library (using -[Flipper](https://github.com/jnunemaker/flipper), and covered in the [Feature -Flags process](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/) guide) supports rolling out changes to a percentage of +[Flipper](https://github.com/jnunemaker/flipper), and covered in the +[Feature Flags process](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/) guide) supports rolling out changes to a percentage of time to users. This in turn can be controlled using [GitLab ChatOps](../../ci/chatops/index.md). -For an up to date list of feature flag commands please see [the source -code](https://gitlab.com/gitlab-com/chatops/blob/master/lib/chatops/commands/feature.rb). +For an up to date list of feature flag commands please see +[the source code](https://gitlab.com/gitlab-com/chatops/blob/master/lib/chatops/commands/feature.rb). Note that all the examples in that file must be preceded by `/chatops run`. @@ -50,15 +51,16 @@ change feature flags or you do not [have access](#access). ### Enabling a feature for pre-production testing -As a first step in a feature rollout, you should enable the feature on <https://about.staging.gitlab.com> -and <https://dev.gitlab.org>. +As a first step in a feature rollout, you should enable the feature on +[`about.staging.gitlab.com`](https://about.staging.gitlab.com) +and [`dev.gitlab.org`](https://dev.gitlab.org). These two environments have different scopes. `dev.gitlab.org` is a production CE environment that has internal GitLab Inc. traffic and is used for some development and other related work. `staging.gitlab.com` has a smaller subset of GitLab.com database and repositories and does not have regular traffic. Staging is an EE instance and can give you -a (very) rough estimate of how your feature will look/behave on GitLab.com. +a (very) rough estimate of how your feature will look and behave on GitLab.com. Both of these instances are connected to Sentry so make sure you check the projects there for any exceptions while testing your feature after enabling the feature flag. @@ -97,7 +99,7 @@ Guidelines: #### Process When enabling a feature flag rollout, the system will automatically block the -chatops command from succeeding if there are active `"severity::1"` or `~"severity::2"` +ChatOps command from succeeding if there are active `"severity::1"` or `~"severity::2"` incidents or in-progress change issues, for example: ```shell @@ -227,7 +229,7 @@ Note, that if an actor based feature gate is present, switching the `default_enabled` attribute of the YAML definition from `false` to `true` will not have any effect. The feature gate must be deleted first. -For example, a feature flag is set via chatops: +For example, a feature flag is set via ChatOps: ```shell /chatops run feature set --project=gitlab-org/gitlab some_feature true @@ -265,7 +267,7 @@ To disable a feature flag that has been enabled for a specific project you can r You cannot selectively disable feature flags for a specific project/group/user without applying a [specific method of implementing](index.md#selectively-disable-by-actor) the feature flags. -If a feature flag is disabled via chatops, that will take precedence over the `default_enabled` value in the YML. In other words, you could have a feature enabled for on-premise installations but not for GitLab.com. +If a feature flag is disabled via ChatOps, that will take precedence over the `default_enabled` value in the YML. In other words, you could have a feature enabled for on-premise installations but not for GitLab.com. ### Feature flag change logging diff --git a/doc/development/merge_request_performance_guidelines.md b/doc/development/merge_request_performance_guidelines.md index 74b1d5680b0..69e9f7d16e3 100644 --- a/doc/development/merge_request_performance_guidelines.md +++ b/doc/development/merge_request_performance_guidelines.md @@ -205,7 +205,7 @@ Keeping the old behavior requires marking CTEs with the keyword `MATERIALIZED`. When building CTE statements, use the `Gitlab::SQL::CTE` class [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/56976) in GitLab 13.11. By default, this `Gitlab::SQL::CTE` class forces materialization through adding the `MATERIALIZED` keyword for PostgreSQL 12 and higher. `Gitlab::SQL::CTE` automatically omits materialization when PostgreSQL 11 is running -(this behavior is implemented using a custom arel node `Gitlab::Database::AsWithMaterialized` under the surface). +(this behavior is implemented using a custom Arel node `Gitlab::Database::AsWithMaterialized` under the surface). WARNING: We plan to drop the support for PostgreSQL 11. Upgrading to GitLab 14.0 requires PostgreSQL 12 or higher. diff --git a/doc/development/performance.md b/doc/development/performance.md index e59f7fb154b..b5294c8359d 100644 --- a/doc/development/performance.md +++ b/doc/development/performance.md @@ -365,7 +365,7 @@ This patch is available by default for [GCK](https://gitlab.com/gitlab-org/gitlab-compose-kit/-/merge_requests/149) and can additionally be enabled for [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/doc/advanced.md#apply-custom-patches-for-ruby). -This patch provides the following metrics that make it easier to understand efficiency of memory use for a given codepath: +This patch provides the following metrics that make it easier to understand efficiency of memory use for a given code path: - `mem_total_bytes`: the number of bytes consumed both due to new objects being allocated into existing object slots plus additional memory allocated for large objects (that is, `mem_bytes + slot_size * mem_objects`). @@ -384,7 +384,7 @@ and `100M mem_bytes`. You can view the current usage on [GitLab.com](https://log There are two ways of measuring your own code: 1. Review `api_json.log`, `development_json.log`, `sidekiq.log` that includes memory allocation counters. -1. Use `Gitlab::Memory::Instrumentation.with_memory_allocations` for a given codeblock and log it. +1. Use `Gitlab::Memory::Instrumentation.with_memory_allocations` for a given code block and log it. 1. Use [Measuring module](service_measurement.md) ```json diff --git a/doc/development/rails_update.md b/doc/development/rails_update.md index f25d68a8900..1a30e606c17 100644 --- a/doc/development/rails_update.md +++ b/doc/development/rails_update.md @@ -71,7 +71,7 @@ To efficiently and quickly find which Rails change caused the spec failure you c gem 'rails', ENV['RAILS_VERSION'], path: ENV['RAILS_FOLDER'] ``` -1. Set the `RAILS_FOLDER` env variable with the folder you cloned Rails into: +1. Set the `RAILS_FOLDER` environment variable with the folder you cloned Rails into: ```shell export RAILS_FOLDER="<GDK_FOLDER>/rails" diff --git a/doc/development/ruby_upgrade.md b/doc/development/ruby_upgrade.md index 064cb8daf98..2102a256645 100644 --- a/doc/development/ruby_upgrade.md +++ b/doc/development/ruby_upgrade.md @@ -190,7 +190,7 @@ via `gdk update`. This pause is a good time to assess the risk of this upgrade for GitLab SaaS. For Ruby upgrades that are high risk, such as major version upgrades, it is recommended to coordinate the changes with the infrastructure team through a [change management request](https://about.gitlab.com/handbook/engineering/infrastructure/change-management/). -Create this issue early to give everyone enough time to schedule and prepare changes. +Create this issue early to give everyone enough time to schedule and prepare changes. ### Make it the default Ruby @@ -205,7 +205,7 @@ in that repository. This change is only necessary when the minor or major versio ([example](https://gitlab.com/gitlab-org/gitlab-compose-kit/-/merge_requests/176).) As mentioned above, if the impact of the Ruby upgrade on SaaS availability is uncertain, it is -prudent to skip this step until you have verified that it runs smootly in production via a staged +prudent to skip this step until you have verified that it runs smoothly in production via a staged rollout. In this case, go to the next step first, and then, after the verification period has passed, promote the new Ruby to be the new default. diff --git a/doc/development/stage_group_dashboards.md b/doc/development/stage_group_dashboards.md index a887558e473..88e9141574e 100644 --- a/doc/development/stage_group_dashboards.md +++ b/doc/development/stage_group_dashboards.md @@ -60,8 +60,8 @@ component can have 2 indicators: We're working on making this target configurable per endpoint in [this project](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/525). Learn - how to [customize the request - apdex](application_slis/rails_request_apdex.md), this new apdex + how to + [customize the request Apdex](application_slis/rails_request_apdex.md), this new Apdex measurement is not yet part of the error budget. For Sidekiq job execution, the threshold depends on the [job diff --git a/doc/development/testing_guide/best_practices.md b/doc/development/testing_guide/best_practices.md index fab75581855..0f768a51b66 100644 --- a/doc/development/testing_guide/best_practices.md +++ b/doc/development/testing_guide/best_practices.md @@ -964,7 +964,7 @@ creates and deletes indices between examples to ensure a clean index, so that th for polluting the tests with nonessential data. Most tests for Elasticsearch logic relate to: -- Creating data in Postgres and waiting for it to be indexed in Elasticsearch. +- Creating data in PostgreSQL and waiting for it to be indexed in Elasticsearch. - Searching for that data. - Ensuring that the test gives the expected result. @@ -980,7 +980,7 @@ You do NOT need to add `:clean_gitlab_redis_shared_state` manually. Specs using Elasticsearch require that you: -- Create data in Postgres and then index it into Elasticsearch. +- Create data in PostgreSQL and then index it into Elasticsearch. - Enable Application Settings for Elasticsearch (which is disabled by default). To do so, use: @@ -994,7 +994,7 @@ end Additionally, you can use the `ensure_elasticsearch_index!` method to overcome the asynchronous nature of Elasticsearch. It uses the [Elasticsearch Refresh API](https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-refresh.html#refresh-api-desc) to make sure all operations performed on an index since the last refresh are available for search. This method is typically -called after loading data into Postgres to ensure the data is indexed and searchable. +called after loading data into PostgreSQL to ensure the data is indexed and searchable. #### Test Snowplow events diff --git a/doc/development/testing_guide/review_apps.md b/doc/development/testing_guide/review_apps.md index cfdb3ad0d62..c948b906ce0 100644 --- a/doc/development/testing_guide/review_apps.md +++ b/doc/development/testing_guide/review_apps.md @@ -15,7 +15,6 @@ For any of the following scenarios, the `start-review-app-pipeline` job would be - for merge requests with CI config changes - for merge requests with frontend changes - for merge requests with QA changes -- for scheduled pipelines - the MR has the `pipeline:run-review-app` label set ## QA runs on Review Apps |