Environment Type Suggestions

[Thoman]

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?

[SteRe · Accepted solution]

Hi @Thoman ,

the type of environments you are going to set up depends on the licenses you already have in place. The more licenses you have, the more capacity for storage you have (a bit simplified). If you don't run capacity issues I would suggest run every environment beside production as "Sandbox". 

You can do basically everything within a sandbox as you can do in type production. A main difference (at least in the past) was about availability of major updates (twice a year; sandboxes before prodution) and backup times (production provides more automated restore points). 

Developer environments are great to save license cost, but if your developers need to have access to any test or prod environment, they need a license anyway. If you are paying a license for a dedicated user, it doesn't matter to how many environments you grant access. Cost remain the same. 

While dev environments are great in matter of storage capacity (not considered for consumption) they have a big downside for you: They are meant for active development. You wrote it might happen dev won't change for years (would be very surprising, but great to hear you have such stable setup). If you don't use a dev system 90 days it get's removed automatically. To prevent from any loss you could either setup a sandbox for dev (change type from dev to sandbox is not supported) or you need to have great source control and pipeline so your pipeline is able to setup a new dev environment and deploy the latest dev status there. Sure, you would need to consider data then. 

So to sum up my recommendation: everything besides production should use type sandbox. If you have short term new feature development, you can use additional enviroments type development and when development is done, you merge the result into your regular dev environment.

[Thoman]

Thanks @SteRe , I was leaning the same way but just wanted some validation that I wasn't missing anything.

Is it possible to have multiple pipelines go to "Production" for the same solution or will it error out saying the solution already exists in production?

For instance:

D-->F-->Prod

D-->H-->Prod

Solution A is updated to F for testing.... while that is being tested, new functionality is getting added to D and then promoted to H for testing by a different Team. While H testing is going on... F was approved and promoted to Prod. Say a few weeks\months go by and H finally gets approved. Can that be published to Prod and then have D promoted to F to get the two environments back in sync?

[SteRe]

You can deploy any solution to production in general. It doesn't matter which source it came from. But for sure, you need to consider versioning. 

When importing a solution the system will check if there is another solution with the same technical name present. If so it will compare version of installed solution and solution to be installed. 

The version you would like to install must be bigger then the existing once. 

So if you run several cycles you could use 

F = 1.3.1.1

H = 1.4.1.1

Prod = 1.2.3.4

In this case you can install both solution from F or H to production as both versions are bigger then 1.2.3.4. 

In case you install F first you can later install H. Once you have installed H, you cannot install F anymore because 1.3 < 1.4