Environment setup and deployment for Apps with Sharepoint data sources

[mjbcruzdev]

We're in the process of cleaning up the default environment and moving business apps to managed Power Apps environments.

We have setup a Dev (sandbox), Test (sandbox) and Prod environments. Developers have maker access in Dev and Test. Only PowerApps admins have maker and admin access in the Test environments. 
Most of our business apps uses Sharepoint as a data source for the reason that we have very limited PowerApps licenses that's why we're not using CDS for now. 
Our current situation is that developers don't have Sharepoint development site in the O365 Production tenant, so they work in our O365 Developer tenant where they can create development SP sites. When they're ready to deploy their application we asked them deploy it in our O365 Prod tenant, Dev environment (where they have maker access).  They will make two copies of the app and workflow, one that points to pre-prod/test SP site and one that points to Prod site. They will do all the updating and re-mapping in the Dev environment. Once they're done the PowerApps admin deploy them in Pre-prod environment (using service accounts) and Prod environment.
I was wondering how others setup their environment.  What is the recommended setup?  We planned of creating Sharepoint development sites also in our O365 Production tenant but we're quite hesitant because it will be mixed up with production data and we might end up with hundreds of development site residing together with prod sites.

Here's a diagram of our current setup.

[jlindstrom]

So basically I would have a separate prod environment for the apps from the prod environment that you have cds in. See the power platform adoption framework guidance—you want to group apps and environments by work stream and criticality https://github.com/PowerPlatformAF/PowerPlatformAF/wiki/4---Enterprise-Management

as for the lists themselves you could either have different lists in the same sharepoint site or lists in different sharepoint sites. It  doesn’t matter that much because sharepoint is not a relational database and you can share lists with different groups so you can limit access to different lists

biggest thing is you want to limit the kinds of apps that are being built using Sharepoint. Sharepoint is great but it should not be used for high criticality complex apps. The following is from the adoption framework:

”

• Excel should be used sparingly, if ever, and only to provide data storage for the most basic and temporary workloads.

• SharePoint is an acceptable best practice data storage for productivity workloads built by citizen developers, but should be avoided for more advanced productivity and certainly for important and critical workloads.

• Common Data Service is the data source native to Power Platform, and should be considered the default data source for important, critical, and some more sophisticated productivity workloads.

• Azure data services can provide an alternative to CDS in organizations with significant pre-existing Azure data investments / infrastructure. However, significant functionality--particularly within Power Apps (e.g. the ability to create model-driven apps)--is sacrificed when using Azure as a data source.

Microsoft has addressed this topic with additional guidance in a blog post of 30 October 2019: Establishing an Environment Strategy for Microsoft Power Platform.”

[mjbcruz]

Thank you.
Once we're ok with our licenses we'll definitely migrate some of them to CDS. We'll create a diff set of environment for those that uses CDS.