Power Platform - The Managed Delivery Process

#powerplatform #powerapps #powerautomate #lowcode

Not to be confused with Managed Environments, the Managed Delivery Process is at its core how you implement ALM (Application Lifecycle Management). So what does that mean, well you think of it as how your organisation moves a solution from development to production, and all the steps in-between.

Some will argue that you don't need ALM, you can simply edit in production/dev is your production. The Default environment in the Power Platform supports this approach, so you can see Microsoft didn't want to follow the normal process, why you may ask?

Well that's because ALM slows down development, worst of all it requires the developer to have additional knowledge base, and additional people involved, not what you want when you want Citizen Developers to drive adoption. So then you ask why have ALM?

Well there are a few good reasons, but mainly they are:

Protects production by ensuring testing
Mitigates risk of developers having access to production data
Meets certain government regulations like SOX
Ensures stability by separating prod from the developer
Ensures sustainability through coding standards and documentation

So you can see the value, and the challenges it creates, and that's why your Managed Delivery Process has to be secure yet streamlined, In-depth but not challenging, quick yet detailed.

Key to this is automated deployments (aka Pipelines) as this is the tool you use to deliver your Managed Deliveries, and it shows you what Microsoft's vision of Managed Delivery vs what I recommend.

Microsoft's Versions

Looking at Microsoft's Power Platform Pipelines you can see that this is more on the 'Default' side then ALM side. It works on a Dev/Test/Prod approach, but it does not detach the Developer from Prod. They still own the solution, and they still use their connections.

There are variations of this, with delegated deployments added that enable a SPN to own the solutions in Test and Prod (there is delegated to Service Accounts as well, but they can't deploy anything with connections so is not fit for purpose), but this generates issues with licenses, connection errors, and doesn't cover the connections (which are still the developers, so they still need access to production data).

Additionally interestingly there is no default approval process, this has to be added through flows. You can tell this was built to enable this, but it's also true to say its not prebuilt, let alone on by default.

My Version

The approach I recommend is to go with full compliant ALM, and then move all the complexity to the Automated Deployment.

So we have Dev/Test/Prod, but this time Service Accounts own the solutions in Test and Prod. The developer can have read only access, but they can not edit it, not even environment variables.

The next step is we need stage gates to ensure compliance, and there are a few of them:

Intake: is there a ROI, is there a plan to sustain the solution
Arch Review: is the solution viable, is the right tech used (are there new systems/changes in the future that would impact it)
Security: is the solution secure and low risk
Impact: does it impact any other system, are required licenses/ dev environments available in connected systems
UAT approval: does someone separate from the dev team agree it passes all testing
Code Review: does the code meet required org standards, is it documented
Change Approval: does the business impacted by the solution approve changes

So we need a process/system that can track all of these stage gates, recording who approves what. This creates a robust audit trail, ensuring we meet all government regulations (I can't imagine Microsoft's version complying with SOX).

The final part of the puzzle is ensuring that each environment is used correctly, as Microsoft didn't create different Dev/Test/Prod environments we have to (and yes I know there are Developer Environments, but they are not really different, they can still act like a production environment).

For dev we have an automation that periodically turns off all flows that have not been edited in 24 hours. This stops dev becoming pseudo prod.

Test we ensure that the pipeline first checks the solution has been through required stage gates (like Impact, Arch, Security and Impact). We also should have a automation that deletes all solutions that have not been updated in 14 days. Finally we should have reporting that shows length of time for every solution in Test, anything there for over 28 days should be investigated.

If you would like to get notified every new blog (I also do a few in the Power Platform Community), subscribe below