Deleting, importing unmanaged solution adds old tables

[Gjøl]

In our PowerApps setup we have four environments:

* Development (Unmanaged)

* Build (Unmanaged)

* Test (Managed)

* Production (Managed)

We change the solution in development. When everything is ready for deployment we export an unmanaged solution to git. When we merge to our main branch, the pipeline takes over:

1. Delete the solution from Build.
2. Import new solution to Build from git.
3. Bump version.
4. Export solution from Build as managed.
5. Upgrade solution in test.
6. Upgrade solution in production.

This has the benefit of keeping the solution and the code in sync as well as verifying that the solution can be imported anew if everything goes sideways.

However, there is an issue: When deleting the solution from Build the Dataverse tables remain. Not only that, when importing the new solution they are somehow incorporated into the solution, so when it is exported in step 4 references to deleted tables reemerge. Step 5 then fails.

Ideally we would prefer to just reset the build environment each time, however this also deletes users and takes much too long.

Is there a way to delete all table definitions belonging to a deleted solution? Doing it via REST calls is fine, as long as it can be done by some automated process.

[joe_hannes_col]

Hello @Gjøl,

Why don't you create a new Build environment every time you merge into your main branch, and delete it once the solution was successfully exported as managed?

We are using this approach, and it works fairly fast. I assume your build process is completely automated, so in my understanding you would not additional users in Build, right?

[Gjøl]

This is an interesting approach. I guess it's a question of privilege. Our app users are not administrators so they can operate on the solution level, but cannot create and remove environments. This might be a way forward, if we don't find a security issue with the escalated privileges.

[joe_hannes_col]

When you set up your pipeline steps, you can define the user you are using to execute the Power Platform commands. We are using a service principal (application user) to create environments and import the solution (and for all subsequent steps).

In this case, the permissions of your developers would not have any impact on downstream steps.

[Gjøl]

We are also using a service principal user, however it does not currently have the required roles to manage environments. It is granted access to individual environments by adding the user in the PowerApps admin portal and giving it roles in there. For the user to be able to create new environments it would need more rights outside of the specific environments.

[ChrisPiasecki]

Hi @Gjøl,

You provably have Environment creation restricted to Admins only in your tenant. In this scenario, you may want to consider just having a build environment pre created and used just for builds. You can perform a reset of the environment as a first step in your build pipeline to ensure its always clean. As long as your service principal has admin privileges on the environment, you can perform a reset. 

---
Please click Accept as Solution if my post answered your question. This will help others find solutions to similar questions. If you like my post and/or find it helpful, please consider giving it a Thumbs Up.