Firstly, a basic intro to both. Azure DevOps is a catch-all tool for software development that has been around for years, originating in Team Foundation Server. It has very robust work management, source control, build and release and other options, primarily built around traditional coding but has in the last couple of years had Power Platform tasks added.

PP Pipelines are a relatively recent addition that exist within the platform itself and allow to export and import solutions between configured environments.

To a degree, a direct comparison is unfair as they appear to be aimed at different audiences, however due to the nature of both existing, it is worth a discussion.

Pipelines

For more information on and how to setup pipelines, visit the following sites from Microsoft

Overview of pipelines in Power Platform

Set up pipelines in Power Platform

Fundamentally, pipelines export and import solutions, it’s as simple as that. If you require simple exports and imports, with the same behaviour as manual and the account does not matter, I would recommend them. They will be a lot easier to setup than DevOps and will be in an ecosystem you are familiar with (it’s all via Model-Driven Apps), as well as the setup process ensuring strict usage of specific environments and accounts. It will also force you into an order of environments.

On the opposite end, you cannot perform any of the following: linking to work items; approvals; pre-defining environment variable and connection reference values; import as someone who doesn’t own the connections. If you are operating in a team and are trying to achieve full ALM process like coding teams, pipelines are not currently for you, as these are fundamental requirements for that process to happen.

Overall, if Microsoft extend Pipelines to be more feature rich, they could become excellent and a far simpler alternative to ADO. As it stands though, they are more aimed at one audience.

Azure DevOps

As mentioned above, ADO is a far more complex and robust toolset, including releasing. You will have full control of every aspect of connecting to the environment, to what you do within it. This does mean a learning curve and complexity of setting up the releases, however it is fundamentally worth the effort. I will go into more detail on how to set it up in another post, but here are some key benefits:

• Non-interactive users via Azure App Registrations and PP App Users is possible. No license is required and you cannot login – extra security.
• Values in environment variables and connection references can be populated in and used from a configuration file, regardless of who owns the connection the reference will use.
• Approvals prior to each environment (or any stage you choose).
• Automated testing and backups of solutions to git.
• Work items can be updated (read the next post for more info, it’s not the same way as coding).

ADO is nothing special – it is ultimately a wrapper for the Power Platform CLI. This means the more familiar you are with one, the quicker you will become with the other (a very good thing). It would be my one and only choice to achieve true automation within ALM.