Skip to content

GitLab Next

Closed
Created by Xiaohe Li@xli1Developer0 of 5 tasks completed0/5 tasks

Deploy Boards are available in Core

Overview

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.

Release notes

https://docs.gitlab.com/ee/user/project/deploy_boards.html

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.

Proposal

We can follow the same template

  1. Try moving everything as a trial
  2. Move backend that does not depend on license check
  3. Remove license check from EE
  4. Move backend pieces in chunks determined by engineer
  5. Move frontend in one piece
  6. Update docs

Trial run of moving to core...

Backend

  • Gitlab::Kubernetes::RolloutStatus is entry point
  • Environment#rollout_status can be moved safely, I think
  • Move #rollout_status, and #calculate_reactive_cache_for from 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 ?

  1. We can either move canary deploy boards to Core.
  2. 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.

API

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

Frontend

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

ee/app/assets/javascripts/environments contains files we want to move

  • JSON returns stable attribute which determines if pod is styled as canary or not, see ee/app/assets/javascripts/vue_shared/components/deployment_instance.vue
  • environment_alert.vue, environment.query.graphql is not relevant, it's for incidents/alerts

Move order:

  1. stores/helpers.js
  2. deploy_board_component.vue, and constants.js, environments_store.js
  3. delete canary_deployment_callout.vue as seems un-needed in core

Documentation

Documentation for this feature should be updated to reflect that this is no longer in a paid tier.

Example of a Deploy Board

https://gitlab.com/gitlab-services/version-gitlab-com/-/environments

Definition of Done

  • Move backend, except exposing the rollout_status attribute
  • Move frontend - it should be safe to move most things
  • Remove license check and expose rollout_status attribute.

Follow-ups

When done

Edited by Viktor Nagy