ALM and Environment strategy

(2) Share

Report

Posted on by CU18101220-0

Hi there,

I am about to set up a ALM strategy, but I am hesitating as far as environment type to set for each stage.

There seems to be different trends about the type of env to set depending on the stage.

I was thinking having a 3-stage cycle, i.e Development=>QA=>Production cycle.

So far nothing crazy innovative, right ? :-)

However I see some people are assigning a Production Env for the 3 different steps, while others are going with Sandbox for the Development stage and others assigning a Sandbox for the QA.

Surprisingly, I don't see much people assigning a Dev Env for the Development stage.

I was thinking having a prod env each stage, and an additional Dev environment aside to pretest ideas before doing anything in the Dev Stage.

One of the reason is Dev env does not consume any credit, which allows me to test ideas without being refrained of testing new stuff.

Yet, a Dev Environment cannot be part of a pipeline, but on the other hand I can export it manually to a Sandbox/Production Environment, so I don't see anything precluding me to play around a Dev env.

As you can see I didn't make up my mind.

Any advice ?

Categories:

Publish & channel management

I have the same question (0)

All responses (4)

Answers (3)

Verified answer

Romain The Low-Code... 2,111 Super User 2025 Season 2 on at

Like (1)

Report

hello :) the naming of the environnement are confusing.

the "dev" was the named "student" : so i think you will start to understand where is the problem : it have a lot limitation, sharing, feature etc

I use it for "R & D" for my personnel test

the sandbox have a lot of feature for restoring content etc. with appropriate DLP it's a good "dev" environnement.

Q&A et Prod should be "production" environnement because of the few difference about solution management and capability in restore.

And "non official" what i have seen after many year in those environnement, it's a personnal feeling :

the "dev" is slow

the sandbox is "normal" speed

the production have quicker answer time.

it's probably totally wrong but i feel there is not the same perf between prod and dev.

This is a quick opinion writtent nightly :) i hope this help

2 people found this reply helpful.

Was this reply helpful? Yes No
Verified answer

Giraldoj 762 Super User 2025 Season 2 on at

Like (2)

Report
Hi!

There are a few articles related to this topic, including Microsoft’s official recommendations

https://learn.microsoft.com/en-us/microsoft-copilot-studio/authoring-solutions-overview

From my point of view, Copilot Studio agents rely on Power Platform environments, so there’s no reason to adopt a different ALM strategy. I usually follow this setup:

DEV (Sandbox)

UAT/QA (Sandbox)

PROD (Production)

As Romain mentioned, there have been some changes in development environments. At least in Europe, it’s still named “Development,” so you can give it a try and see if it works for you. However, not consuming credits in DEV isn’t always ideal—you might miss licensing issues or cost implications before deploying to QA.

For UAT, I strongly recommend using a sandbox environment. If something goes wrong, you can’t restore a production environment over itself—you need a sandbox to restore it. In my experience, a lot can happen in QA, and restoring a fresh copy has saved me hours of work.

3 people found this reply helpful.

Was this reply helpful? Yes No
Verified answer

Romain The Low-Code... 2,111 Super User 2025 Season 2 on at

Like (1)

Report

i totally agree with @Giraldoj

2 people found this reply helpful.

Was this reply helpful? Yes No
CU18101220-0 25 on at

Like (0)

Report

Salut @Romain The Low-Code Bearded Bear

Having Dev Env type as an Rnd env sounds smart.

Do you see any issue using that Dev Env type, to build up a solution as fas as you can (given the limitations) and once done, moving to the Sandbox so-called Dev Environnement to finalize the development, packing, fine-tuning, cost assessment before pushing it to a UAT/Prod env ?

My goal here is to avoid being charged tons of credits during the very first step of the development as we all know there is likely a lot of runs, crashes, debug to be done.

If this is according to you a good option; here comes up the next question : versioning.

I am not -yet- that used of the Pipeline/ALM tool, but do you see a problem setting the following ALM tactics :

- one pipeline : RnD (Dev Env Type) --> Dev (Sandbox Env Type) to move the "RnD" solution crafted from RnD to Dev (benefit is cost savings during early dev).

- one pipeline : Dev (Sandbox Env Type) --> UAT (Sandbox Env Type) to move the "dev"' solution from Dev to UAT (benefit is cost assessment and fine-tuning during Dev stage).

I was wondering whether there gonna been problems of versioning for the solution as that solution is on the one hand the Target of a pipeline (Rnd--> Dev) and on the other hand the Source on the other side (Dev-->UAT)... not even sure this is possible.

By the way, kudos for your videos on YouTube :-)

Was this reply helpful? Yes No