Deploy Boards are available in Core
As part of an effort to open source some currently paid features and move them to our free tier "Deploy Boards" have been identified as a feature worth moving down.
Deploy Boards should be moved to Core. This requires the removal of any licensing checks for the feature which is currently in the Premium tier.
- Canary visualization will also need to move to Core since track:canary is included in the deploy board I am linking these two issues.
Deploy Boards offer a consolidated view of the current health and status of each CI environment running on Kubernetes, displaying the status of the pods in the deployment. Developers and other teammates can view the progress and status of a rollout, pod by pod, in the workflow they already use without any need to access Kubernetes.
Earlier this year GitLab committed to moving 18 features to our open source core product. With this release of GitLab we've completed the work to move Deploy Boards to Core. We're excited about bringing these features to more users and seeing what use cases and workflows you're able to use them for.
We can follow the same template
- Try moving everything as a trial
- Move backend that does not depend on license check
- Remove license check from EE
- Move backend pieces in chunks determined by engineer
- Move frontend in one piece
- Update docs
Trial run of moving to core...
Gitlab::Kubernetes::RolloutStatusis entry point
Environment#rollout_statuscan be moved safely, I think
#calculate_reactive_cache_forfrom ee/app/models/ee/clusters/platforms/kubernetes.rb to core. I think it can be done safely
- ee/app/serializers/clusters/environment_entity.rb is not applicable so this should be left in EE
- mock_deployment service can be moved safely I think
What do we with canary ingress ?
canary_ingress attribute (!43816 (merged))
Based on #218139 (comment 421093605), I think we move this to Core too.
Both issues should follow the tiering of deploy boards and canary respectively
What do we do with canary deploy borads ?
- We can either move canary deploy boards to Core.
- We can keep canary deploy boards in Premium
We prefer option 1, because otherwise we have invent a new licensed feature for canary deploy boards
For clarify, "canary deploy boards" refers to the "yellow dot" in deploy boards.
Projects::EnvironmentsController#index returns the JSON to serve the data in the
rollout_status attribute. Example, see https://gitlab.com/gitlab-org/gitlab/-/environments, open Network in Dev tools
ee/app/serializers/ee/environment_entity.rb is probably the last thing we move
In theory, it should be safe to move all FE to core as we already handle the
rollout_status not being present for Stater licenses
- JSON returns
- environment_alert.vue, environment.query.graphql is not relevant, it's for incidents/alerts
- deploy_board_component.vue, and constants.js, environments_store.js
- delete canary_deployment_callout.vue as seems un-needed in core
Documentation for this feature should be updated to reflect that this is no longer in a paid tier.
- Documentation: https://docs.gitlab.com/ee/user/project/deploy_boards.html
- Issue that Implemented the feature: #1589 (closed)
Example of a Deploy Board
Definition of Done
Move backend, except exposing the
- Move frontend - it should be safe to move most things
Remove license check and expose
- add a note to https://gitlab.com/groups/gitlab-com/packaging-and-pricing/-/epics/1
@kencjohnstonon #s_configure once the issue is closed