The current behavior of deployment approval is that an already approved deployment can be rerun after the approval is given. This may be not desired a concern both from a security/auditing standpoint as well as allowing the possibility of deploying older code to production.
Proposal
Don't allow deployment pipelines to be rerun without getting the necessary approvals.
Hey @cbalane - Can we do a run-through of the current experience sync? Perhaps next week in our 1:1?
I want to have a better understanding of the flow before I start ideating on it.
@cbalane - I was taking another look at this and just wanted to understand the problem a bit better before I hop into designing a flow.
Is this a setting we want to give users with flexibility to customize, or something that we expect all users would want? If it's a setting, we could allow them to enable or disable this in the protected environments settings page.
I assume we don't need to do much new UX for the actual flow, we would just show the waiting status with pending approval when a deployment is re-run?
Deployment runs successfully without any approvals.
Proposed experience:
User runs a deployment that needs approval.
Deployment blocked until approval is given.
Approval given.
Deployment runs successfully.
User re-runs deployment.
Deployment blocked until approval is given.
Approval given.
Deployment runs successfully.
@cbalane and I noted that for MVC this will be the default experience, if we need to it as a setting this can be a followup later on depending on user feedback. I'll work on the experience today and hopefully close it off by eow.
@cbalane - I chatted with @afontaine and @andrei.zubov and this one is good to go from a UX perspective. First iteration will be simple, just blocking the deployment and prompting for approvals again.
We have a few improvements we can make to it in the future (potentially when the Deployment Details Page is live), so I can go ahead and collect those in a follow-up issue. Let me know if you have any questions. If not we can move this into workflowplanning breakdown
When a deployment executor rollback/re-deploy to a previous deployment, it should require approvals again, however, the previous approvals are still remaining and effective so the deployment executor can skip the process.
I've tested the Deployment Approval functionality a bit, and it looks very promising but I have a bit of an issue. I want to use approvals to protect from accidental deployments by requiring more than one person to be involved. But when an approval is given, the approved job can then be re-run at any later time without requiring a new approval (seemingly because this job is now approved). But this can be intrusive if the deployment process is not seamless and invisible.
Is there a way to limit an approval so a job can be run only once, and then require approval again, or is this perhaps a feature that could be considered?
We would also want this feature. Allowing anyone to re-deploy an old version that was previously approved is a security risk since the old version might have a known bug/issue.
On that note, also being able to mark a deployment as borked would be neat, but not as important as long as each deployment requires an approval.
@cbalane@shinya.maeda - I think when we discussed MVC for this however, the previous approvals are still remaining and effective so the deployment executor can skip the process. was out of scope as we were just going to apply this to all deployments that needed to be re-run.
Do you think we need to include this flow as well for the first iteration?
@cbalane@emilybauman I think one challenge in this issue is how to keep all of the approval/execution history for audit purpose. For example, users should see the following timeline:
A deployment is blocked. Needs approvals.
User-A, User-B approved. The deployment executed.
The deployment is retried and blocked again. Needs approvals.
User-A, User-B approved. The deployment re-run.
Today, backend doesn't have a capability to preserve these history, meaning 1) and 2) will be gone. This should be covered in the timeline feature in Deployment Details page.
@shinya.maeda - Yes I was struggling with how to show this in the current modal as well, since we are running pretty low on room to begin with.
@andrei.zubov and I were discussing in #375512[Final_Flow_of_Experience.png] around showing approval history, and landed on it probably makes sense for the Deployment Request Page as well since we have a lot more real estate to work with. Open to suggestions though (we could collapse these details into the modal until then, but I'm unsure if that would be throw-away work).
can we just consider the re-run a new deployment if the re-run button is triggered?
That was going to be my proposal for MVC, and then in the deployment request page show the full timeline. So we can move ahead with this without being blocked by the page. Unless it's necessary for audit reasons.
@emilybauman and I tested the case above and it works as the proposed experience - retry creates a new deployment that requires a new approval. @shinya.maeda are there any other test cases we should check?
This seems like a bad idea in the fact that if your rolling back to previous known good deploy which was already approved. Now you have to wait to get approvals to deploy while the application is down.
Could this be a configurable option like Allow pipeline triggerer to approve deployment.