I think I might have chosen the wrong environment types when originally staging the environment to work with Deployment Pipelines. Our requirements are a bit unique from a "Dev, Test, Prod" deployment pipeline. We have one true "Dev Environment (D Environment)" but multiple "Test Environments (E, F, G, H....). This is because we may be testing applications in future time frames to ensure different process behave correctly depending on the time of year.
Every Test environment has about 1-5 QA testers working in them at a given time. So they are quite active. However the dev environment may have apps\workflows that will go unchanged for months to years unless a change needs to go into production.
Before we get too many solutions deployed out I want to double check with those here how you would assign out each environment type as I know some environment types have restrictions on flow runs, licensing costs, and even automatic purging features built into them.
My thoughts are:
| Name | Usage | Type |
| D | Development - Programmers have access to do anything. | Developer |
| E,F,G,H | Limited User Testing | Sandbox (However, I think there is a flow run limit for this type of 750 runs a month. Is that per flow or all flows total?) |
| Q | Pre-Production | Production (Licensing Required) |
| Production | Production\Final | Production (Licensing Required) |
We then use pipelines to manage promotions to each environment. Promotion to Production would require a "Pre-Deployment" approval workflow.
Does this sound right or should my limited testing environments be Production too? I think you are also limited to only 3 "Developer" Type environments per tenant. Is that correct?
