Although Microsoft really didn't plan (or probably want you to) most organisations understood the benefits of application lifecycles and instigated...
For further actions, you may consider blocking this person and/or reporting abuse
Hi David, interesting article if people must use PP pipelines. However, I feel this is a very maintenance heavy way of achieving it and is why we have the options of both PPP and build tools. Build tools in ADO do this out of the box via deployment settings json files easily. We’ve had it for 2 years and are now migrating over from classic releases to full yaml, as its standardised ALM with the coding world and PPP don’t really make anything simpler.
We had a session with Nick Doelman recently and although PPP have improved, they still very much fit a different purpose to me.
Hi James, you are not the only one to say this, but both sides have complexity, And in my experience keeping it in one platform and one skill set is more scalable and stable. Also I prefer my Devs being able to do everything from inside the platform. And for me the biggest part of complexity is swapping connection, which both needs external setup. Also how do you swap owner from the spn with ADO, something I could never figure out.
Excuse my ignorance, but you'll have to explain what you mean by swapping the connection. As far as I'm aware, all connections have to be owned by someone, regardless if they use interactive (service) accounts like Outlook, or service principals like say Oracle. We do those as the single service account (with MFA tied to it), share them with the Azure App Registration that imports solutions in ADO and use the IDs in the deployment settings JSON to set the connection reference. If we want to change the connection the reference points at, we simply change the ID and re-release that solution.
I do understand what you mean about 1 platform, but for me it's more about pick the right/better tool for the job and people just have to learn. Software has always adapted, as have the people with it. For us, trying to implement sustainable and enterprise level ALM via PP Pipelines is a total no-go. The PAC CLI is ever growing and build tools will with it (as they are just a front end). However, it's a fantastic tool for maybe smaller, localised or other types of deployments. Different tools for very different purposes.
For compliance we ensure that there is different owners of connections in dev/test/prod (ef that sensitive data in SharePoint should not be accessed by dev or test). The only way to swap is for the spn to have the connection shared in advance, and also created in advance. Which takes a lot of effort (as you will should be using different accounts for each solution). Additionally the spn shouldn't really own the solution in the target environment, as it can't have a premium license etc. so we need to deploy, change connections (pre created and shared) and change owner.
Got you, we have a live and non-live account that own connections (we may segregate more in the future) and deployment settings is fine for that. The file doesn't contain the actual IDs (or env var values), but placeholders and we store the ID/values in ADO variable groups, then a task replaces the placeholder values with those for each environment individually. You're right in that we need to create the connection as the interactive users, share them and get the IDs, but that's by design to use the deployment settings json for the build tools. It's a one time thing and took hardly any time to setup.
We've also never had an issue with the app user (azure app reg, what I'm assuming you're referring to as service principal) being the owner of our flows, and they use multiple premium connectors like word mail merge, dataverse, sql server. We use per user licensing for now (aware this has performance limitations, but it's fine for us) rather than per flow and the references point to the service account.
I've got a guide on my blog, but it's a bit long and I'll be redoing it for the fully yaml approach soon. But I'm happy to share the files on how we've done it if you like.
Makes sense, nice setup, unfortunately with our volumes and the $200 per month licences cost it was not sustainable. Hopefully Microsoft allows spn license like a user license soon
Not sure why it would cost that much per user. You have stakeholder access, which is free for limited work item features. You can have any number of pipelines totally free:
Are there limits on who can use Azure Pipelines?
You can have as many users as you want when you're using Azure Pipelines. There's no per-user charge for using Azure Pipelines. Users with both basic and stakeholder access can author as many builds and releases as they want.
Are there any limits on the number of builds and release pipelines that I can create?
No. You can create hundreds or even thousands of pipelines for no charge. You can register any number of self-hosted agents for no charge.
https://learn.microsoft.com/en-us/azure/devops/pipelines/licensing/concurrent-jobs?view=azure-devops&tabs=ms-hosted#faq
You can also use git (to store your json, yaml, unmanaged backups, etc) for 5 people, then it's only $6 each.
azure.microsoft.com/en-us/pricing/...
The per flow license is $200 per month (though been a while since I checked so maybe less but compared to free or premium per user its expensive), its the only way you can have an spn as owner of a flow (as you cant assign user license to them) and you mentioned thats how you license them. I know there is no limits on who uses Azure pipelines, but creating them does require ADO and storage (no matter how small). Yep they scale really well, but if you are using them for hundreds or thousands then thats very expensive (from the license side, as each solution will have a per flow license). If Micrsoft fixed this with a SPN license it would be great, but at the moment I suspect a lot of orgs are techincally in breach of license as they dont assign any license to the spn.
For Apps its a different matter as there is no license issue, but Power Platform pipelines can just use a service account with no extra steps as there are no connections (so all complexity has gone there too).
No we license using per user, which is our interactive service account. The owner is still the azure app registration used to import via ADO. Per user in my last job used to be £60 for a pack of 5, but that’s academic and even if it was 240 (the most we get is 25% of full retail) that’s still not 200 each.
I just checked and its $150 USD (microsoft.com/en-us/power-platform...), with 250k power platform api calls versus premium user 40k it was always going to be more expensive, plus now they rolled in PAD as well.
If the owner is a App and not a service account then technically you are unlicensed. Thouugh Microsoft knows that this is rediculous as they provide guides to use SPN but no license to purchase, so they dont enforce it. But its a grey area and something some legal depts wont do just to be 100% compliant.