Ive already written a blog about environment strategy, and for some this is still valid, but since I have written it my opinion has changed.
Before I was focused on the data and domain, giving each business department its own Dev/Test/Prod by Geo
But there are a few reasons why I have now decided against it.
- Pain to setup
- Difficult to monitor/control
- Difficult to develop in
Why is Difficult used so much, let me explain.
As with everything in life as something grows it becomes harder to get the big picture, there are simply more places to look and more places to lose things. We normally accept this because the benefits out way it, complexity is a necessary evil. But it should be kept to a minimum.
With my original strategy we grow quickly, at first nearly every automation/app gets its own environment. Not only one environment but sometimes 3. This requires time to setup and time maintain. You may not think tha's a lot but it includes:
- Setting up environment
- Configuring DLP (why is there no copy function Microsoft!!)
- Setting up security groups for each role
- Building a access process and approvals
- Adding reusable components like custom connectors
I know managed managed environments fix some of these but not everyone has managed environments
On top of all that setup we need to maintain it, nothing stays the same, new connectors, updates to reusable components, backups, release waves, etc.
So why is it difficult to monitor, well that's easy, the Power Platform is not in a good place for monitoring. Don't believe me, why is there the CoE kit, it's there because of the huge gap in platform monitoring. Monitoring is all about the big picture, and if we are struggling to get the picture because of the platform, the last thing we should do is exasperate the issue with unnecessary complexity.
Don't get me started on Developer environments, the thought of dealing with thousands of environments is mad. If these environments were real developer environments and locked down great, but as you can share like production environments its just another pseudo prod to control
Difficult for developers depends on the developer, but for people like me who support multiple teams, it can be challenge to find where all my apps/flows are. Add in the administration of requesting access to environments its more unnecessary overhead.
So what's my version 2, well now I think consolidation is the key.
I now like Shared Environments with additional environments added on when needed.
My shared environments are done by geo, so the bigger the organisation the more environment stacks. What's good about this is you can start small and scale out when needed.
This is also our foundation so we can still expand in other directions. Let's say you have a high performing team (ideally IT), they build lots of solutions in the shared environments, they learn CoE's processes and follow them well. At this point they have scale, sustainability and the knowledge. These teams can then have their own environment stack. They sign off with security to ensure they take responsibility for security etc. ideally the CoE still controls the test and prod to ensure separation of duty. But the environment owner takes responsibility for all solutions (e.g CoE ensures service accounts and no editing prod, the owner ensures no miss use of pi/spi data etc).
Its an unfortunate truth but the developers don't care about environments, if they could they would work out of the default, so your environments need to be configured in a way to force good governance. Strick DLP on Default, dev only api's for custom connectors in dev environments, good training. Unfortunately all of this will still not stop psuedo prod.
Pseudo Prod
Pseudo prod is a non-production environment used as production and is one of the biggest challenges for Power Platform admins. Production includes controls and checks, all of which add time and effort for updates, additionally there is separation of duty so the developer has limited access and visibility to production. That makes using non-prod as prod very appealing.
Your environment structure is built around Dev-Test-Prod, so without controls dev/test will become pseudo production, breaking you environment strategy. Therefor as part of you environment strategy you will need some controls/automations.
Dev
If you are using managed environments then sharing limits should definitely be set, else the ease of sharing without controls will be very appealing (You should be using security groups for access, as they have an approval process and audit trail, not sharing through users in Power Apps).
Secondly you should be using a repository, a repository stores your dev unmanaged solutions. The main reason is that if the Power Platform isn't your point of storage you can delete it from Dev, ensuring it is not production. Once you have a repo you can add a deletion automation, this should be set to run once a solution has gone into production. If you are using pipelines add it as a post deployment step, if manual then add a clean up automation that checks inprogress solutions.
Next add a auto shut off automation, this should check every dev flow, and if it hasn't been modified in last 24 hours turn it off. The developer can turn it on with minimum effort, but it will stop anyone trying to run prod flows in dev.
Finally monitoring, you should setup up Power BI reports that check for solutions that have been in dev for a long time so that the CoE can reach out and find out what's happening. You should also look at Apps that have high session counts, anything used a lot over a period of time smells like prod.
There is also a second approach you could take. Instead of a shared Dev environment use trial environments for each project. These are spun up when a new project completes intake and as they get deleted after 28 days they will not become pseudo prod. There are a few reasons why I don't recommend above shared dev but they can all be solved if this is feels like better option:
- Complexity to spin up the environment
- Access setup - security groups, how created etc
- If using pipelines they will have to be spun up on demand
- Only 28 days to complete project
- Relies on Dev saving to repo during dev else will be lost with environment
Test
As test does not require change management and if you have an automated/slick dev to test deployment process, test could be the ideal pseudo prod. It runs on a service account and can't be turned off as testing may require a long window.
That's why it isn't as simple as dev, firstly I would have a flow that turns off all flows after 1 month since created. The flow should notify the team and then delete it after a short period unless they reach out to CoE with a special use case.
This still gives a 1 month window so should be more of a fail safe, the CoE should have tight control of test, with tracking of what is being promoted there. Again Power BI should be used to flag behaviour that looks like production.
The biggest challenge with the Power Platform is keeping it's usp (self service, anyone can build) without breaking valuable IT governance. Your environment strategy needs to do both, and this needs to be a mix of good structure and automations/process.
Top comments (3)
the problem with the shared env approach is once you start using Dataverse as storage you end up with a huge amount of tables and possible security issues with regards to sensitive data in production which will be even more difficult to manage
Very true, and I would always scale out separate environments for large Dataverse projects. But in my experience the volume of solutions don't use Dataverse (your milage may vary). My version 1 was focused on Dataverse like you said and that is good for some, but I found its negatives out way the positives.
On similar thought process wrote about automation ALM