cancel
Showing results for 
Search instead for 
Did you mean: 
Reply
Power Apps
Power Apps

Create Build Environments on demand as part of your CI/CD pipelines with the Power Platform Build Tools

With the recent GA release of the Power Platform Build Tools, we added support for creating an environment on demand and use that environment in subsequent tasks, for example to generate a build artifact and then delete the environment afterwards. 

 

  • How do you use it? When you use the 'create an environment' task in your pipeline, that environment will be used in any task that follows and the best part is you don't even have to do anything - it just works. An example of a Build pipeline is outlined below that packs a solution from source control -> runs static analysis check on the solution -> creates a new environment -> imports the solution into the newly created environment -> exports it as a managed solution (generates the build artifact) -> deletes the environment -> publishes the build Artifact

buildpipe2.png

 

Note that the URL defined in my service connection is overridden, it is the auth in the service connection that is used to ensure that the user credentials passed have sufficient privileges to create the environment. The Build Tools tasks that deals with environment actions such as create, backup, delete currently only supports username/pw auth. Support for Service Principals for those tasks is just around the corner...

 

Happy CI/CD'ing 😊 

 

 

 

 

5 REPLIES 5
Community Support
Community Support

Hi @Mikkelsen2000 ,

Thanks for your sharing!

I believe many other users will gain a lot from your post.

I really look forward to this new feather!  

 

 

Best regards,

Community Support Team _ Phoebe Liu
If this post helps, then please consider Accept it as the solution to help the other members find it more quickly.
Frequent Visitor

Hello, I have made this pipeline the same way as yours, but I have a problem: When the build artifact is run, the environment creation task runs fine, but the CDS URL changed because there is a 7-day retention policy of the previously deleted instance. This then causes the deletion task to fail because it can't find the url configured in the project's connection services on DevOps. For example, the environment creation task is generated with these parameters: Name: BuildEnv and Domain: build.crm.dynamics.com. Then, when it is deleted, it is retained for 7 days. When the pipeline is executed again, it adds a 0 to the domain (build0.crm.dynamics.com) because the 7-day policy is still active, so build.crm.dynamics.com can’t be used. This then causes that it cannot be deleted because this value is not configured in the service connections.

 

Have you had the same problem?
Do you have a workaround?

Frequent Visitor

What is the advantage of using the build environment as opposed to importing the unmanaged solution as managed with the import Build Tool? I'm trying to work out why i even need a build environment.

@JaRiv You could use $(Build.BuildId) in the name of the build environment that you create to ensure each time the environment name is unique and knowable. 

Hello  @damienjs check this blog, https://benediktbergmann.eu/2020/02/10/cds-basic-alm-process/

and guide for Ms https://github.com/microsoft/PowerApps-Samples/tree/master/build-tools

 

This process is following the recommendation and best practice from Microsoft. Microsoft’s approach, and the approach they recommend to everyone, is the “Source-Controle centric” approach. This means that you always should store a functional version of your Solution in your Source-Controle. I do see the following main reasons for this approach:

  • Recover your development environment
  • Merge several development environments
  • See historic changes in a solution

Build Managed Solution

 

 

Sub-Process – Build Managed Solution

The Solution we stored with the first sub-process will be changed to a Managed solution in this sub-process. To do so we have to import the solution to a JIT Build (Just-In-Time Build) environment, export it as Managed and store the Zip-File as an artifact inside of DevOps.

We do need the extra JIT Build environment because this process will run independently from the first one. This could result in having a different version in our development environment than the version we would like to package. In the best case, we would create a blank new environment when starting this process. I will not go into detail in this article but will publish another one specifically on this topic.

Helpful resources

Announcements
Community Conference

Power Platform Community Conference

Check out the on demand sessions that are available now!

News & Announcements

Community Blog

Stay up tp date on the latest blogs and activities in the community News & Announcements.

secondImage

Power Platform 2020 release wave 2 plan

Features releasing from October 2020 through March 2021

Community Highlights

Community Highlights

Check out the Power Platform Community Highlights

Users online (7,859)