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