Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
G
gitlab-ce
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
Analytics
Analytics
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Commits
Issue Boards
Open sidebar
Boxiang Sun
gitlab-ce
Commits
e113671f
Commit
e113671f
authored
Aug 15, 2018
by
Zeger-Jan van de Weg
Committed by
Robert Speicher
Aug 15, 2018
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Add Acceptance testing issue template
parent
085ed286
Changes
3
Hide whitespace changes
Inline
Side-by-side
Showing
3 changed files
with
135 additions
and
2 deletions
+135
-2
.gitlab/issue_templates/Acceptance_Testing.md
.gitlab/issue_templates/Acceptance_Testing.md
+100
-0
app/models/namespace.rb
app/models/namespace.rb
+1
-1
doc/development/feature_flags.md
doc/development/feature_flags.md
+34
-1
No files found.
.gitlab/issue_templates/Acceptance_Testing.md
0 → 100644
View file @
e113671f
## Details
-
**Feature Toggle Name**
:
`FEATURE_NAME`
-
**Required GitLab Version**
:
`vX.X`
--------------------------------------------------------------------------------
## 1. Preparation
-
[ ]
**Controllers and workers**
:
1.
Please link to dashboards of the workers, and the controllers and actions that can be impacted
2.
...
3.
...
## 2. Development Trial
#### Check Dev Server Versions
-
[ ] GitLab: https://dev.gitlab.org/help
#### Enable on `dev.gitlab.org`:
-
[
] `/chatops feature set FEATURE_NAME true --dev` in [`#dev-gitlab`
](
https://gitlab.slack.com/messages/C6WQ87MU3
)
Then leave running while monitoring and performing some testing through web, api or SSH.
#### Monitor
-
[
] [Monitor Using Grafana
](
https://dashboards.gitlab.net
)
-
[
] [Inspect logs in ELK
](
https://log.gitlab.net/app/kibana
)
-
[
] [Check for errors in GitLab Dev Sentry
](
https://sentry.gitlap.com/gitlab/devgitlaborg/?query=is%3Aunresolved
)
## 2. Staging Trial
#### Check Staging Server Versions
-
[ ] GitLab: https://staging.gitlab.com/help
#### Enable on `staging.gitlab.com`
-
[
] `/chatops run feature set FEATURE_NAME true --staging` in [`#development`
](
https://gitlab.slack.com/messages/C02PF508L/
)
Then leave running while monitoring for at least
**15 minutes**
while performing some testing through web, api or SSH.
#### Monitor
-
[
] [Monitor Using Grafana
](
https://dashboards.gitlab.net
)
-
[
] [Inspect logs in ELK
](
https://log.gitlab.net/app/kibana
)
-
[
] [Check for errors in GitLab Sentry
](
https://sentry.gitlap.com/gitlab/gitlabcom/?query=is%3Aunresolved
)
## 4. Production Server Version Check
-
[ ] GitLab: https://gitlab.com/help
## 5. Initial Impact Check
-
[ ] Enable for a subset of users, when using percentage gates: 1%.
Then leave running while monitoring for at least
**15 minutes**
while performing some testing through web, api or SSH.
#### Monitor
-
[
] [Monitor Using Grafana
](
https://dashboards.gitlab.net
)
-
[
] [Inspect logs in ELK
](
https://log.gitlab.net/app/kibana
)
-
[
] [Check for errors in GitLab Sentry
](
https://sentry.gitlap.com/gitlab/gitlabcom/?query=is%3Aunresolved
)
## 6. Low Impact Check
-
[ ] Enable for a bigger subset of users, when using percentage gates: 10%.
Then leave running while monitoring for at least
**30 minutes**
while performing some testing through web, api or SSH.
#### Monitor
-
[
] [Monitor Using Grafana
](
https://dashboards.gitlab.net
)
-
[
] [Inspect logs in ELK
](
https://log.gitlab.net/app/kibana
)
-
[
] [Check for errors in GitLab Sentry
](
https://sentry.gitlap.com/gitlab/gitlabcom/?query=is%3Aunresolved
)
## 7. Mid Impact Trial
-
[ ] Enable for a big subset of users, when using percentage gates: 50%.
Then leave running while monitoring for at least
**12 hours**
while performing some testing through web, api or SSH.
#### Monitor
-
[
] [Monitor Using Grafana
](
https://dashboards.gitlab.net
)
-
[
] [Inspect logs in ELK
](
https://log.gitlab.net/app/kibana
)
-
[
] [Check for errors in GitLab Sentry
](
https://sentry.gitlap.com/gitlab/gitlabcom/?query=is%3Aunresolved
)
## 8. Full Impact Trial
-
[ ] Enable for all users:
`
/chatops run feature set FEATURE_NAME true
Then leave running while monitoring for at least
**1 week**
.
#### Monitor
-
[
] [Monitor Using Grafana
](
https://dashboards.gitlab.net
)
-
[
] [Inspect logs in ELK
](
https://log.gitlab.net/app/kibana
)
-
[
] [Check for errors in GitLab Dev Sentry
](
https://sentry.gitlap.com/gitlab/devgitlaborg/?query=is%3Aunresolved
)
#### Success?
-
[ ] Remove the feature gate from the code, and close this issue with that MR.
app/models/namespace.rb
View file @
e113671f
...
...
@@ -10,6 +10,7 @@ class Namespace < ActiveRecord::Base
include
Storage
::
LegacyNamespace
include
Gitlab
::
SQL
::
Pattern
include
IgnorableColumn
include
FeatureGate
ignore_column
:deleted_at
...
...
@@ -124,7 +125,6 @@ class Namespace < ActiveRecord::Base
def
to_param
full_path
end
alias_method
:flipper_id
,
:to_param
def
human_name
owner_name
...
...
doc/development/feature_flags.md
View file @
e113671f
...
...
@@ -20,7 +20,40 @@ dynamic (querying the DB etc.).
Once defined in
`lib/feature.rb`
, you will be able to activate a
feature for a given feature group via the
[
`feature_group` param of the features API
](
../api/features.md#set-or-create-a-feature
)
For GitLab.com, team members have access to feature flags through chatops. Only
percentage gates are supported at this time. Setting a feature to be used 50% of
the time, you should execute
`/chatops run feature set my_feature_flag 50`
.
## Feature flags for user applications
GitLab does not yet support the use of feature flags in deployed user applications.
You can follow the progress on that
[
in the issue on our issue tracker
](
https://gitlab.com/gitlab-org/gitlab-ee/issues/779
)
.
\ No newline at end of file
You can follow the progress on that
[
in the issue on our issue tracker
](
https://gitlab.com/gitlab-org/gitlab-ee/issues/779
)
.
## Developing with feature flags
In general, it's better to have a group- or user-based gate, and you should prefer
it over the use of percentage gates. This would make debugging easier, as you
filter for example logs and errors based on actors too. Futhermore, this allows
for enabling for the
`gitlab-org`
group first, while the rest of the users
aren't impacted.
```
ruby
# Good
Feature
.
enabled?
(
:feature_flag
,
project
)
# Avoid, if possible
Feature
.
enabled?
(
:feature_flag
)
```
To use feature gates based on actors, the model needs to respond to
`flipper_id`
. For example, to enable for the Foo model:
```
ruby
class
Foo
<
ActiveRecord
::
Base
include
FeatureGate
end
```
Features that are developed and are intended to be merged behind a feature flag
should not include a changelog entry. The entry should be added in the merge
request removing the feature flags.
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment