Today, I´d like to finish my small series of a first review on Power Platform Pipelines. This time from the view of the last user role being missed – the code-first developers. Sometimes also referred to as pro developers, I´d like to call them code-first in favor of not saying that low-code developer can´t be professional developers as well, bare with me – we´re all Creators. The beauty of Pipelines being designed to really meet everyone from Admin to Maker to every developer that wants to benefit from Application Lifecycle Management (ALM) made easy. It´s as simple as a count to three.
Code-first view using VS Code

Let´s start with running immediately into an error message thrown, as I was switching heads to a code-first developer opening my VS Code with Power Platform Tools extension installed running the pac pipeline list command. I authenticated against my PowerFx Development environment as this is where my artifact development is ongoing. Being a Maker, I would have selected my solution in here, and with a click on the rocket-icon I would have initiated the deployment via Pipelines.
After running the command, I was presented an error message that the segment „deploymentpipelines“ cannot be found. Ups! What went wrong here? Well, I guess I didn´t really switched heads! From a code-first developer perspective, I should have known that I need to be authenticated against the host where my Power Platform Pipelines solution is installed. So I fixed it by switching my authentication to Power Pipelines – my hosting environment.

After running the command again, I was presented with the information, I was searching for. Before using any of my pipelines configured, I need to figure out their ID. After getting this ID, I can then retrieve more details around the Pipeline stages. Another information that I would need for using Power Platform CLI to deploy my solution artifacts to my Test/QA environment.

By using the command pac pipeline list -p [GUID of pipeline], I can now get those details as shared in above visual. You can see that my PowerFx Deployment Pipeline Citizen Development contains two stages
- Move to Production with ID starting with c77dd0
- Move to Test with ID starting with 9d7f07
The Deployment process
Next, I want to use the Move to Test stage for deploying my solution from my PowerFx Development environment to my PowerFx Test environment being a code first developer, but using Pipelines.

Above visual shows you how the Test environment looks like prior of using Power Platform CLI to deploy my solution. With the information collected from previous steps, I am now ready to deploy my solution.

The command I am using this time is pac pipeline deploy with a couple of parameters. Those are:
- -sn which is the solution unique name. I can get this with a right click on my A small app Version 1.0.0.1 solution
- -sid I got the stageId from previous command which in my case is the ID of Move to Test stage
- -env this is the GUID of my development environment. Get it with a right click on the environment in the list and copy it
- -cv which is the current information that is gladly listed inside the environments & solutions tree (1.0.0.1 in my case)
- -nv the new release version which I increment as I increment to 1.0.0.2
- -w asking me if I want to wait for the deployment itself
Okay, are we ready to run this command? Let´s give it a go, folks.

The deployment process starts, performs all kind of checks, then performing some tests prior to deployment. In case you don´t have any issues inside your solution (like missing dependencies for instance or other errors), you should see the deployment running and finish successfully.

Switching back to Power Apps Studio and using a browser refresh, I can now see that my solution successfully deployed into my PowerFx Test environment and the version number is shown as provided.
This is it! This is the code-first developer experience using Power Platform Pipelines. Looks awesome smooth, right?
What´s in it using Pipelines?
While code-first developers might already be familiar using Power Platform CLI to unpack and pack their solutions and deploy them across environments, the beauty of them using Pipelines is their deployment process becoming monitored and governed by Pipeline administrators. What do I mean?

In terms of looking into the Run history of the Deployment Pipeline Configuration app you see both my deployment runs monitored inside the tool. That means the created artifact is also stored as a managed solution zip file and can be downloaded from the app. Furthermore, all the data collected during the development process is stored inside the stage that I´ve been using to deploy my solution.
A perfect combo?
In this case, I do see a large benefit of Fusion Teams Developers using Power Platform Pipelines and therefore monitoring their ALM activity as well as allowing for debugging in case of an error after deployment. With the improvements announced upcoming this experience will obviously getting even smarter.
If you´re interested to learn more about ALM with Power Platform, here´s an upcoming webinar starting April 6th for you. So sign-up and enjoy to get some insights.
Wrap up
While this might not be the last article and review on Power Platform Pipelines, this concludes my mini series. If you´ve missed the previous episodes, find them here:
- Power Platform | Pipelines | The Power Platform Talks (wordpress.com)
- Power Platform | Pipelines – the Admin view | The Power Platform Talks (wordpress.com)
- Power Platform | Makers & Environment Variables | The Power Platform Talks (wordpress.com)
- Power Platform | Pipelines – the security model | The Power Platform Talks (wordpress.com)
Hope you liked it and let me know your thoughts on experiences when using Power Platform Pipelines either via comments, a tweet or LinkedIn answer. Until then, …
Ein Gedanke zu “Power Platform | Pipelines the code-first developers view”