Incubation Engineering Maturity Stages

This guide provides guidelines and best practices for how to properly position an Incubation Engineering project, and what needs to be accomplished in order for a project to mature from Experiment to Beta to Generally Available.

Establish an Experiment

The first step when releasing the first iteration for an Incubation Engineering project is to establish the experiment. See the documentation for more details on what makes a GitLab Experiment.

To establish an experiment, ensure that the feature being released has:

1. A documentation page or blog post, that reflects that the feature is subject to the GitLab Testing Agreement.
2. An experiment badge in the UI.
3. A UI for users to enable/disable the feature. This UI should also link to the GitLab Testing Agreement.
4. A feedback issue (example) or feedback project (example) so user can easily provide feedback and bug reports.

Be sure not to include this feature in a release post until it is mature enough to be classified as a Beta feature.

Graduate from Experiment to Beta

Once an experiment has matured sufficiently and the SEG is confident the feature is stable, unlikely to cause data loss, and the interface is unlikely to drastically change, the feature should be moved to Beta. See the documentation for expectations of a Beta feature.

To move an experiment to Beta, the following items should be in place:

1. Any monitoring and alerting to ensure that any availability issues are captured. Use logging or event tracking and build dashboards from the data received.
2. Runbook entries are added if necessary in order to support SRE in the event of availability issues.
3. All data for this feature should be included in the backup and restore processes.
4. Any feature flags should be on by default, or better yet removed completely.
5. Update the experiment badge to a beta badge in the UI.
6. Documentation must exist (blog posts aren’t sufficient), and the documentation should reflect beta status.
7. Sufficient support materials should exist so that Support teams have the resources necessary to help customers with issues.
8. One or more release post items.

Graduate from Beta to Generally Available (GA)

The final maturity step for a feature is to move to Generally Available (GA). See the documentation for expectations of a GA feature.

A feature that is ready for GA will have:

1. Passed a Production Readiness Review
2. Completed a design review and all UIs are in line with GitLab’s design guidelines.
3. Full documentation in line with GitLab’s documentation style guide.
4. Full support documentation and is fully supported by the customer service team.