[Issue] `azd deploy` no longer reports deployment sub status

[wbreza]

With the refactoring of the new UX updates for the azd deploy command the user no longer sees additional sub status information about the phase of the deployment.

I feel like the sub status information is really important and provides the user with more incremental feedback about the phase of the deploy operations from building, packaging, uploading, etc.  

Expected: | ==== | Deploying service api (Creating deployment package)

or

| ==== | Deploying service api (Pushing container image)

Actual: | ==== | Deploying service api

[vhvb1989]

I would consider using a single step for each sub-status, instead of just temporal labels within the parenthesis.

Something like:

(X)  Creating deployment package
(X)  Pushing container image
| ====   | Deploying service api

This is similar to provision operation. This way, the user can be all the sub-steps at the end.

[Austinauth]

A few proposals to consider @wbreza @vhvb1989

I think the decision comes down to how important it is to see the completion status for every single sub-step (the list could get very long). If it's important to have that level of granularity like we do with the provisioning I suggest option 3. If it's not as important for the status of the sub-step to persist I suggest options 1 or 2. @savannahostrowski thoughts?

Option 1: Temporal

Pros: Simple. Takes minimal vertical space. Cons: Sub-step status does not persist (is this bad?).

Option 2: Temporal (Broken out by service)

Pros: Simple. Takes minimal vertical space. Slightly more detailed than option 1. You can map failure to a specific service. Cons: Sub-step status does not persist (is this bad?).

Option 3: Progress list + Prefix

Pros: Detailed (is this a good thing?). Can see what service a sub-step maps to. Troubleshoot when a step fails. Cons: All sub-steps grouped into a single list, hard to map to a specific service. Longest.

[savannahostrowski]

I personally like option 1. We should think about surfacing output that strikes a balance between approachable + enough info to help debug if something goes wrong.

We should think about this from the end user perspective as well as our perspective:

• What will help provide the right info to the user for understanding the status of their deployment but also help them debug if any problems surfaced during deployment?
• What would be helpful for us as a team to help triage any incoming deployment issues? If a user filed a bug and screenshotted their deployment output, what, if any, info could be useful to us? AFAIK, we don't capture error logs on the user's local machine today so this could be all we are working with if a user files an issue.

[Austinauth]

Thanks @savannahostrowski that's great feedback.

To your point about ensuring we think about this from multiple perspectives, I may be able to better accomplish this if I had a few different specific deployment related use cases I could mockup for discussion. The error/failure cases in particular.

• Deployment as part of a normal azd up targeting a template
• Deployment as a standalone action
• Deployment error/failures (can you provide a specific example?)

[savannahostrowski]

I think this is a great idea.

So I think mocking up the following would be helpful:

• up
• deploy on its own (should look quite similar to up)
• An error state like "I didn't point the azure.yaml at the right path to my source code so azd doesn't know what to build during the deploy stage" could be an option.

[Austinauth]

@savannahostrowski, @wbreza, @vhvb1989

After meeting with Wallace yesterday, I'm proposing we go with something like this:

A few callouts:

• Show the full list of substeps for each deployment step (Service, Web, etc.). Not only is this consistent with the provision step, but it should give users more feedback as the app deploys (less wondering if things stalled), and make it easier to troubleshoot failure.
• Show the host name in the title of the step. This should give users more insight into what specifically is deploying. It may also help solidify the mental model of how things work with their azure.yaml file. It did for me. -I have not included Docker output in these screens (will update in issue #898). However, Docker output should fit nicely beneath the sub-step as it completes (ex: Building container), and disappear once the step successfully completes. If the step fails, the output will persist along with an error message to help make troubleshooting the issue more clear.

Use Case 1: azd up

Command success screen

Use Case 2: azd deploy

To view prototype (steps 1-5) click here.

Command success screen

Use Case 3: azd deploy error

Note: Does not include error for Docker output step, will update in issue #898.

‼️ Feedback requested on the error/warning messages.

Command error screen

[rajeshkamal5050]

@vhvb1989 please take a look at the above mockups. Will keep it for the April fit-n-finish iteration.

[vhvb1989]

Closing this. We ended up implementing the temporal status w/o keeping those in the list of completed steps (only with parenthesis as part of the progress)