Skip to content
GitLab Next
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • GitLab GitLab
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 43,148
    • Issues 43,148
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 1,404
    • Merge requests 1,404
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.org
  • GitLabGitLab
  • Issues
  • #212320
Closed
Open
Created Mar 14, 2020 by Xiaohe Li@xli10 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.

  • Documentation: https://docs.gitlab.com/ee/user/project/deploy_boards.html
  • Issue that Implemented the feature: #1589 (closed)

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

  • add a note to https://gitlab.com/groups/gitlab-com/packaging-and-pricing/-/epics/1
  • Ping @kencjohnston on #s_configure once the issue is closed
Edited Dec 08, 2020 by Viktor Nagy (GitLab)
Assignee
Assign to
Time tracking