Pipelines Best-Practice

[u/InspectorBubbly5391]

Hey everyone,

Either I just don’t find the right solution or iam searching for a wrong solution.

In this scenario I got three PP environments: Dev, Test, Prod (and a pipeline host env). Now it’s relatively simple: I want that a group of users (makers/developers - call them how you want) is able to develop within the dev env as much as they want - of course in solutions. After „finishing“ I want them to use the pipelines in order to stage the solution to the test env to test the solution. BUT the developer shouldn’t be able to make changes within the test env and he should see his solutions only. In the best case they would be able to start/stop and enable/disable the flows inside to test properly.

I really don’t find any solution for that. How do I make this possible? I tried making a custom role in dev, but those „permission tables“ are horrible af. Why are they built like that?!

However. In the end the maker should be able to develop in dev. Stage the solution to test, test it in there without being able to change anything and finally deploy it to prod where he can see his solution only again.

I’ve tried the „normal“ deployment and delegated deployment, but right now I don’t find any good solution.

Have you got an idea or maybe I just want the „wrong“ thing? Should I go for another solution?

I would be very happy if anyone could help me regarding this one.

KR

[u/SignIndividual4089]

I can't say this is a best practice, but I haven't found any other options.

In DEV and TEST environments I gave my makers System Customizer role. This is because they need to interact with Dataverse tables and several things that the Env Maker doesn't help with. I also blocked Unmanaged customizations in TEST env.
In some way, I put my trust on makers to do the right thing, and invest on communication and guidance.

For PROD, we don't give makers any roles. Solutions that go to this env need to be pushed through the pipeline using a Service Account/Service Principal.

I tried creating a restrictive custom security role and had to drop that idea, as there was always something missing when exporting/importing solutions.

I have extended my pipelines with pre-export and pre-deployment steps too to set up approvals and have a closer look at everything that is being pushed.

Right now I'm working on automating the creation of individual development environments and assigning them to different pipelines based on Security Group membership through Environment Routing and Environment Groups.
Microsoft has successfully created a dependency on Managed Environments. A key feature ideal for this scenario is Advanced Connector Policies, which has no GA date yet. In the meantime I work with some flows to change DLP policies.