Feedback on Setup

[richclark808]

Is your feature request related to a problem? Please describe. General feedback on the setup process first impressions

Describe the solution you'd like Liked the new environment setup and being led through the missing setup actions. Would like to see the following though in the GA release:

1. When I added my production environment it wasn't automatically added as production in my pipeline. Although I can see some clients may be deploying to multiple production orgs, they should really use packaging for those scenarios.
2. When prompted to add my first sandbox environment I didn't notice the checkbox to indicate it was a dev org, I'd need to repeat the exercise from scratch to check if that was missing or my error. Easily rectified by removing and re-adding the org.
3. I like the bundling stage radio button to select the org changes becomes a release artifact
4. Navigating between Pipeline and Settings would be unnecessary if there was a Add New option in the Environment pick list on the Pipeline page
5. If I gave an environment the wrong name I had to remove and re-add it. I don't expect this to be a big issue and I'll see what issues removing an environment, re-adding it and re-associating it with the original branch causes.
6. Documentation is very thorough, but ultimately the app is easy to use and I found myself just getting on with it and only going back to the notes to see if I'd missed anything.
7. One time saver is around Access Control. If adding users was centralised and provisioned both access to the Git repo and a developer license to the DevHub org that could be helpful. Noted its a one time issue and not a huge burden.

Additional context Add any other context or screenshots about the feature request here.

[Julian88Tex]

I'll add that for 1. mentioned in @rclark-provar comment, besides the technical implication, I think this is also somewhat confusing regarding naming. I see "Release Environment" and "Production Org" and a count of "All Environments" which to some degree all refer to potentially the same org but based on different perspectives there are different names. It's not an easy problem to solve but I think simplifying the idea of orgs, environments, and stages in the tool would help. It might even make sense to prevent the ability to add a Sandbox as a Release Environment. I realize there are likely use cases where this makes sense but personally, I feel like it's not worth the confusion when learning the tool.

[tsheiner]

Hi! The UX designer here. Thanks for the great comments.

@rclark-provar your items 4,5 are on my radar for sure. The current UX is a result of leftover early decisions about connecting environments before we'd really conceptualized how we'd do pipeline set up. Not an excuse, just an explanation.

To follow on to @Julian88Tex's follow on, yes, 100% we agree we need to improve the clarity/terminology to do with helping the end user construct a model in their mind of how the system works and all the different environments fit together.

Your #7 is very interesting. We've only barely begun to think about how to support managing the DevOps "team" and how much to bring into DevOps Center. Really appreciate your feedback that more centralization could be helpful.

[richclark808]

@Julian88Tex I was of the same opinion re: production but for the Pilot I've chickened out of promoting changes to production and I'm just pushing them to a full sandbox as a 'mock production'. I assume I can the amend or replace the pipeline to add production after and promote the changes then to production. In fact I'll test out how that works out with the git branches as could be messy thinking about it and something to avoid.

[Julian88Tex]

@rclark-provar Curious how that works out! From what I've seen and heard I don't believe you can edit stages after items have been promoted within them so that may be a blocker to adding in production right now.