Do we need a buid environment for healthy ALM ?

[mschaaks]

Hi, based on experiences from others i have come up with this environment strategy: 

I however got questioned regularly about the need of the solution BUILD environment and find it tough to explain its usage. The BUILD environment is used by the build pipeline to transform an unmanaged solution (pulled from DEV by the export pipeline) to managed using the Powe Platform Build Tools import and export tasks. Power platform environments are stateful and volatile and to assure a clean transformation proces the build environment is only used by the build pipeline, no regular development work is allowed to happen within it. This assoumption is based on experiences i have heard from others, I however find it difficult to explain what could go wrong if one pulls both unmanaged and managed solutions from the DEV environments from the get go. Feedback on this is much welcomed. 

[Pstork1]

The build environment is used primarily when there are multiple devs working on a solution.  YOu could also call it a "Staging" environment.  The Dev environment is dedicated to individual developers working on projects in their own space.  Not all Dev solutions will be ready for deployment at the same time.  So the Build environment is where those separate components are combined into a set of solutions to be used for testing and production.

The problem with pulling things directly from the Dev environment is that you may pull some solutions that are ready for deployment along with other solutions that are not.  The Build environment lets you control which solutions are combined for deployment without interrupting the work of individual developers.

[mschaaks]

To nuace my question: if you do not have parallel development or the need for merging components coming from differenent solutions: aka just looking at one-and-only-one solution, is in that case the usage of a seperate BUILD environment logical ? In this case I find it akward to export 2 different pacakages from DEV : 1 unmanaged that (in an unzipped state) goes to the repo and the managed one, that will be used to deploy the solution to higher level environments (test, production). It feels cleaner to solely use the exported unmanaged package as a singe source during the whole deployment process, where the build environment is used for the transformation step (unmanaged to managed).