This epic is about delivering a MVC iteration for "Progressive Delivery" as described in https://about.gitlab.com/direction/cicd. That content is intentionally not duplicated here to avoid drift; this issue will focus on the MVC (first iteration) goals and deliverables. ## MVC Goals We want to put a stake in the ground with what we can legitimately describe as a progressive delivery workflow. We have a lot of the raw materials to deliver here, but they need to be considered and packaged in a way that makes sense with our vision described at https://about.gitlab.com/direction/cicd/#progressive-delivery. Quoting https://launchdarkly.com/blog/progressive-delivery-a-history-condensed/ for the key elements: > Release progression – progressively increasing the number of users that are able to see (and are impacted by) new features (e.g. Stage 1: visible to developers only; Stage 2: visible to developers and beta users; Stage 3: visible to more users; Stage n: visible to everyone) The core of this MVC will be enabling this _staged release progression_ idea of Progressive Delivery, taking advantage of existing features as much as possible: ## Proposal There are a couple key pieces that are still needed, in addition to feature flag capabilities we already have: - We need % rollout for feature flags - We need cookie-based access for feature flags Once we have these, the high level flow for a sample release progression under this model would start just like today. First, you develop normally using a Review App and MR in a branch and make sure everything is working there (this is existing, standard development process with Review Apps today.) Then using a [feature flag strategy](https://github.com/Unleash/unleash#activation-strategies), you can phase the rollout as follows: 1. Deploy new code to production with feature flag set to off, but with a feature flag strategy allowing for a special cookie to activate the feature 1. `Stage 1`: Developers interact with it through having their userid (https://gitlab.com/gitlab-org/gitlab-ee/issues/11459) in the feature flag user list 1. `Stage 2`: Developers add beta testers to the user id list, who then gain access 1. `Stage 3`: Use new % rollout feature (https://gitlab.com/gitlab-org/gitlab-ee/issues/8240) to add more and more users over time to see the new feature, while monitoring system behavior 1. `Stage 4`: Set feature flag status to all users to on. ### Additional Considerations This MVC will require a number of steps to be done manually for the first iteration, so we should ensure at least that the UX and documentation are clear. - Creating initial feature flag - Adding initial users to the feature flag testing group - Adding subsequent users to the feature flag testing group - Manually incrementing rollout - Setting feature flag to on We should also implement a `.gitlab-ci.yml` template to illustrate how this can be set up in a pipeline in a way that's clear. ### Future Improvements Additionally, automated monitoring that controls the `stage 3` decision to proceed (and/or timed incremental feature flag rollouts) would be interesting, but are out of scope for the MVC.