Skip to content

Show deployment status in the environment page

Problem to solve

As a user, I want to know that there is a deployment going on in my environment.

Intended users

User experience goal

The user will be able to know the status of a deployment directly from the environment page

Proposal

  • Add the deployment status to the deployment column of /environments page for each row.
    • The deployment status and deployment ID, plus author will either reflect the latest successful deployment or one which is in progress.
    • The deployment status will be displayed with a single status icon positioning after the deployment ID
    • The deployment author will be positioned on a second line below the deployment ID and status.
    • The deployment status will link towards the deployment job responsible (similar to the environment detail page)
    • Canceled or failed deployments will not show as these do not represent what is present in the environment.
    • The deployment status will feature a tooltip stating Deployment <status>:
      • Running Deployment in progress
      • Success: Deployment successful
  • When an "upcoming" deployment exists, update the Job and Commit columns to point to the new deployment's job ID and commit info.
Mockup (Browser made)
image

Background: Current vs Upcoming deployments

In environment index page, the most essential information for operators/RMs/SREs is the current deployment on the environment (or sometimes we refer it as last or last successful deployment). Today, we show it, and on top of that there are some advanced metrics or controls on the current deployment. For example:

  • Is there any critical alerts caused by the current deployment? => We show alerts in footer.
  • Can I monitor how the current deployment is performing on the environment? => Click "Monitoring" button
  • Can I see the website of the current deployment? => Click "Open live environment" button.
  • Can I stop the environment? => Click "Stop environment" button. Important note: this automatically triggers a corresponding stop job in the same pipeline with the current deployment job. Given current and upcoming deployments run in different pipelines, this makes a similar confusion @nfriend pointed above.
  • Can I re-deploy the current deployment? => Click "Re-deploy to environment" button.
  • and more

So almost all of the features on this environment index page were designed for the current deployment, which is what actually exists on the environment. We should keep the current UX, otherwise we need to revisit the concepts of the above features for running deployment, just like a proposal to hide button suggested by @nfriend. We need to do similar follow-up for the rest of the features as well, which probably we cannot afford.

The main purpose of this issue is showing a complementary information about "what's the next deployment?". The next deployment job could be a manual job that is waiting for operators executing the job, or it could be a scheduled job that will be automatically executed after a specific period, or it could be a normal job that will be executed after an upstream stage jobs have finished, or it could be being deployed (i.e. running) by one of the above paths. I'm referring these type of deployment jobs as "upcoming deployments", but please let me know if there is a better terminology.

Now, this issue should be fairly easy to be accomplished if we simply add a new column, because it doesn't affect the current behavior thus require no follow-ups. For the MVC sake, this issue targets only running status as a upcoming deployment, however, I believe this feature should be extended as above.

Payload change

We'll change the environments.json payload to have last_deployment and upcoming_deployment per environment. The upcoming_deployment payload is formatted in the same schema with last_deployment.

This upcoming_deployment is selected by the following criteria:

  • Deployments with running status.
  • Newer deployment object than the latest/current deployment.
  • When there are multiple candidates, the latest one is returned i.e. the largest deployments.id.
  • If there is no relevant record, it returns nil or the key doesn't exist in the hash.

A few notes:

  • It only contains necessary data to present the UI and excludes some unnecessary metadata such as manual_actions, scheduled_actions to save up some payload size.

Further details

The user currently has no way of knowing that a deployment is in progress when viewing the environment page. This is super useful with the connectivity of showing alerts in the environment page as this will give the user an indication of what action they can take during an alert. Stop a rollout that is in progress or rollback for a deployment that has completed

More detailed Upcoming deployments (Next iteration)

An upcoming deployment should be selected by the following order:

  1. If there is a running deployment job, the deployment job is selected.
  2. If there is a scheduled deployment job (i.e. when: delayed), the deployment job is selected.
  3. If there is a manual deployment job (i.e. when: manual), the deployment job is selected.
  4. If there are no relevant deployment jobs, it shows empty.

Breakdown

  • frontend to display the badges (this will already show the statuses that are currently provided by the BE) behind a feature flag (type development)
  • backend to provide the additional statuses

Permissions and Security

Documentation

Availability & Testing

What does success look like, and how can we measure that?

What is the type of buyer?

Is this a cross-stage feature?

Links / references

Edited by Shinya Maeda