Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
555b877303
commit
132aeb2a72
|
|
@ -332,6 +332,15 @@
|
|||
PG_VERSION: "15"
|
||||
REDIS_VERSION: "7.0"
|
||||
|
||||
.use-pg16:
|
||||
extends:
|
||||
- .pg-base-variables
|
||||
services:
|
||||
- !reference [.db-services-with-auto-explain, services]
|
||||
variables:
|
||||
PG_VERSION: "16"
|
||||
REDIS_VERSION: "7.0"
|
||||
|
||||
.es7-services:
|
||||
services:
|
||||
- !reference [.zoekt-services, services]
|
||||
|
|
@ -362,6 +371,14 @@
|
|||
- !reference [.db-services-with-auto-explain, services]
|
||||
- !reference [.es7-services, services]
|
||||
|
||||
.use-pg16-es7-ee:
|
||||
extends:
|
||||
- .use-pg16
|
||||
- .zoekt-variables
|
||||
services:
|
||||
- !reference [.db-services-with-auto-explain, services]
|
||||
- !reference [.es7-services, services]
|
||||
|
||||
.es8-services:
|
||||
services:
|
||||
- !reference [.zoekt-services, services]
|
||||
|
|
@ -400,6 +417,15 @@
|
|||
- !reference [.db-services-with-auto-explain, services]
|
||||
- !reference [.es8-services, services]
|
||||
|
||||
.use-pg16-es8-ee:
|
||||
extends:
|
||||
- .use-pg16
|
||||
- .zoekt-variables
|
||||
- .es8-variables
|
||||
services:
|
||||
- !reference [.db-services-with-auto-explain, services]
|
||||
- !reference [.es8-services, services]
|
||||
|
||||
.os1-services:
|
||||
services:
|
||||
- !reference [.zoekt-services, services]
|
||||
|
|
@ -431,6 +457,14 @@
|
|||
- !reference [.db-services-with-auto-explain, services]
|
||||
- !reference [.os1-services, services]
|
||||
|
||||
.use-pg16-opensearch1-ee:
|
||||
extends:
|
||||
- .use-pg16
|
||||
- .zoekt-variables
|
||||
services:
|
||||
- !reference [.db-services-with-auto-explain, services]
|
||||
- !reference [.os1-services, services]
|
||||
|
||||
.os2-services:
|
||||
services:
|
||||
- !reference [.zoekt-services, services]
|
||||
|
|
@ -462,6 +496,14 @@
|
|||
- !reference [.db-services-with-auto-explain, services]
|
||||
- !reference [.os2-services, services]
|
||||
|
||||
.use-pg16-opensearch2-ee:
|
||||
extends:
|
||||
- .use-pg16
|
||||
- .zoekt-variables
|
||||
services:
|
||||
- !reference [.db-services-with-auto-explain, services]
|
||||
- !reference [.os2-services, services]
|
||||
|
||||
.use-pg14-clickhouse23:
|
||||
extends: .use-pg14
|
||||
services:
|
||||
|
|
|
|||
|
|
@ -952,6 +952,39 @@ rspec system pg15:
|
|||
- .rspec-base-pg15
|
||||
- .rails:rules:default-branch-schedule-nightly--code-backstage
|
||||
- .rspec-system-parallel
|
||||
|
||||
# PG16
|
||||
rspec migration pg16:
|
||||
extends:
|
||||
- .rspec-base-pg16
|
||||
- .rspec-base-migration
|
||||
- .rails:rules:default-branch-schedule-nightly--code-backstage
|
||||
- .rspec-migration-parallel
|
||||
|
||||
rspec background_migration pg16:
|
||||
extends:
|
||||
- .rspec-base-pg16
|
||||
- .rspec-base-migration
|
||||
- .rails:rules:default-branch-schedule-nightly--code-backstage
|
||||
- .rspec-background-migration-parallel
|
||||
|
||||
rspec unit pg16:
|
||||
extends:
|
||||
- .rspec-base-pg16
|
||||
- .rails:rules:default-branch-schedule-nightly--code-backstage
|
||||
- .rspec-unit-parallel
|
||||
|
||||
rspec integration pg16:
|
||||
extends:
|
||||
- .rspec-base-pg16
|
||||
- .rails:rules:default-branch-schedule-nightly--code-backstage
|
||||
- .rspec-integration-parallel
|
||||
|
||||
rspec system pg16:
|
||||
extends:
|
||||
- .rspec-base-pg16
|
||||
- .rails:rules:default-branch-schedule-nightly--code-backstage
|
||||
- .rspec-system-parallel
|
||||
# EE/FOSS: default branch nightly scheduled jobs #
|
||||
##########################################
|
||||
|
||||
|
|
@ -1109,6 +1142,90 @@ rspec-ee system pg15 es8:
|
|||
extends:
|
||||
- .rspec-ee-base-pg15-es8
|
||||
- .rspec-ee-system-parallel
|
||||
|
||||
# PG16
|
||||
rspec-ee unit pg16 opensearch1:
|
||||
extends:
|
||||
- .rspec-ee-base-pg16-opensearch1
|
||||
- .rspec-ee-unit-parallel
|
||||
- .rails:rules:default-branch-schedule-nightly--code-backstage-ee-only
|
||||
|
||||
rspec-ee unit pg16 opensearch2:
|
||||
extends:
|
||||
- .rspec-ee-base-pg16-opensearch2
|
||||
- .rspec-ee-unit-parallel
|
||||
- .rails:rules:default-branch-schedule-nightly--code-backstage-ee-only
|
||||
|
||||
rspec-ee integration pg16 opensearch1:
|
||||
extends:
|
||||
- .rspec-ee-base-pg16-opensearch1
|
||||
- .rspec-ee-integration-parallel
|
||||
- .rails:rules:default-branch-schedule-nightly--code-backstage-ee-only
|
||||
|
||||
rspec-ee integration pg16 opensearch2:
|
||||
extends:
|
||||
- .rspec-ee-base-pg16-opensearch2
|
||||
- .rspec-ee-integration-parallel
|
||||
- .rails:rules:default-branch-schedule-nightly--code-backstage-ee-only
|
||||
|
||||
rspec-ee system pg16 opensearch1:
|
||||
extends:
|
||||
- .rspec-ee-base-pg16-opensearch1
|
||||
- .rspec-ee-system-parallel
|
||||
- .rails:rules:default-branch-schedule-nightly--code-backstage-ee-only
|
||||
|
||||
rspec-ee system pg16 opensearch2:
|
||||
extends:
|
||||
- .rspec-ee-base-pg16-opensearch2
|
||||
- .rspec-ee-system-parallel
|
||||
- .rails:rules:default-branch-schedule-nightly--code-backstage-ee-only
|
||||
|
||||
rspec-ee migration pg16:
|
||||
extends:
|
||||
- .rspec-ee-base-pg16
|
||||
- .rspec-base-migration
|
||||
- .rails:rules:default-branch-schedule-nightly--code-backstage-ee-only
|
||||
- .rspec-ee-migration-parallel
|
||||
|
||||
rspec-ee background_migration pg16:
|
||||
extends:
|
||||
- .rspec-ee-base-pg16
|
||||
- .rspec-base-migration
|
||||
- .rails:rules:default-branch-schedule-nightly--code-backstage-ee-only
|
||||
- .rspec-ee-background-migration-parallel
|
||||
|
||||
rspec-ee unit pg16:
|
||||
extends:
|
||||
- .rspec-ee-base-pg16
|
||||
- .rails:rules:default-branch-schedule-nightly--code-backstage-ee-only
|
||||
- .rspec-ee-unit-parallel
|
||||
|
||||
rspec-ee unit pg16 es8:
|
||||
extends:
|
||||
- .rspec-ee-base-pg16-es8
|
||||
- .rspec-ee-unit-parallel
|
||||
|
||||
rspec-ee integration pg16:
|
||||
extends:
|
||||
- .rspec-ee-base-pg16
|
||||
- .rails:rules:default-branch-schedule-nightly--code-backstage-ee-only
|
||||
- .rspec-ee-integration-parallel
|
||||
|
||||
rspec-ee integration pg16 es8:
|
||||
extends:
|
||||
- .rspec-ee-base-pg16-es8
|
||||
- .rspec-ee-integration-parallel
|
||||
|
||||
rspec-ee system pg16:
|
||||
extends:
|
||||
- .rspec-ee-base-pg16
|
||||
- .rails:rules:default-branch-schedule-nightly--code-backstage-ee-only
|
||||
- .rspec-ee-system-parallel
|
||||
|
||||
rspec-ee system pg16 es8:
|
||||
extends:
|
||||
- .rspec-ee-base-pg16-es8
|
||||
- .rspec-ee-system-parallel
|
||||
# EE: default branch nightly scheduled jobs #
|
||||
#####################################
|
||||
|
||||
|
|
|
|||
|
|
@ -187,6 +187,11 @@ include:
|
|||
- .rspec-base
|
||||
- .use-pg15
|
||||
|
||||
.rspec-base-pg16:
|
||||
extends:
|
||||
- .rspec-base
|
||||
- .use-pg16
|
||||
|
||||
.rspec-ee-base-pg13:
|
||||
extends:
|
||||
- .rspec-base
|
||||
|
|
@ -256,6 +261,29 @@ include:
|
|||
- .use-pg15-opensearch2-ee
|
||||
- .rails:rules:run-search-tests
|
||||
|
||||
.rspec-ee-base-pg16:
|
||||
extends:
|
||||
- .rspec-base
|
||||
- .use-pg16-es7-ee
|
||||
|
||||
.rspec-ee-base-pg16-es8:
|
||||
extends:
|
||||
- .rspec-base
|
||||
- .use-pg16-es8-ee
|
||||
- .rails:rules:run-search-tests
|
||||
|
||||
.rspec-ee-base-pg16-opensearch1:
|
||||
extends:
|
||||
- .rspec-base
|
||||
- .use-pg16-opensearch1-ee
|
||||
- .rails:rules:run-search-tests
|
||||
|
||||
.rspec-ee-base-pg16-opensearch2:
|
||||
extends:
|
||||
- .rspec-base
|
||||
- .use-pg16-opensearch2-ee
|
||||
- .rails:rules:run-search-tests
|
||||
|
||||
.db-job-base:
|
||||
extends:
|
||||
- .rails-job-base
|
||||
|
|
|
|||
|
|
@ -219,7 +219,7 @@ templates-shellcheck:
|
|||
- .default-before_script
|
||||
- .default-retry
|
||||
- .ruby-cache
|
||||
- .use-pg15
|
||||
- .use-pg16
|
||||
stage: lint
|
||||
needs:
|
||||
- setup-test-env
|
||||
|
|
|
|||
2
Gemfile
2
Gemfile
|
|
@ -522,7 +522,7 @@ group :test do
|
|||
# Moved in `test` because https://gitlab.com/gitlab-org/gitlab/-/issues/217527
|
||||
gem 'derailed_benchmarks', require: false # rubocop:todo Gemfile/MissingFeatureCategory
|
||||
|
||||
gem 'gitlab_quality-test_tooling', '~> 1.14.2', require: false, feature_category: :tooling
|
||||
gem 'gitlab_quality-test_tooling', '~> 1.15.0', require: false, feature_category: :tooling
|
||||
end
|
||||
|
||||
gem 'octokit', '~> 8.0', feature_category: :importers
|
||||
|
|
|
|||
|
|
@ -227,7 +227,7 @@
|
|||
{"name":"gitlab-styles","version":"11.0.0","platform":"ruby","checksum":"0dd8ec066ce9955ac51d3616c6bfded30f75bb526f39ff392ece6f43d5b9406b"},
|
||||
{"name":"gitlab_chronic_duration","version":"0.12.0","platform":"ruby","checksum":"0d766944d415b5c831f176871ee8625783fc0c5bfbef2d79a3a616f207ffc16d"},
|
||||
{"name":"gitlab_omniauth-ldap","version":"2.2.0","platform":"ruby","checksum":"bb4d20acb3b123ed654a8f6a47d3fac673ece7ed0b6992edb92dca14bad2838c"},
|
||||
{"name":"gitlab_quality-test_tooling","version":"1.14.2","platform":"ruby","checksum":"9ee343328d5e755b54d97729adc5a743abd83b05e9b28d9bbbe74f393b6cf658"},
|
||||
{"name":"gitlab_quality-test_tooling","version":"1.15.0","platform":"ruby","checksum":"33416dce2d6a686ea95643eb650a249e94f696731e7f7c5bc552b369b2ba0bb5"},
|
||||
{"name":"globalid","version":"1.1.0","platform":"ruby","checksum":"b337e1746f0c8cb0a6c918234b03a1ddeb4966206ce288fbb57779f59b2d154f"},
|
||||
{"name":"gon","version":"6.4.0","platform":"ruby","checksum":"e3a618d659392890f1aa7db420f17c75fd7d35aeb5f8fe003697d02c4b88d2f0"},
|
||||
{"name":"google-apis-androidpublisher_v3","version":"0.34.0","platform":"ruby","checksum":"d7e1d7dd92f79c498fe2082222a1740d788e022e660c135564b3fd299cab5425"},
|
||||
|
|
|
|||
|
|
@ -742,7 +742,7 @@ GEM
|
|||
omniauth (>= 1.3, < 3)
|
||||
pyu-ruby-sasl (>= 0.0.3.3, < 0.1)
|
||||
rubyntlm (~> 0.5)
|
||||
gitlab_quality-test_tooling (1.14.2)
|
||||
gitlab_quality-test_tooling (1.15.0)
|
||||
activesupport (>= 6.1, < 7.1)
|
||||
amatch (~> 0.4.1)
|
||||
gitlab (~> 4.19)
|
||||
|
|
@ -1935,7 +1935,7 @@ DEPENDENCIES
|
|||
gitlab-utils!
|
||||
gitlab_chronic_duration (~> 0.12)
|
||||
gitlab_omniauth-ldap (~> 2.2.0)
|
||||
gitlab_quality-test_tooling (~> 1.14.2)
|
||||
gitlab_quality-test_tooling (~> 1.15.0)
|
||||
gon (~> 6.4.0)
|
||||
google-apis-androidpublisher_v3 (~> 0.34.0)
|
||||
google-apis-cloudbilling_v1 (~> 0.21.0)
|
||||
|
|
|
|||
|
|
@ -1418,6 +1418,7 @@ Input type: `AiActionInput`
|
|||
| <a id="mutationaiactiongeneratedescription"></a>`generateDescription` | [`AiGenerateDescriptionInput`](#aigeneratedescriptioninput) | Input for generate_description AI action. |
|
||||
| <a id="mutationaiactionresolvevulnerability"></a>`resolveVulnerability` | [`AiResolveVulnerabilityInput`](#airesolvevulnerabilityinput) | Input for resolve_vulnerability AI action. |
|
||||
| <a id="mutationaiactionsummarizecomments"></a>`summarizeComments` | [`AiSummarizeCommentsInput`](#aisummarizecommentsinput) | Input for summarize_comments AI action. |
|
||||
| <a id="mutationaiactionsummarizenewmergerequest"></a>`summarizeNewMergeRequest` | [`AiSummarizeNewMergeRequestInput`](#aisummarizenewmergerequestinput) | Input for summarize_new_merge_request AI action. |
|
||||
| <a id="mutationaiactionsummarizereview"></a>`summarizeReview` | [`AiSummarizeReviewInput`](#aisummarizereviewinput) | Input for summarize_review AI action. |
|
||||
|
||||
#### Fields
|
||||
|
|
@ -34985,6 +34986,19 @@ see the associated mutation type above.
|
|||
| ---- | ---- | ----------- |
|
||||
| <a id="aisummarizecommentsinputresourceid"></a>`resourceId` | [`AiModelID!`](#aimodelid) | Global ID of the resource to mutate. |
|
||||
|
||||
### `AiSummarizeNewMergeRequestInput`
|
||||
|
||||
Summarize a new merge request based on two branches. Returns `null` if the `add_ai_summary_for_new_mr` feature flag is disabled.
|
||||
|
||||
#### Arguments
|
||||
|
||||
| Name | Type | Description |
|
||||
| ---- | ---- | ----------- |
|
||||
| <a id="aisummarizenewmergerequestinputresourceid"></a>`resourceId` | [`AiModelID!`](#aimodelid) | Global ID of the resource to mutate. |
|
||||
| <a id="aisummarizenewmergerequestinputsourcebranch"></a>`sourceBranch` | [`String!`](#string) | Source branch of the changes. |
|
||||
| <a id="aisummarizenewmergerequestinputsourceprojectid"></a>`sourceProjectId` | [`ID`](#id) | ID of the project where the changes are from. |
|
||||
| <a id="aisummarizenewmergerequestinputtargetbranch"></a>`targetBranch` | [`String!`](#string) | Target branch of where the changes will be merged into. |
|
||||
|
||||
### `AiSummarizeReviewInput`
|
||||
|
||||
#### Arguments
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ coach:
|
|||
approvers: []
|
||||
---
|
||||
|
||||
Disclaimer: This blueprint requires more cross-functional alignment - [Confidence Level] --> Low
|
||||
Disclaimer: This blueprint requires more cross-functional alignment - **Confidence Level:** Low
|
||||
|
||||
# Application Deployment with a Cellular Architecture
|
||||
|
||||
|
|
|
|||
|
|
@ -123,7 +123,7 @@ However, Service-Integration will establish certain necessary and optional requi
|
|||
| ID | Required | Detail | Epic/Issue | Done? |
|
||||
|---|---|---|---|---|
|
||||
| `R100` | Required | The platform should be easy to use: imagine Heroku with [GitLab Production Readiness-approved](https://handbook.gitlab.com/handbook/engineering/infrastructure/production/readiness/) defaults. | [Runway to [BETA] : Increased Adoption and Self Service](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/1115) | **{dotted-circle}** No |
|
||||
| `R110` | Required | With the exception of an Infrastructure-led onboarding process, services are owned, deployed and managed by stage-group teams. In other words,services follow a “You Build It, You Run It” model of ownership.| [[Paused] Discussion: Tiered Support Model for Runway](https://gitlab.com/gitlab-com/gl-infra/platform/runway/team/-/issues/97) | **{dotted-circle}** No |
|
||||
| `R110` | Required | With the exception of an Infrastructure-led onboarding process, services are owned, deployed and managed by stage-group teams. In other words,services follow a "You Build It, You Run It" model of ownership.| [[Paused] Discussion: Tiered Support Model for Runway](https://gitlab.com/gitlab-com/gl-infra/platform/runway/team/-/issues/97) | **{dotted-circle}** No |
|
||||
| `R120` | Required | Programming-language agnostic: no requirements for services. Services should be packaged as container images.| [Runway to [BETA] : Increased Adoption and Self Service](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/1115) | **{dotted-circle}** No |
|
||||
| `R130` | Recommended | Each service should be evaluated against the GitLab.com [Service Maturity Model](https://handbook.gitlab.com/handbook/engineering/infrastructure/service-maturity-model/).| [Discussion: Introduce an 'Infrastructure Well-Architected Service Framework'](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/2537) | **{dotted-circle}** No |
|
||||
| `R140` | Recommended | Services using the platform have expedited production-readiness processes. {::nomarkdown}<ol><li>Production-readiness requirements graded by service maturity: low-traffic, low-maturity experimental services will have lower requirement thresholds than more mature services. </li><li> By default, the platform should provide services with defaults that would pass production-readiness review for the lowest service maturity-level. </li><li> At introduction, lowest maturity services can be deployed without production readiness, provided the meet certain automatically validated requirements. This removes Infrastructure gate-keeping from being a blocker to experimental service delivery.</li></ol>{:/} | | |
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ Keeping up with the latest version of Vue ensures that the GitLab frontend lever
|
|||
**Current Status**
|
||||
|
||||
- **As of December 2023**: GitLab is currently using Vue 2.x.
|
||||
- **Progress**: [Brief description of progress]
|
||||
- **Progress**: (Brief description of progress)
|
||||
|
||||
**Responsible Team**
|
||||
|
||||
|
|
@ -26,11 +26,11 @@ Keeping up with the latest version of Vue ensures that the GitLab frontend lever
|
|||
|
||||
**Milestones and Timelines**
|
||||
|
||||
- [Key milestones, expected completions]
|
||||
- (Key milestones, expected completions)
|
||||
|
||||
**Challenges and Dependencies**
|
||||
|
||||
- [Any major challenges]
|
||||
- (Any major challenges)
|
||||
|
||||
**Success Metrics**
|
||||
|
||||
|
|
@ -38,12 +38,12 @@ Keeping up with the latest version of Vue ensures that the GitLab frontend lever
|
|||
|
||||
### State Management
|
||||
|
||||
When global state management is needed, it should happen in Apollo instead of Vuex or other state management libraries. See [https://docs.gitlab.com/ee/development/fe_guide/migrating_from_vuex.html](migrating_from_vuex.md) for more details regarding why and how we plan on migrating.
|
||||
When global state management is needed, it should happen in Apollo instead of Vuex or other state management libraries. See [Migrating from Vuex](migrating_from_vuex.md) for more details regarding why and how we plan on migrating.
|
||||
|
||||
**Current Status**
|
||||
|
||||
- **As of December 2023**: [Status]
|
||||
- **Progress**: [Brief description of progress]
|
||||
- **As of December 2023**: (Status)
|
||||
- **Progress**: (Brief description of progress)
|
||||
|
||||
**Responsible Team**
|
||||
|
||||
|
|
@ -52,24 +52,24 @@ When global state management is needed, it should happen in Apollo instead of Vu
|
|||
|
||||
**Milestones and Timelines**
|
||||
|
||||
- [Key milestones, expected completions]
|
||||
- (Key milestones, expected completions)
|
||||
|
||||
**Challenges and Dependencies**
|
||||
|
||||
- [Any major challenges]
|
||||
- (Any major challenges)
|
||||
|
||||
**Success Metrics**
|
||||
|
||||
- [Potential metrics]
|
||||
- (Potential metrics)
|
||||
|
||||
### HAML by default
|
||||
|
||||
We'll continue using HAML over Vue when appropriate. See [https://docs.gitlab.com/ee/development/fe_guide/vue.html#when-to-add-vue-application](vue.md#when-to-add-vue-application) on how to decide when Vue should be chosen.
|
||||
We'll continue using HAML over Vue when appropriate. See [when to add Vue application](vue.md#when-to-add-vue-application) on how to decide when Vue should be chosen.
|
||||
|
||||
**Current Status**
|
||||
|
||||
- **As of December 2023**: [Status]
|
||||
- **Progress**: [Brief description of progress]
|
||||
- **As of December 2023**: (Status)
|
||||
- **Progress**: (Brief description of progress)
|
||||
|
||||
**Responsible Team**
|
||||
|
||||
|
|
@ -78,15 +78,15 @@ We'll continue using HAML over Vue when appropriate. See [https://docs.gitlab.co
|
|||
|
||||
**Milestones and Timelines**
|
||||
|
||||
- [Key milestones, expected completions]
|
||||
- (Key milestones, expected completions)
|
||||
|
||||
**Challenges and Dependencies**
|
||||
|
||||
- [Any major challenges]
|
||||
- (Any major challenges)
|
||||
|
||||
**Success Metrics**
|
||||
|
||||
- [Potential metrics]
|
||||
- (Potential metrics)
|
||||
|
||||
### Complete removal of jQuery
|
||||
|
||||
|
|
@ -94,8 +94,8 @@ In 2019 we committed to no longer use jQuery, however we have not prioritized fu
|
|||
|
||||
**Current Status**
|
||||
|
||||
- **As of December 2023**: [Status]
|
||||
- **Progress**: [Brief description of progress]
|
||||
- **As of December 2023**: (Status)
|
||||
- **Progress**: (Brief description of progress)
|
||||
|
||||
**Responsible Team**
|
||||
|
||||
|
|
@ -104,15 +104,15 @@ In 2019 we committed to no longer use jQuery, however we have not prioritized fu
|
|||
|
||||
**Milestones and Timelines**
|
||||
|
||||
- [Key milestones, expected completions]
|
||||
- (Key milestones, expected completions)
|
||||
|
||||
**Challenges and Dependencies**
|
||||
|
||||
- [Any major challenges]
|
||||
- (Any major challenges)
|
||||
|
||||
**Success Metrics**
|
||||
|
||||
- [Potential metrics]
|
||||
- (Potential metrics)
|
||||
|
||||
### Dependencies management
|
||||
|
||||
|
|
@ -120,8 +120,8 @@ Similar to keeping on the latest major version of Vue, we should try to keep as
|
|||
|
||||
**Current Status**
|
||||
|
||||
- **As of December 2023**: [Status]
|
||||
- **Progress**: [Brief description of progress]
|
||||
- **As of December 2023**: (Status)
|
||||
- **Progress**: (Brief description of progress)
|
||||
|
||||
**Responsible Team**
|
||||
|
||||
|
|
@ -130,15 +130,15 @@ Similar to keeping on the latest major version of Vue, we should try to keep as
|
|||
|
||||
**Milestones and Timelines**
|
||||
|
||||
- [Key milestones, expected completions]
|
||||
- (Key milestones, expected completions)
|
||||
|
||||
**Challenges and Dependencies**
|
||||
|
||||
- [Any major challenges]
|
||||
- (Any major challenges)
|
||||
|
||||
**Success Metrics**
|
||||
|
||||
- [Potential metrics]
|
||||
- (Potential metrics)
|
||||
|
||||
## Best Practices
|
||||
|
||||
|
|
@ -168,8 +168,8 @@ For navigation between clusters, we can still rely on Rails routing. These cases
|
|||
|
||||
**Current Status**
|
||||
|
||||
- **As of December 2023**: [Status]
|
||||
- **Progress**: [Brief description of progress]
|
||||
- **As of December 2023**: (Status)
|
||||
- **Progress**: (Brief description of progress)
|
||||
|
||||
**Responsible Team**
|
||||
|
||||
|
|
@ -178,15 +178,15 @@ For navigation between clusters, we can still rely on Rails routing. These cases
|
|||
|
||||
**Milestones and Timelines**
|
||||
|
||||
- [Key milestones, expected completions]
|
||||
- (Key milestones, expected completions)
|
||||
|
||||
**Challenges and Dependencies**
|
||||
|
||||
- [Any major challenges]
|
||||
- (Any major challenges)
|
||||
|
||||
**Success Metrics**
|
||||
|
||||
- [Potential metrics]
|
||||
- (Potential metrics)
|
||||
|
||||
### Reusable components
|
||||
|
||||
|
|
@ -203,8 +203,8 @@ This is currently under development. Follow the [GitLab Modular Monolith for FE]
|
|||
|
||||
**Current Status**
|
||||
|
||||
- **As of December 2023**: [Status]
|
||||
- **Progress**: [Brief description of progress]
|
||||
- **As of December 2023**: (Status)
|
||||
- **Progress**: (Brief description of progress)
|
||||
|
||||
**Responsible Team**
|
||||
|
||||
|
|
@ -213,15 +213,15 @@ This is currently under development. Follow the [GitLab Modular Monolith for FE]
|
|||
|
||||
**Milestones and Timelines**
|
||||
|
||||
- [Key milestones, expected completions]
|
||||
- (Key milestones, expected completions)
|
||||
|
||||
**Challenges and Dependencies**
|
||||
|
||||
- [Any major challenges]
|
||||
- (Any major challenges)
|
||||
|
||||
**Success Metrics**
|
||||
|
||||
- [Potential metrics]
|
||||
- (Potential metrics)
|
||||
|
||||
### Migrate to PostCSS
|
||||
|
||||
|
|
@ -229,8 +229,8 @@ SASS compilation takes almost half of the total frontend compilation time. This
|
|||
|
||||
**Current Status**
|
||||
|
||||
- **As of December 2023**: [Status]
|
||||
- **Progress**: [Brief description of progress]
|
||||
- **As of December 2023**: (Status)
|
||||
- **Progress**: (Brief description of progress)
|
||||
|
||||
**Responsible Team**
|
||||
|
||||
|
|
@ -239,15 +239,15 @@ SASS compilation takes almost half of the total frontend compilation time. This
|
|||
|
||||
**Milestones and Timelines**
|
||||
|
||||
- [Key milestones, expected completions]
|
||||
- (Key milestones, expected completions)
|
||||
|
||||
**Challenges and Dependencies**
|
||||
|
||||
- [Any major challenges]
|
||||
- (Any major challenges)
|
||||
|
||||
**Success Metrics**
|
||||
|
||||
- [Potential metrics]
|
||||
- (Potential metrics)
|
||||
|
||||
## Collaboration and Tooling
|
||||
|
||||
|
|
@ -257,8 +257,8 @@ We're early in the process of adding visual testing, but we should have a framew
|
|||
|
||||
**Current Status**
|
||||
|
||||
- **As of December 2023**: [Status]
|
||||
- **Progress**: [Brief description of progress]
|
||||
- **As of December 2023**: (Status)
|
||||
- **Progress**: (Brief description of progress)
|
||||
|
||||
**Responsible Team**
|
||||
|
||||
|
|
@ -267,15 +267,15 @@ We're early in the process of adding visual testing, but we should have a framew
|
|||
|
||||
**Milestones and Timelines**
|
||||
|
||||
- [Key milestones, expected completions]
|
||||
- (Key milestones, expected completions)
|
||||
|
||||
**Challenges and Dependencies**
|
||||
|
||||
- [Any major challenges]
|
||||
- (Any major challenges)
|
||||
|
||||
**Success Metrics**
|
||||
|
||||
- [Potential metrics]
|
||||
- (Potential metrics)
|
||||
|
||||
### Accessibility testing
|
||||
|
||||
|
|
@ -283,8 +283,8 @@ In 2023 we determined the tooling for accessibility testing. We opted for axe-co
|
|||
|
||||
**Current Status**
|
||||
|
||||
- **As of December 2023**: [Status]
|
||||
- **Progress**: [Brief description of progress]
|
||||
- **As of December 2023**: (Status)
|
||||
- **Progress**: (Brief description of progress)
|
||||
|
||||
**Responsible Team**
|
||||
|
||||
|
|
@ -293,12 +293,12 @@ In 2023 we determined the tooling for accessibility testing. We opted for axe-co
|
|||
|
||||
**Milestones and Timelines**
|
||||
|
||||
- [Key milestones, expected completions]
|
||||
- (Key milestones, expected completions)
|
||||
|
||||
**Challenges and Dependencies**
|
||||
|
||||
- [Any major challenges]
|
||||
- (Any major challenges)
|
||||
|
||||
**Success Metrics**
|
||||
|
||||
- [Potential metrics]
|
||||
- (Potential metrics)
|
||||
|
|
|
|||
|
|
@ -681,7 +681,7 @@ This should let us:
|
|||
Our test suite runs against PostgreSQL 14 as GitLab.com runs on PostgreSQL 14 and
|
||||
[Omnibus defaults to PG14 for new installs and upgrades](../../administration/package_information/postgresql_versions.md).
|
||||
|
||||
We do run our test suite against PostgreSQL 14 on nightly scheduled pipelines.
|
||||
We run our test suite against PostgreSQL 13, 14, 15 and 16 on nightly scheduled pipelines.
|
||||
|
||||
We also run our test suite against PostgreSQL 13 upon specific database library changes in merge requests and `main` pipelines (with the `rspec db-library-code pg13` job).
|
||||
|
||||
|
|
@ -694,7 +694,7 @@ We also run our test suite against PostgreSQL 13 upon specific database library
|
|||
| `maintenance` scheduled pipelines for the `master` branch (every even-numbered hour at XX:05) | 14 (default version), 13 for DB library changes | 3.1 (default version) |
|
||||
| `maintenance` scheduled pipelines for the `ruby3_0` branch (every odd-numbered hour at XX:40) | 14 (default version), 13 for DB library changes | 3.0 |
|
||||
| `maintenance` scheduled pipelines for the `ruby3_2` branch (every odd-numbered hour at XX:10) | 14 (default version), 13 for DB library changes | 3.2 |
|
||||
| `nightly` scheduled pipelines for the `master` branch | 14 (default version), 13, 15 | 3.1 (default version) |
|
||||
| `nightly` scheduled pipelines for the `master` branch | 14 (default version), 13, 15, 16 | 3.1 (default version) |
|
||||
|
||||
For each current Ruby versions we're testing against with, we run
|
||||
maintenance scheduled pipelines every 2 hours on their respective `ruby\d_\d`
|
||||
|
|
|
|||
|
|
@ -181,6 +181,8 @@ that are scoped to a single [configuration keyword](../../ci/yaml/index.md#job-k
|
|||
| `.use-pg14-ee` | Same as `.use-pg14` but also use an `elasticsearch` service (see [`.gitlab/ci/global.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/global.gitlab-ci.yml) for the specific version of the service). |
|
||||
| `.use-pg15` | Allows a job to use the `postgres` 15, `redis`, and `rediscluster` services (see [`.gitlab/ci/global.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/global.gitlab-ci.yml) for the specific versions of the services). |
|
||||
| `.use-pg15-ee` | Same as `.use-pg15` but also use an `elasticsearch` service (see [`.gitlab/ci/global.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/global.gitlab-ci.yml) for the specific version of the service). |
|
||||
| `.use-pg16` | Allows a job to use the `postgres` 16, `redis`, and `rediscluster` services (see [`.gitlab/ci/global.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/global.gitlab-ci.yml) for the specific versions of the services). |
|
||||
| `.use-pg16-ee` | Same as `.use-pg16` but also use an `elasticsearch` service (see [`.gitlab/ci/global.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/global.gitlab-ci.yml) for the specific version of the service). |
|
||||
| `.use-kaniko` | Allows a job to use the `kaniko` tool to build Docker images. |
|
||||
| `.as-if-foss` | Simulate the FOSS project by setting the `FOSS_ONLY='1'` CI/CD variable. |
|
||||
| `.use-docker-in-docker` | Allows a job to use Docker in Docker. For more details, see the [handbook about CI/CD configuration](https://handbook.gitlab.com/handbook/engineering/gitlab-repositories/#cicd-configuration). |
|
||||
|
|
|
|||
|
|
@ -54,7 +54,7 @@ Documentation and References:
|
|||
|
||||
#### AWS CodePipeline Integrations
|
||||
|
||||
[AWS CodePipeline Integration](https://docs.aws.amazon.com/codepipeline/latest/userguide/connections-gitlab.html) - by using GitLab as CodeStar Connections source for CodePipeline, additional AWS service integrations are available. [[12/28/2023](https://aws.amazon.com/about-aws/whats-new/2023/12/codepipeline-gitlab-self-managed/)] `[AWS Built]`
|
||||
[AWS CodePipeline Integration](https://docs.aws.amazon.com/codepipeline/latest/userguide/connections-gitlab.html) - by using GitLab as CodeStar Connections source for CodePipeline, additional AWS service integrations are available. ([12/28/2023](https://aws.amazon.com/about-aws/whats-new/2023/12/codepipeline-gitlab-self-managed/)) `[AWS Built]`
|
||||
|
||||
AWS Services that are supported by an AWS CodePipeline integration:
|
||||
|
||||
|
|
|
|||
|
|
@ -135,7 +135,7 @@ To create the **UX workflow** issue board:
|
|||
1. Clear the **Show the Open list** and **Show the Closed list** checkboxes.
|
||||
1. Select **Create board**. You should see an empty board.
|
||||
1. Create a list for the `Workflow::Ready for design` label:
|
||||
1. In the upper-left corner of the issue board page, select **Create list**.
|
||||
1. In the upper-right corner of the issue board page, select **Create list**.
|
||||
1. In the column that appears, from the **Value** dropdown list, select the `Workflow::Ready for design` label.
|
||||
1. Select **Add to board**.
|
||||
1. Repeat the previous step for labels `Workflow::Design` and `Workflow::Ready for development`.
|
||||
|
|
@ -152,7 +152,7 @@ To create the **Frontend workflow** board:
|
|||
1. Next to **Labels**, select **Edit** and select the `Frontend` label.
|
||||
1. Select **Create board**.
|
||||
1. Create a list for the `Workflow::Ready for development` label:
|
||||
1. In the upper-left corner of the issue board page, select **Create list**.
|
||||
1. In the upper-right corner of the issue board page, select **Create list**.
|
||||
1. In the column that appeared, from the **Value** dropdown list, select the `Workflow::Ready for development` label.
|
||||
1. Select **Add to board**.
|
||||
1. Repeat the previous step for labels `Workflow::In development` and `Workflow::Complete`.
|
||||
|
|
|
|||
|
|
@ -165,11 +165,11 @@ To set up your issue board:
|
|||
1. Select **Plan > Issue boards**.
|
||||
1. In the upper-left corner of the issue board page, select the dropdown list with the current board name.
|
||||
1. Select **Create new board**.
|
||||
1. In the **Title field**, enter `Issue triage (by severity)`.
|
||||
1. In the **Title** field, enter `Issue triage (by severity)`.
|
||||
1. Keep the **Show the Open list** checkbox selected and clear the **Show the Closed list** one.
|
||||
1. Select **Create board**. You should see an empty board.
|
||||
1. Create a list for the `severity::1` label:
|
||||
1. In the upper-left corner of the issue board page, select **Create list**.
|
||||
1. In the upper-right corner of the issue board page, select **Create list**.
|
||||
1. In the column that appears, from the **Value** dropdown list, select the `severity::1` label.
|
||||
1. Select **Add to board**.
|
||||
1. Repeat the previous step for labels `severity::2`, `severity::3`, and `severity::4`.
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 17 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 34 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 39 KiB |
|
|
@ -0,0 +1,556 @@
|
|||
---
|
||||
stage: Plan
|
||||
group: Project Management
|
||||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
|
||||
---
|
||||
|
||||
# Tutorial: Use GitLab to facilitate Scrum
|
||||
|
||||
DETAILS:
|
||||
**Tier:** Premium, Ultimate
|
||||
**Offering:** SaaS, self-managed
|
||||
|
||||
<!-- vale gitlab.FutureTense = NO -->
|
||||
|
||||
This tutorial provides step-by-step guidance on using agile planning and tracking features in GitLab
|
||||
to facilitate core Scrum ceremonies and workflows.
|
||||
By setting up groups, projects, boards, and other features in a deliberate way, teams can realize
|
||||
enhanced transparency, collaboration, and delivery cadences.
|
||||
|
||||
According to Martin Fowler's [Agile Fluency Model](https://martinfowler.com/articles/agileFluency.html), teams practicing [Scrum](https://scrumguides.org/scrum-guide.html):
|
||||
|
||||
> ...think and plan in terms of the benefits their sponsors, customers, and users will see from their software.
|
||||
|
||||
They achieve this by demonstrating their progress monthly; regularly reflecting on improving their
|
||||
processes and work habits to provide more business and customer value.
|
||||
|
||||
This tutorial covers the following topics:
|
||||
|
||||
- Setting up GitLab
|
||||
- Understand inheritance model in GitLab
|
||||
- Create your group
|
||||
- Create your projects
|
||||
- Create labels
|
||||
- Create an iteration cadence
|
||||
- Managing your feature backlog
|
||||
- How to structure your work
|
||||
- Setup a release planning board
|
||||
- Write your first feature
|
||||
- Managing your story backlog
|
||||
- Break down features into stories
|
||||
- Refine your story backlog
|
||||
- Tracking sprint progress
|
||||
- Manage the workflow of stories in your sprint
|
||||
- View burndown/up charts for your sprint
|
||||
- Facilitating other Scrum ceremonies in GitLab
|
||||
- Synchronous and asynchronous stand-up
|
||||
- Synchronous and asynchronous retrospective
|
||||
- Advanced tips and tricks
|
||||
- Leverage issue templates
|
||||
- Decide on a story point scale
|
||||
- Measure velocity and lower your team's volatility
|
||||
|
||||
## Setting up your groups and projects
|
||||
|
||||
To facilitate Scrum practices in GitLab, you first need to set up the foundational structure of groups
|
||||
and projects.
|
||||
You'll use groups to create boards and labels that can be inherited by projects nested under that group.
|
||||
Projects will contain the issues and tasks that make up the actual work items for each sprint.
|
||||
|
||||
### Understanding the inheritance model in GitLab
|
||||
|
||||
GitLab has a hierarchical structure where groups contain projects.
|
||||
Settings and configurations applied at the group level cascade down to child projects, so you can
|
||||
standardize labels, boards, and iterations across multiple projects:
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
Group -->|Contains| Project
|
||||
Group -->|Contains| Epics
|
||||
Group -->|Contains| Labels
|
||||
Group -->|Contains| Boards
|
||||
Group -->|Contains| Iterations
|
||||
Project -->|Contains| Issues
|
||||
Labels .->|Cascades To| Project
|
||||
Issues .->|Rolls Up To| Group
|
||||
Iterations .->|Cascades To| Project
|
||||
Issues .->|Assigned To| Epics
|
||||
Issues .->|Visible In| Boards
|
||||
Issues .->|Assigned To| Iterations
|
||||
```
|
||||
|
||||
- Groups contain one or more projects, epics, boards, labels, and iterations.
|
||||
User membership in groups cascades down to a group's projects.
|
||||
- You can create boards and labels in a group or project.
|
||||
For this tutorial, you should create them in a group to facilitate standardized planning workflows
|
||||
and reporting across many projects in a single group.
|
||||
- Any object that cascades down to a project can be associated with that project's issues,
|
||||
for example: you can apply labels from a group to issues.
|
||||
|
||||
### Create your group
|
||||
|
||||
Create a dedicated group for your Scrum activities.
|
||||
This will be the parent container for projects and configurations like boards and labels that you want
|
||||
to be standardized across projects.
|
||||
|
||||
This group will be the primary location for the different activities during a typical Scrum cadence.
|
||||
It will contain your boards, features (epics), story (issue) roll up, and labels.
|
||||
|
||||
To create a group:
|
||||
|
||||
1. On the left sidebar, at the top, select **Create new** (**{plus}**) and **New group**.
|
||||
1. Select **Create group**.
|
||||
1. In the **Group name** text box, enter the name of the group. For a list of words that cannot be used as group names, see
|
||||
[reserved names](../../user/reserved_names.md).
|
||||
1. In the **Group URL** text box, enter the path for the group used for the [namespace](../../user/namespace/index.md).
|
||||
1. Select the [**Visibility level**](../../user/public_access.md) of the group.
|
||||
1. Optional. To personalize your GitLab experience:
|
||||
- From the **Role** dropdown list, select your role.
|
||||
- For **Who will be using this group?**, select an option.
|
||||
- From the **What will you use this group for?** dropdown list, select an option.
|
||||
1. Optional. To invite members to the group, in the **Email 1** text box, enter the email address of the user you want to invite. To invite more users, select **Invite another member** and enter the user's email address.
|
||||
1. Select **Create group**.
|
||||
|
||||
### Create your projects
|
||||
|
||||
In the group you created, create one or more projects.
|
||||
Your project will contain the stories that roll up to your parent group.
|
||||
|
||||
To create a blank project:
|
||||
|
||||
1. On the left sidebar, at the top, select **Create new** (**{plus}**) and **New project/repository**.
|
||||
1. Select **Create blank project**.
|
||||
1. Enter the project details:
|
||||
- In the **Project name** field, enter the name of your project. See the
|
||||
[limitations on project names](../../user/reserved_names.md).
|
||||
- In the **Project slug** field, enter the path to your project. The GitLab instance uses the
|
||||
slug as the URL path to the project. To change the slug, first enter the project name,
|
||||
then change the slug.
|
||||
- To modify the project's [viewing and access rights](../../user/public_access.md) for
|
||||
users, change the **Visibility Level**.
|
||||
- To create README file so that the Git repository is initialized, has a default branch, and
|
||||
can be cloned, select **Initialize repository with a README**.
|
||||
1. Select **Create project**.
|
||||
|
||||
### Create scoped labels to support different phases of the Scrum lifecycle
|
||||
|
||||
Next, in the group you've created, you'll create labels to add to issues to categorize them.
|
||||
|
||||
The best tool for this is [scoped labels](../../user/project/labels.md#scoped-labels), which you
|
||||
can use to set mutually exclusive attributes.
|
||||
|
||||
The double colon (`::`) in the name of a scoped label prevents two labels of the same scope being
|
||||
used together.
|
||||
For example, if you add the `status::in progress` label to an issue that already has `status::ready`,
|
||||
the previous one is removed.
|
||||
|
||||
To create each label:
|
||||
|
||||
1. On the left sidebar, select **Search or go to** and find your group.
|
||||
1. Select **Manage > Labels**.
|
||||
1. Select **New label**.
|
||||
1. In the **Title** field, enter the name of the label. Start with `priority::now`.
|
||||
1. Optional. Select a color by selecting from the available colors, or enter a hex color value for
|
||||
a specific color in the **Background color** field.
|
||||
1. Select **Create label**.
|
||||
|
||||
Repeat these steps to create all the labels you'll need:
|
||||
|
||||
- **Priority:** You will use these on an epic board to facilitate feature-level release prioritization.
|
||||
- `priority::now`
|
||||
- `priority::next`
|
||||
- `priority::later`
|
||||
- **Status:** You will use these labels on an issue board to understand a story's current step in the
|
||||
overall development lifecycle.
|
||||
- `status::triage`
|
||||
- `status::refine`
|
||||
- `status::ready`
|
||||
- `status::in progress`
|
||||
- `status::in review`
|
||||
- `status::acceptance`
|
||||
- `status::done`
|
||||
- **Type:** You will use these labels to represent the different types of work typically pulled into a single iteration:
|
||||
- `type::story`
|
||||
- `type::bug`
|
||||
- `type::mantainence`
|
||||
|
||||
### Create an iteration cadence
|
||||
|
||||
In GitLab, sprints are called iterations.
|
||||
Iteration cadences contain the individual, sequential iteration timeboxes for planning and reporting
|
||||
on your issues.
|
||||
Similar to labels, iterations cascade down your group, subgroup, and project hierarchy.
|
||||
That's why you'll create the iteration cadence in the group you've created.
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- You must have at least the Reporter role for a group.
|
||||
|
||||
To create an iteration cadence:
|
||||
|
||||
1. On the left sidebar, select **Search or go to** and find your group.
|
||||
1. Select **Plan > Iterations**.
|
||||
1. Select **New iteration cadence**.
|
||||
1. Enter the title and description of the iteration cadence.
|
||||
1. Make sure the **Enable automatic scheduling** checkbox is selected.
|
||||
1. Complete the required fields to use automatic scheduling.
|
||||
- Select the automation start date of the iteration cadence. Iterations are scheduled to
|
||||
begin on the same day of the week as the day of the week of the start date.
|
||||
- From the **Duration** dropdown list, select **2**.
|
||||
- From the **Upcoming iterations** dropdown list, select **4**.
|
||||
- Select the **Enable roll over** checkbox.
|
||||
1. Select **Create cadence**. The cadence list page opens.
|
||||
|
||||
With your iteration cadence configured this way:
|
||||
|
||||
- Each sprint is two weeks in length.
|
||||
- GitLab automatically creates four sprints in the future.
|
||||
- Incomplete issues from one sprint are automatically reassigned to the next sprint when the current sprint is closed.
|
||||
|
||||
You can also disable **Automatic scheduling** and
|
||||
[manually create and manage iterations](../../user/group/iterations/index.md#create-an-iteration-manually) in your cadence.
|
||||
|
||||
## Managing your feature backlog
|
||||
|
||||
A feature backlog captures ideas and desired functionality in the form of epics.
|
||||
As you refine this backlog, epics will be prioritized to flow into upcoming sprints.
|
||||
This section covers creating an epic board to facilitate backlog management and writing your first
|
||||
feature epic.
|
||||
|
||||
### Decide on a way to structure your work
|
||||
|
||||
GitLab is extensible to support different flavors of backlog management.
|
||||
For this tutorial, we will structure our deliverables in the following way:
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
Epic["Feature (Epic)"] --> Issue["Job Story (Issue)"]
|
||||
Issue --> Task["Implementation Step (Task)"]
|
||||
```
|
||||
|
||||
- An epic represents a feature that a team can deliver in a single iteration.
|
||||
- Each epic will contain many
|
||||
[job stories](https://medium.com/@umang.soni/moving-from-user-role-based-approach-to-problem-statement-based-approach-for-product-development-18b2d2395e5).
|
||||
- A story should provide tangible customer value, contain explicit acceptance criteria, and be small
|
||||
enough that an individual can complete it in one or two days.
|
||||
- You should be able to complete four to ten stories as a team per sprint.
|
||||
- While there are many strategies for splitting features, a great strategy is to
|
||||
[vertically slice](https://www.agilerant.info/vertical-slicing-to-boost-software-value/) stories
|
||||
into discrete, standalone stories a user must take to accomplish their goal.
|
||||
|
||||
While you might not be able to ship a single story to your customers, your team should be able to
|
||||
test and interact with each story by using a feature flag on production or in a staging environment.
|
||||
Not only does this help provide stakeholders visibility into the story's progress, but also is a
|
||||
mechanism to break down more complex features into approachable development goals.
|
||||
- Depending on the complexity of the stories, you can use tasks to break down stories into discrete
|
||||
implementation steps developers need to take to complete the story.
|
||||
|
||||
In terms of time horizons, target the following guidelines to sizing and scoping work items:
|
||||
|
||||
- A **feature** can be completed in a single iteration.
|
||||
- A **story** can be completed in a few days.
|
||||
- A **task** can be completed in a few hours to a day.
|
||||
|
||||
#### Example: Vertically slicing a feature
|
||||
|
||||
Here's an example of breaking a feature into vertically sliced job stories based on the end user's
|
||||
journey:
|
||||
|
||||
```mermaid
|
||||
Epic["Epic: When using the application, I need to create an <br> account, so that I can use the application features"] --> Issue1["Issue: When creating my account, I need to specify my email address,<br> so that I can receive future updates from the application"]
|
||||
Epic --> Issue2["Issue: When creating my account, I need to <br>specify a password, so that my account remains secure"]
|
||||
Epic --> Issue3["Issue: When creating my account and entering the required info, I need to <br>finalize creating my account, so that I can login"]
|
||||
```
|
||||
|
||||
You've taken the feature of an unmodified account sign-up for an application and broke it down into
|
||||
three discrete stories:
|
||||
|
||||
1. Entering an email address.
|
||||
1. Entering a password.
|
||||
1. Selecting a button to execute the account creation.
|
||||
|
||||
After you have broken down a feature into stories, you can further break down the story into discrete
|
||||
implementation steps:
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
Issue1["Issue: When creating my account, I need to specify my email address,<br> so that I can receive future updates from the application"]
|
||||
Issue1 --> Task2["Task: Backend - Validate email formatting"]
|
||||
Issue1 --> Task3["Task: Backend - API endpoint to accept POST request from client"]
|
||||
Issue1 --> Task4["Task: Frontend - Display email input"]
|
||||
Issue1 --> Task5["Task: Frontend - Display error message when validation fails"]
|
||||
```
|
||||
|
||||
### Set up a release planning board
|
||||
|
||||
You've defined your deliverables structure.
|
||||
The next step is to create an epic board that you will use to develop and maintain your feature backlog.
|
||||
|
||||
To create a new epic board:
|
||||
|
||||
1. On the left sidebar, select **Search or go to** and find your group.
|
||||
1. Select **Plan > Epic boards**.
|
||||
1. In the upper-left corner, select the dropdown list with the current board name.
|
||||
1. Select **Create new board**.
|
||||
1. Enter the new board's title: `Release Planning`.
|
||||
1. Select **Create board**.
|
||||
|
||||
Next, [create lists](../../user/group/epics/epic_boards.md#create-a-new-list) for the `priority::later`,
|
||||
`priority::next`, and `priority::now` labels.
|
||||
|
||||
To create a new list:
|
||||
|
||||
1. In the upper-right corner of your board, select **Create list**.
|
||||
1. In the **New list** column expand the **Select a label** dropdown list and select the label to use as
|
||||
list scope.
|
||||
1. Select **Add to board**.
|
||||
|
||||
You'll use these lists to facilitate moving features through your board from left to right.
|
||||
|
||||
Use each list in your release planning board to represent the following time horizons:
|
||||
|
||||
- **Open:** Features that are not yet ready for prioritization.
|
||||
- **Later:** Features that will be prioritized into a later release.
|
||||
- **Next:** Features tentatively planned for the next release.
|
||||
- **Now:** Features prioritized for your current release.
|
||||
- **Closed:** Features that have been completed or canceled.
|
||||
|
||||
### Create your first epic
|
||||
|
||||
Next, create a new epic in the `priority::now` list:
|
||||
|
||||
1. On the top of the **`priority::now`** list, select the **New epic** (**{plus}**) icon.
|
||||
1. Enter the new epic's title:
|
||||
|
||||
```plaintext
|
||||
When using the application, I need to create an account, so that I can use the application features.
|
||||
```
|
||||
|
||||
1. Select **Create epic**.
|
||||
|
||||
When you complete this step, your board should look like this:
|
||||
|
||||
|
||||
|
||||
You can now use the **Release Planning** board to quickly build your backlog.
|
||||
|
||||
Stub out many features and prioritize them into the **Now**, **Next**, **Later** lists.
|
||||
Next, spend some time to further break down each story into stories and tasks.
|
||||
|
||||
To reorder feature epics in a list or across lists, drag the epic cards.
|
||||
You can also [move cards to the top or bottom](../../user/group/epics/epic_boards.md#move-an-epic-to-the-start-of-the-list) of a list.
|
||||
|
||||
## Managing your story backlog
|
||||
|
||||
When you have features defined as epics, the next step is to break down those features into granular,
|
||||
vertical slices as issues.
|
||||
You will then refine and sequence those issues across iterations on a dedicated backlog board.
|
||||
|
||||
### Break down features into stories
|
||||
|
||||
Break features into vertically sliced stories ahead of time to have an efficient sprint planning meeting.
|
||||
In the previous step, you created your first feature.
|
||||
Let's break that down into stories.
|
||||
|
||||
To create your first stories:
|
||||
|
||||
1. On the left sidebar, select **Search or go to** and find your group.
|
||||
1. Select **Plan > Epic boards**.
|
||||
1. In the upper-left corner, make sure the dropdown list with the current board name shows **Release Planning**.
|
||||
If not, from the dropdown list, select that board.
|
||||
1. Open an epic by clicking the title of the epic card.
|
||||
1. In the **Child issues and epics** section, select **Add > Add a new issue**.
|
||||
1. Enter the following title for the issue:
|
||||
|
||||
```plaintext
|
||||
When creating my account, I need to specify my email address so that I can receive future updates from the application
|
||||
```
|
||||
|
||||
1. From the **Project** dropdown list, select the project where you want to create the issue.
|
||||
1. Select **Create issue**.
|
||||
1. Repeat this process for the other two vertical slices:
|
||||
|
||||
```plaintext
|
||||
When creating my account, I need to specify a password so that my account remains secure
|
||||
```
|
||||
|
||||
```plaintext
|
||||
When creating my account and entering the required information, I need to finalize creating my account so that I can log in
|
||||
```
|
||||
|
||||
### Refine your story backlog
|
||||
|
||||
In the previous step, you broke down a feature into the necessary user stories to complete the feature.
|
||||
Next, set up an issue board to serve as your canonical location for managing and refining your story backlog.
|
||||
|
||||
In your group, create a new issue board titled **Backlog**.
|
||||
You will use this board to sequence and schedule your stories into upcoming sprints (iterations):
|
||||
|
||||
1. On the left sidebar, select **Search or go to** and find your group.
|
||||
1. Select **Plan > Issue boards**.
|
||||
1. In the upper-left corner, select the dropdown list with the current board name.
|
||||
1. Select **Create new board**.
|
||||
1. Enter the new board's title: `Backlog`.
|
||||
1. Select **Create board**.
|
||||
|
||||
After you've created the board, create a new list for each upcoming iteration:
|
||||
|
||||
1. In the upper-right corner of the issue board page, select **Create list**.
|
||||
1. In the column that appears, under **Scope**, select **Iteration**.
|
||||
1. From the **Value** dropdown list, select one of the iterations.
|
||||
1. Select **Add to board**.
|
||||
1. Repeat the previous step for the other upcoming iterations.
|
||||
|
||||
Then, when an iteration is over, you should [remove the completed iteration list](../../user/project/issue_board.md#remove-a-list)
|
||||
and add a new list for the new future iteration that was automatically created based on your cadence settings.
|
||||
|
||||
At this point, stories haven't been estimated or refined into tasks.
|
||||
Mark them for refinement:
|
||||
|
||||
1. [Select each issue's card](../../user/project/issue_board.md#edit-an-issue) in the board and apply the `status::refine` label:
|
||||
1. In the **Labels** section of the sidebar, select **Edit**.
|
||||
1. From the **Assign labels** list, select the `status::refine` label.
|
||||
1. Select **X** next to **Assign labels** or select any area outside the label section.
|
||||
1. Drag the three stories into the desired upcoming sprint to assign the stories to the corresponding sprint timebox.
|
||||
|
||||
By this point in the tutorial, your **Backlog** board should look like this:
|
||||
|
||||
|
||||
|
||||
In practice, you will use this board to sequence many stories into upcoming iterations.
|
||||
When your backlog grows, and you have dozens of stories spanning multiple features, it can be helpful
|
||||
to enable [**Group by epic**](../../user/project/issue_board.md#group-issues-in-swimlanes) so you can
|
||||
view stories related to their corresponding feature epic.
|
||||
When stories are grouped, it's easier to sequence them into upcoming sprints.
|
||||
|
||||
### Sprint planning ceremony
|
||||
|
||||
With the backlog prepared, it's time to plan the upcoming sprint.
|
||||
You can use synchronous and asynchronous ways to facilitate sprint planning meetings in GitLab.
|
||||
|
||||
#### Synchronous planning
|
||||
|
||||
When it's time for your sprint planning ceremony, pull up the **Backlog** board with the team and
|
||||
work through each story.
|
||||
You should start planning for your next sprint on the last day of your current sprint.
|
||||
While discussing each issue:
|
||||
|
||||
- Review and collaborate on the acceptance criteria.
|
||||
You can capture this in the issue's description by using checklists or list items.
|
||||
- Further [break down the story into tasks](../../user/tasks.md#create-a-task) for each implementation step.
|
||||
- Estimate the issue's story point effort or complexity and set this value in the issue's **Weight** field.
|
||||
- After the team is satisfied with the scope of the issue and agrees on the story point value,
|
||||
apply the `status::ready` label to the issue:
|
||||
|
||||
1. In the **Labels** section of the sidebar, select **Edit**.
|
||||
1. From the **Assign labels** list, select the `status::ready` label.
|
||||
1. Select **X** next to **Assign labels** or select any area outside the label section.
|
||||
|
||||
After you've cycled through all the issues in the upcoming iteration, you're done with sprint planning!
|
||||
|
||||
Remember to incorporate your team's velocity into your sprint commitment.
|
||||
You can find the total number of story points (weight) allocated to each sprint at the top of each iteration list.
|
||||
It's also worth making sure story points that will likely roll over from the previous sprint.
|
||||
|
||||
#### Asynchronous planning
|
||||
|
||||
Instead of holding a synchronous meeting, use an issue to run your sprint planning.
|
||||
|
||||
Given the nature of asynchronous sprint planning, you should start this a few days before the end of
|
||||
the current sprint.
|
||||
Provide all team members the appropriate time to contribute and collaborate.
|
||||
|
||||
1. Open the **Backlog** issue board:
|
||||
1. On the left sidebar, select **Search or go to** and find your group.
|
||||
1. Select **Plan > Issue boards**.
|
||||
1. In the upper-left corner, select the dropdown list with the current board name.
|
||||
1. Select **Backlog**.
|
||||
1. In the list for the upcoming sprint, select **Create new issue** (**{plus-square}**).
|
||||
1. Enter the issue's title: `Release Planning`.
|
||||
1. Select **Create issue**.
|
||||
1. Open the issue and create a discussion thread for each story assigned to the upcoming sprint.
|
||||
|
||||
Append `+` to the issue URL to automatically unfurl the title.
|
||||
Append `+s` to the issue URL to automatically unfurl the title, milestone, and assignees.
|
||||
You can use the following template for these threads to create checkboxes:
|
||||
|
||||
```markdown
|
||||
## https://gitlab.example.com/my-group/application-b/-/issues/5+
|
||||
|
||||
- [ ] Acceptance criteria defined
|
||||
- [ ] Weight set
|
||||
- [ ] Implementation steps (tasks) created
|
||||
```
|
||||
|
||||
For example:
|
||||
|
||||
|
||||
|
||||
1. After every story has a thread, edit the issue description and [mention each team member](../../user/discussions/index.md#mentions).
|
||||
Mentioning team members automatically creates a to-do item for them in their respective [to-do lists](../../user/todos.md).
|
||||
1. Then, asynchronously, before the start of the upcoming sprint, team members should:
|
||||
|
||||
- Discuss each issue, ask questions, and collaborate to align on the acceptance criteria for each planned issue.
|
||||
- Use a reaction emoji such as `:one:`, `:two:`, and `:three:` to cast their vote on what the story point (weight) should be.
|
||||
If team members set different story point values, it's an excellent opportunity to discuss further until there is consensus.
|
||||
You can also average all the various reactions to align on what the story point will be.
|
||||
- Break down vertical slices (issues) into implementation steps (tasks).
|
||||
|
||||
1. As each story discussion concludes, update the issue with any changes to the acceptance criteria
|
||||
and set the story point value in the **Weight** field.
|
||||
1. After the story is updated, add the `status::ready` label to each issue.
|
||||
1. Then, to signal the planning for that vertical slice has been completed,
|
||||
[resolve each discussion thread](../../user/discussions/index.md#resolve-a-thread) in the planning issue.
|
||||
|
||||
## Tracking sprint progress
|
||||
|
||||
To visualize and manage the work during a sprint, teams can create a dedicated issue board representing
|
||||
the current sprint's scope.
|
||||
This board provides transparency into the team's progress and any potential blockers.
|
||||
Teams can also use iteration analytics for additional visibility through burndown charts.
|
||||
|
||||
### Create a board for your current sprint
|
||||
|
||||
In your group, create a new issue board titled **Current Sprint**:
|
||||
|
||||
1. On the left sidebar, select **Search or go to** and find your group.
|
||||
1. Select **Plan > Issue boards**.
|
||||
1. In the upper-left corner, select the dropdown list with the current board name.
|
||||
1. Select **Create new board**.
|
||||
1. Enter the new board's title: `Current Sprint`.
|
||||
1. Next to **Scope**, select **Expand**.
|
||||
1. Next to **Iteration**, select **Edit**.
|
||||
1. Below your iteration cadence, select **Current**.
|
||||
1. Select **Create board**.
|
||||
|
||||
The board is now filtered only to show issues assigned to the current iteration.
|
||||
Use it to visualize the team's progress in the active sprint.
|
||||
|
||||
Next, create label lists for all the statuses:
|
||||
|
||||
1. In the upper-right corner of the issue board page, select **Create list**.
|
||||
1. In the column that appears, under **Scope**, select **Label**.
|
||||
1. From the **Value** dropdown list, select one of the labels:
|
||||
|
||||
- `status::refine`: The issue needs further refinement before being developed.
|
||||
- `status::ready`: The issue is ready for development.
|
||||
- `status::in progress`: The issue is in development.
|
||||
- `status::review`: The issue's corresponding MRs are going through code review.
|
||||
- `status::acceptance`: The issue is ready for stakeholder acceptance and QA testing.
|
||||
- `status::done`: The issue's acceptance criteria have been satisfied.
|
||||
|
||||
1. Select **Add to board**.
|
||||
1. Repeat the previous steps for the other labels.
|
||||
|
||||
Then, as the sprint progresses, drag issues to different lists to change their `status::` label.
|
||||
|
||||
### View burndown and burnup charts for your sprint
|
||||
|
||||
It can be helpful to review the iteration report during the sprint.
|
||||
Iteration reports provide progress metrics and burndown and burnup charts.
|
||||
|
||||
To view your iteration report:
|
||||
|
||||
1. On the left sidebar, select **Search or go to** and find your group.
|
||||
1. Select **Plan > Iterations** and select an iteration cadence.
|
||||
1. Select an iteration.
|
||||
|
|
@ -44,7 +44,7 @@ SAST supports the following official analyzers:
|
|||
<html>
|
||||
<small>Footnotes:
|
||||
<ol>
|
||||
<li>These analyzers were [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/431123) in GitLab 16.9</a> and are planned for removal in 17.0. The <a href="https://gitlab.com/gitlab-org/security-products/analyzers/semgrep">Semgrep analyzer</a> is proposed as their replacement.</li>
|
||||
<li>These analyzers were <a href="https://gitlab.com/gitlab-org/gitlab/-/issues/431123">deprecated</a> in GitLab 16.9 and are planned for removal in 17.0. The <a href="https://gitlab.com/gitlab-org/security-products/analyzers/semgrep">Semgrep analyzer</a> is proposed as their replacement.</li>
|
||||
</ol>
|
||||
</small>
|
||||
</html>
|
||||
|
|
|
|||
|
|
@ -86,9 +86,7 @@ For more information about our plans for language support in SAST, see the [cate
|
|||
<li>The SpotBugs-based analyzer supports <a href="https://gradle.org/">Gradle</a>, <a href="https://maven.apache.org/">Maven</a>, and <a href="https://www.scala-sbt.org/">SBT</a>. It can also be used with variants like the <a href="https://docs.gradle.org/current/userguide/gradle_wrapper.html">Gradle wrapper</a>, <a href="https://grails.org/">Grails</a>, and the <a href="https://github.com/takari/maven-wrapper">Maven wrapper</a>. However, SpotBugs has <a href="https://gitlab.com/gitlab-org/gitlab/-/issues/350801">limitations</a> when used against <a href="https://ant.apache.org/">Ant</a>-based projects. You should use the Semgrep-based analyzer for Ant-based Java or Scala projects.</li>
|
||||
</ol>
|
||||
<ol>
|
||||
<li>
|
||||
These analyzers were <a href="https://gitlab.com/gitlab-org/gitlab/-/issues/431123">deprecated in GitLab 16.9</a> and are planned for removal in 17.0. The <a href="https://gitlab.com/gitlab-org/security-products/analyzers/semgrep">Semgrep analyzer</a> is proposed as their replacement.</li>
|
||||
</li>
|
||||
<li> These analyzers were <a href="https://gitlab.com/gitlab-org/gitlab/-/issues/431123">deprecated in GitLab 16.9</a> and are planned for removal in 17.0. The <a href="https://gitlab.com/gitlab-org/security-products/analyzers/semgrep">Semgrep analyzer</a> is proposed as their replacement.</li>
|
||||
</ol>
|
||||
</html>
|
||||
|
||||
|
|
|
|||
|
|
@ -10,6 +10,9 @@ DETAILS:
|
|||
**Tier:** Premium, Ultimate
|
||||
**Offering:** GitLab.com, self-managed, GitLab Dedicated. GitLab Duo Pro required.
|
||||
|
||||
NOTE:
|
||||
GitLab Duo Code Suggestions requires [GitLab 16.8](https://about.gitlab.com/releases/2024/01/18/gitlab-16-8-released/) and newer. Earlier GitLab versions not supported.
|
||||
|
||||
> - [Introduced support for Google Vertex AI Codey APIs](https://gitlab.com/groups/gitlab-org/-/epics/10562) in GitLab 16.1.
|
||||
> - [Removed support for GitLab native model](https://gitlab.com/groups/gitlab-org/-/epics/10752) in GitLab 16.2.
|
||||
> - [Introduced support for Code Generation](https://gitlab.com/gitlab-org/gitlab/-/issues/415583) in GitLab 16.3.
|
||||
|
|
|
|||
|
|
@ -9,27 +9,27 @@ module Gitlab
|
|||
GITLAB_HOSTED_RUNNER = 'gitlab-hosted'
|
||||
SELF_HOSTED_RUNNER = 'self-hosted'
|
||||
|
||||
def self.for_build(build, aud: DEFAULT_AUD, wlif: nil)
|
||||
new(build, ttl: build.metadata_timeout, aud: aud, wlif: wlif).encoded
|
||||
def self.for_build(build, aud: DEFAULT_AUD, target_audience: nil)
|
||||
new(build, ttl: build.metadata_timeout, aud: aud, target_audience: target_audience).encoded
|
||||
end
|
||||
|
||||
def initialize(build, ttl:, aud:, wlif:)
|
||||
def initialize(build, ttl:, aud:, target_audience:)
|
||||
super(build, ttl: ttl)
|
||||
|
||||
@aud = aud
|
||||
@wlif = wlif
|
||||
@target_audience = target_audience
|
||||
end
|
||||
|
||||
private
|
||||
|
||||
attr_reader :aud, :wlif
|
||||
attr_reader :aud, :target_audience
|
||||
|
||||
def reserved_claims
|
||||
super.merge({
|
||||
iss: Gitlab.config.gitlab.url,
|
||||
sub: "project_path:#{project.full_path}:ref_type:#{ref_type}:ref:#{source_ref}",
|
||||
aud: aud,
|
||||
wlif: wlif
|
||||
target_audience: target_audience
|
||||
}.compact)
|
||||
end
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ RSpec.describe Gitlab::Ci::JwtV2, feature_category: :secrets_management do
|
|||
let(:pipeline) { build_stubbed(:ci_pipeline, ref: 'auto-deploy-2020-03-19') }
|
||||
let(:runner) { build_stubbed(:ci_runner) }
|
||||
let(:aud) { described_class::DEFAULT_AUD }
|
||||
let(:wlif) { nil }
|
||||
let(:target_audience) { nil }
|
||||
|
||||
let(:build) do
|
||||
build_stubbed(
|
||||
|
|
@ -27,7 +27,7 @@ RSpec.describe Gitlab::Ci::JwtV2, feature_category: :secrets_management do
|
|||
)
|
||||
end
|
||||
|
||||
subject(:ci_job_jwt_v2) { described_class.new(build, ttl: 30, aud: aud, wlif: wlif) }
|
||||
subject(:ci_job_jwt_v2) { described_class.new(build, ttl: 30, aud: aud, target_audience: target_audience) }
|
||||
|
||||
it { is_expected.to be_a Gitlab::Ci::Jwt }
|
||||
|
||||
|
|
@ -61,16 +61,16 @@ RSpec.describe Gitlab::Ci::JwtV2, feature_category: :secrets_management do
|
|||
expect(payload[:aud]).to eq('AWS')
|
||||
end
|
||||
|
||||
it 'does not use wlif claim in the payload' do
|
||||
expect(payload.include?(:wlif)).to be_falsey
|
||||
it 'does not use target_audience claim in the payload' do
|
||||
expect(payload.include?(:target_audience)).to be_falsey
|
||||
end
|
||||
end
|
||||
|
||||
context 'when given an wlif claim' do
|
||||
let(:wlif) { '//iam.googleapis.com/foo' }
|
||||
context 'when given an target_audience claim' do
|
||||
let(:target_audience) { '//iam.googleapis.com/foo' }
|
||||
|
||||
it 'uses specified wlif in the payload' do
|
||||
expect(payload[:wlif]).to eq(wlif)
|
||||
it 'uses specified target_audience in the payload' do
|
||||
expect(payload[:target_audience]).to eq(target_audience)
|
||||
end
|
||||
end
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue