search

silverstripe-archive / deploynaut

A web based tool for performing deployments
BSD 3-Clause "New" or "Revised" License
71 stars 26 forks source link

Pipelines has no indication that release has been rolled back #101

Closed ss23 closed 9 years ago

ss23 commented 9 years ago

This release was rolled back, but it shows as "Finished" in the release overview. The deployment log also shows as successful, presumably another step in the pipeline failed? Its confusing to lack that indication, and show the SHA that has been rolled back to.

cc @chillu

tractorcow commented 9 years ago

Well, the release itself is only a part of a pipeline, and it's not a "bug" for it to display itself as finished if it is. The release shouldn't care if it's a part of a pipeline or not.

As I noted on https://github.com/silverstripe/deploynaut/issues/100 the real solution to this problem is to have a proper pipeline history list similar to the snapshot / deployment logs.

chillu commented 9 years ago

I think having a failed release represented with a green finished label is misleading. I'd say there either needs to be a way for individual pipeline steps to mark the whole pipeline as failed, or customize the shown status in the overview (e.g. to "rolled back").

Listing failed pipelines separately (#100) is also needed, but doesn't change the fact that a listed release shouldn't show as "all good" when its actually failed.

tractorcow commented 9 years ago

I don't agree. A deployment in itself (which is only a tiny part of the pipeline) can still be successful, even if another part of the pipeline (e.g. smoketesting) fails. Subsequent steps don't fail previous steps, but they do fail the pipeline as a whole, which is where the information relevant to the actual user resides. The deployment itself shouldn't be reporting on the status of objects which OWN it, it should only report on itself.

The problem is that you are looking at the atomic operation and viewing it as the entire release process. Pre-pipelines, the deployment WAS the whole process so it made sense then. Now it doesn't, so it doesn't make sense to continue to use that as the basis for determining success.

Look at it this way, if you run a triathlon and fail to complete the third leg (running), that means that you fail the race as a whole, but that doesn't mean you never completed the cycling or swimming bits. You still suck, but maybe not at everything.

It would make more sense to do away with the whole current deployment history UI altogether, and show the history grouped by pipeline, which shows the user the overview of the process, along with the status of each individual step.

I'd say there either needs to be a way for individual pipeline steps to mark the whole pipeline as failed

that's actually what currently happens.

chillu commented 9 years ago

A deployment in itself (which is only a tiny part of the pipeline) can still be successful, even if another part of the pipeline (e.g. smoketesting) fails.

But it isn't "successful" in terms of user goals - it has rolled back to a previous deployment.

To stick with your half completed triathlon example, at the moment we basically give out a medal saying "triathlon finished", which is misleading if you've only completed 2/3 legs. Maybe there's informational value in the fact that a release has run through all steps (as opposed to being aborted), regardless of the outcome of individual steps. But from a user's perspective, there's much less value in knowing this compared to knowing if the release has actually achieved the intended goal (and not rolled back).

tractorcow commented 9 years ago

Then we should make the UI suit the user's goals rather than dumping out all data unfiltered. I don't think it makes sense to display pipeline dependent releases without the necessary context. On 12 Nov 2014 13:28, "Ingo Schommer" notifications@github.com wrote:

A deployment in itself (which is only a tiny part of the pipeline) can still be successful, even if another part of the pipeline (e.g. smoketesting) fails.

But it isn't "successful" in terms of user goals - it has rolled back to a previous deployment.

To stick with your half completed triathlon example, at the moment we basically give out a medal saying "triathlon finished", which is misleading if you've only completed 2/3 legs. Maybe there's informational value in the fact that a release has run through all steps (as opposed to being aborted), regardless of the outcome of individual steps. But from a user's perspective, there's much less value in knowing this compared to knowing if the release has actually achieved the intended goal (and not rolled back).

— Reply to this email directly or view it on GitHub https://github.com/silverstripe/deploynaut/issues/101#issuecomment-62648308 .

sminnee commented 9 years ago

The user shouldn't have to care about the difference between a pipeline and a deployment—they're the same thing.

I expect that, if pipelines are enabled, then "deployments" shouldn't be showing shown in the UI, only pipelines. Maybe that's what #100 is? In any case, the current implementation is a bug—the user is given misleading information about the state of deployments.

sminnee commented 9 years ago

I've re-edited the #100 title so that now I think the resolution of this ticket will be covered by that, and so I'm closing this as a duplicate.