You can now link directly to a deployment page within GitLab. Until now, if you were collaborating on a deployment, you had to look up the deployment from the deployment list view. This approach was error prone as identifying a deployment was like searching for a needle in a haystack.
Finally, GitLab offers a deployment details view that you can link to directly. In this first version, the deployment details page offers an overview of the deployment job and the possibility to approve, reject or comment on a deployment in a continuous delivery setting. We are looking into further avenues to enhance the deployment details page, and are working on linking to it, instead of the list view, from the related pipeline job.
Users can view detailed information about a specific deployment in its own page.
Proposal
MVC Proposal: Move and/or add the deployment approval action workflow and history into its own page. This can be the first iteration of the new deployment detail page.
This MVC idea came from a recent Release Stage brainstorm session discussing Deployment Detail Page (or Deployment Request s... (#360503). We decided that moving the deployment approval workflow from the Environments Page into its deployment detail page would be a great MVC for the larger Deployment Detail page feature since it is critical functionality and it makes sense for it to exist on a deployment specific page. We can then iterate on the page and continue to add more deployment specific information.
Permissions and Security
Documentation
Availability & Testing
Available Tier
Feature Usage Metrics
MAU of the deployment detail page.
What does success look like, and how can we measure that?
The deployment detail page is easily discoverable, relevant to users, and is actually used regularly.
What is the competitive advantage or differentiation for this feature?
We can build differentiation by connecting to other GitLab features natively, e.g. Issues, Monitoring, etc.
Links / references
This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
@emilybauman - I've added the UI text label to this issue (which already has the documentation label) to highlight that I'll likely be involved in both activities.
All SUS-impacting issues need to have a proper severity label set.
Please add a severity label, remove the automation:ux-missing-labels label, and then reply to this comment briefly explaining your reasoning for providing this severity.
If you are not the DRI for this area and would like help determining the best severity, please @ the appropriate person for assistance.
@cbalane - I'm starting to take a look at this issue and wanted to break down into the different versions of this page we will need. Let me know if this makes sense:
Needs all approvals (show a page with a deployment that requires all approvals, deployment is blocked until approvals are finished)
Some approvals have happened, but some are still pending (some comments and approvals are shown, but deployment is still blocked).
All approvals done, deployment pending (2 versions of this, one for executors to click deploy and one for anyone else who wants to see the status of the deployment).
Deployed with Approval and comment history.
Additionally we will need to confirm entry links to this page, my thoughts are for MVC we simply link through the approvals option button.
To confirm things that are out of scope: Versions of this page that do not require approvals (non-protected environments) and selecting approvers are both not in scope for this.
As a first iteration, I tried to move all information from the approval modal and the deployment widget into the page. Let me know your thoughts. I've left open sections for us to work on the select approvers flow later.
@emilybauman Thanks! This mockup is very helpful to start discussions. I have one question about the direction:
Should we define the concept and scope of this page more explicitly? Deployment Details page seems too generic to understand what's expected to happen in the page, therefore it might not sound right in the user workflow. For example, we can consider naming this page as "Deployment Request" page that requests a deployment to a specific environment, similar to merge requests.
To validate the concept of this page, I'd suggest brainstorming the usecases from two different angles/roles:
DRI of the deployment - the one who is planning to execute it
Personas: SREs/Operators/Release managers
Can the user see whether the deployment is ready to be executed or blocked?
Can the user see who is allowed to approve the deployment?
Can the user ping and have discussions with an approver?
Can the user execute the deployment after it's unblocked?
A reviewer of the deployment - the one who is approving it
Personas: Stable counter-parts, such as Security engineer and QA tester
Can the user see why the user is looped in the page for what purpose?
Can the user see what's changed since the last deployment? (i.e. commit diff, included MRs)
Can the user have discussions with DRI before making a decision?
Thanks for the conversation here @shinya.maeda, and that's exactly why I got a visual up so we could start chatting about it!
Should we define the concept and scope of this page more explicitly? Deployment Details page seems too generic to understand what's expected to happen in the page, therefore it might not sound right in the user workflow.
My thoughts are initially we can use this page for deployment approvals (pretty much an expanded out version of the modal). We could then test this against the modal in some user tests to ensure that the switch makes sense before we put any development energy into it. Keep MVC scoped very small so we don't actually do anything "new" on this page yet. If we see success, we could start exploring with different iterations (request approval flow etc).
For example, we can consider naming this page as "Deployment Request" page that requests a deployment to a specific environment, similar to merge requests.
I like the idea of renaming the page to something that makes a bit more sense with the workflow. Deployment Request makes sense, but also would love to pull @rdickenson in.
To validate the concept of this page, I'd suggest brainstorming the usecases from two different angles/roles:
Yes I think these work well. I've added in a few additional points we might want to test for, but I'm open to suggestions:
For DRI:
Can the user see whether the deployment is ready to be executed or blocked?
Can the user who is allowed to approve the deployment?
Can the user ping and have discussions with an approver?
Can the user see who has approved so far?
Can the user execute the deployment after it's unblocked?
Can the user see the new status of the deployment?
For Approver:
Can the user navigate to the page in the current workflow?
Can the user see why the user is looped in the page for what purpose?
Can the user see what's changed since the last deployment? (i.e. commit diff, included MRs)
Can the user have discussions with DRI before making a decision?
Can the user approve/reject a deployment?
I'll go ahead and open a solution validation issue around this page as well, once we've finalized on a design we'll probably want to put it in front of users and run them through some of the above scenarios. FYI @wleidheiser@cbalane
@emilybauman - I somehow lost this comment previously, so I'm going by memory.
It seems the request's status is shown in several elements. We have "Waiting", "Needs approval", "Deployment waiting...". Which of these elements definitely indicates the request's status?
Could the "Deployment waiting..." element be moved to below the "Merge branch" element? I think it would communicate: "Here are all the request's details, and this is its current status. Read on for more details."
Why are there two sets of approval and rejection buttons? One set allows for comment, but the duplication concerns me.
@rdickenson - No worries at all - thanks for jumping in!
It seems the request's status is shown in several elements. We have "Waiting", "Needs approval", "Deployment waiting...". Which of these elements definitely indicates the request's status?
To be honest I just grabbed these off the deployment info from the environment index page when something is pending approval. I agree, I think the entire top part could be rethought a bit better to make statuses a lot more clear.
Could the "Deployment waiting..." element be moved to below the "Merge branch" element? I think it would communicate: "Here are all the request's details, and this is its current status. Read on for more details."
Would this mean bringing it above the approver area? I was trying have the page read in order, but I agree it somewhat gets lost in the flow! I'll ideate a bit more on how to accurately show statuses.
Why are there two sets of approval and rejection buttons? One set allows for comment, but the duplication concerns me.
I was originally just trying to copy the CTAs in the modal, but taking a step back this does look a bit weird and confusing. We'll probably also want an option just to "comment". I'll adjust this in the next iteration! Thanks for the feedback.
By the way, @emilybauman , from the mockup above I don't see an option to leave a comment without approving or rejecting the deployment. In the UX Flow it is mentioned, that a user should be able to just leave a comment, so absence of Comment button must be an oversight, right?
@andrei.zubov Oversight on my part, whoops
I was using the CTAs in the modal and forgot to change one to simply "comment". I'll be adjusting for the final prototype.
Additional thoughts - @afontaine@andrei.zubov I know we have some scheduled issues to enhance the modal. Do you see any of those efforts going to waste if we move forward with this as a page?
Good to know, thanks @afontaine - @cbalane what do you think is the best plan to go ahead with in terms of these two issues? I don't want Andrew having to do throw away work, if we think we can get this scheduled in in the next few milestones.
@emilybauman sure, let's close for now since our intended direction is the Deployment Details page. we can always reopen or create a new issue if needed
For MVC, let's simplify the comment section to remove the markdown support and keep it more in line with what we see in the modal. We can open up a new issue around enhancing the comment box and adding the ability to reply to other comments.
Removed the box around how many approvals is left, and the box around the deployment waiting for approvals.
Remove items out of the deployment history except for comments.
MVC Proposal
Tested Version
Does this seem like it captures everything? I'll have to adjust the flow to match when I am back from PTO.
I noticed the Environment name is not present (as fr as I can tell?) in the MVC. I think we need this (even if it's in the top nav breadcrumbs) unless there's a reason we decided not to include it.
Edge case: are more approvals than the required amount allowed?
@cbalane As Deployment Details Page MVC is related to Deploy Approval, and I know we are moving our focus away from this over the next milestone what is the best way to proceed with this issue? I was going to clean it up in 15.10, but unsure that's the best way to go now
We did a lot of work to validate this, so I'd hate for it to be throw away.
@emilybauman I'll have to defer to @nagyv-gitlab. I think it's a still a good idea to do at some point but Viktor will have to set the priority. My thoughts, if there's capacity, it could be good to finish cleaning it up (if it doesn't take too long) so that it's ready if/when we want to do it.
Is there something we should show when a project doesn't have deploy approvals available? a CTA? We can keep the status portion is ready to deploy, etc., but the page is pretty empty without a review area.
Is there something we should show when a project doesn't have deploy approvals available? a CTA? We can keep the status portion is ready to deploy, etc., but the page is pretty empty without a review area.
@afontaine - My first thought would be just to keep things simple and follow our goal of replacing the modal which doesn't show up for Free tier at the moment, BUT - I wonder if we could experiment with this page as an acquisition funnel in the future (prompting them to upgrade to get approvals)?
New MR up at !143102 (merged), adds the sidebar portion of the MVC UI
2 more MRs will be required:
Adding the approval table
Adding the approval comments
This week I've been tasked with some investigation regarding Cells, so I
expect there will be more progress on the above two MRs in the back half
of the week. As it is, the current MR will be moved along through the
review process.
...
--
Andrew Fontaine
Senior Frontend Engineer, Deploy::Environments @ GitLab
It's not looking great to get the comments in by code cut off on Friday,
but that final MR should be in review by EOD Friday, and we can start
rolling the flag out on .com by %16.10
I am also the refinement DRI this week, so that is taking up some time,
but we should be nearly nearly there and ready to start turning things
on in or just before %16.10.
...
--
Andrew Fontaine
Senior Frontend Engineer, Deploy::Environments @ GitLab