Before I start, this blog is about Power Platform Pipelines, not ALM Accelerator using Azure DevOps.
The Power Platform has always been, how do we put this, a little distracted when it comes to ALM and deployments. It was very much a 'build it in prod' approach. But eventually we got solutions and recently pipelines.
For me Pipelines are kind of a big deal, they are key to IT lifecycles. Pipelines or automated deployments, have 2 main benefits:
- Simplifying Deployments
- Adding Governance & Compliance
So let's look at how it stacks up.
1. Simplifying Deployments
From a starting position pipelines would have been brilliant, before solutions everything was separate and challenging to move, but since solutions most of the heavy lifting is done.
The export process is couple of button presses, and everything is zipped up. Then a couple more button presses and its imported. It sets all the connections and variables and makes the whole process joy.
Pipelines make it even easier, now no export and import, just a couple of button presses and it appears in the new environment.
So it's a win for pipelines simplifying deployments, but I would say it was already pretty simple.
2. Adding Governance & Compliance
A big part of IT governance and compliance is segregation of duty.
Separation of duties is commonly used in IT organizations so that no single person is in a position to introduce fraudulent or malicious code or data without detection
In the Power Platform that means the developer should not have access to production, which is not easy. As at its core it is a citizen developer tool, which is about empowering people to build their own solutions. Everything is linked to you, it's your flow/app, your credentials, etc.
This means you need Service Accounts (a M365 account with Outlook account etc but the account is not linked to a real person) to own the app/flow in test/prod. A second person from the developer will log in as the Service Account and import the solution, which is very manual and time consuming. The deployment to production should also have an approval process (change ticket), to ensure the correct testing and security checks have been carried out.
This is where pipelines will be perfect, they can replace the second person and do the deploying.
To support this pipelines has delegated deployments, where the deployment is completed by either the Pipeline owner (can be a Service Account) or spn (Service Principal Name). As without delegated deployments the developer using the pipeline has to have full edit access to test and prod.
Pipeline Owner
There is a setting when creating where you select delegate deployment, this then means the pipeline uses whoever created the pipeline to run the pipeline. They will need elevated permissions in all the environments, not ideal, but understandable.
Problem One
You may be deploying as a Service Account, but its still using the developers connections. So if your flow uses Outlook, the pipeline will deploy to production using your Email. So there goes separation of duty as you in theory can access prod.
Problem Two
Accounts only have upto 40k power platform api calls per day, so after a few flows are deployed they are going to run out and get throttled.
Problem Three
Pipeline Owners (Service Account or not) cannot deploy connection references using OAuth. What connections us OAuth, well lets just say nearly 99% of them. Outlook, SharePoint, OneDrive, Teams, Planner, Forms, all of them. This is because it does not have permission to access the developers connections.
mslearn#deploy-as-the-pipeline-stage-owner
So lets be honest, it is unusable, except for maybe some Power app only solutions.
SPN
Problem One
Same as Service Account, it still uses the developers connections.
Problem Two
SPNS are not accounts, so cant have licenses, which means how can they own them. The documentation is 'grey', it looks about using pooled API calls from other licenses, win, but nothing about pooled licenses. I can't imagine Microsoft being happy if I have my spn own thousands of premium flies with zero premium licenses.
Problem Three
To uses the SPN it needs to be owned by whoever creates the pipeline, and in most organisations, this is simply not allowed.
So definitely a lot better than the pipeline owner, but still not quite there, especially if your organisation doesn't allow you to own it.
Wrap Up
For me this is a big missed opportunity. Microsoft have focused on making the deployment process simpler, rather than making the platform compliant. The delegated deployments are simply not fit for purpose, and feel more like a way of ticking a box then actually delivering what people need. Yet if they had put the effort into a governance focused pipeline they could have added real value (all those hours of platform engineers deploying solutions).
So how do they fix it, well for starters let's call out the good and what we want more of. The interface is great, it's very user friendly and the ability to extend with flows is brilliant (it allows some creative work arounds to fix some of the issues). It seamlessly integrates with the platform and pretty much just works.
Now to the fix, well first there needs to be a change in direction. The focus needs to be on governance not citizen developers. If a developer is honest with you they will all admit that if they have access to prod they will eventually edit prod. Which means Pipelines will eventually become unused.
With a governance focus we really need a credential bank. Here Service Accounts connections can be created in any environment, and then permission to use them shared with either a user or specific solution (but only through the pipeline).
The pipeline then needs to be decoupled from the developer, remove the process of using their connections (save this functionality for personal pipelines).
Next we need a process to either pool or allocate premium licenses to spn's. And improve/clarify the documentation on the pooling of daily Power Platform API calls.
Finally the spn needs to be decoupled from the pipeline owner, and instead it's client id and secret used when selecting it as the delegated deployer (it's how all the other spn connections are created).
And one more, as for the pipeline owned delegated deployment, either remove it or advertise as only for selected Apps, and say it's not suitable for flows.
Pipelines have the potential to fix most of the issues that are holding back the platform from scaling in large organisations. And what they have designed looks great, and is so close to be what we need, I really hope they get back on track.
Top comments (3)
Thanks for the insights @wyattdave. But I was wondering, won't these risks be eliminated if we have the ownership of flows assigned to a dedicated Service Account? I mean once the flow gets to prod, we remove the dev as owner and assign to a Service Account not accessible to the dev. Won't this practice eliminate the fears highlighted here?
Yep that's definitely a good move, but you would also need to do connections, which is impossible to automate without spn.
thanks for sharing @wyattdave . I am sure you are in conversation with the platform engineering team. Looking forward for updates