DevSecOps in the Power Platform

The Power Platform at its heart is Micrsofts attempt at a perfect DevOps implementation.

DevOps is a culture of enabling rapid development and feedback cycles by close collaboration of the dev and ops team. The Power Platform approaches this is a simple way, the dev and ops are the same team/person.

The developer creates, tests, deploys, and monitors the solution.

But there was one big issue, developers simply didnt follow it. Microsoft may give you:

• Test Studio
• Solutions
• Pipelines
• Monitor
• App Insights

Most developers are in a business domain not a IT domain, so there focus is more on output and balancing with other
responsibilities. This means developers generally take the easy way, ending up with:

• No Planning
• No Testing
• Editing Prod
• No Exception Handling
• No Monitoring

But it can be done in the Power Platform, as shown the tools are there, so how do we do it right?

Well first there is something important to consider, DevOps has now been superseded by DevSecOps.

DevSecOps is built on the strong foundation of DevOps, but grows the colloberation gang to include Security. We ensure that in every stage of pre and post production we consider and implement security requirements.

So lets dive into Power Platform DevSecOps 😎

Few tweaks I have made to the model:

Release - I have removed this as the everything is deployed in one
Build - Is Package as we don't have a build stage
Code - Makes, as it covers no code and after all, we are environment makers

Plan

It is so easy just to open the design studio and make, but the plan stage is key, and for multiple reasons:

Build Better
I have done a full blog around the steps to build a Power Automate flow (Power Automate - 4 Steps to Building a Flow, although for flows it is transferable to Apps, and it is key message is the 2 planning stages before.

• SDD & SDG (Simple Design Document & Simple Design Goal) - Plan connections and idenifies the key point/value of the solution
• TDD (Technical Design Document) - Plan the contents and inner works of your solution/package.

Understand Impacts
Your plan allows you to understand what systems you connect to and how you will impact them.

Sustainability
Planning the team and resources to own and maintain the solution.

Security
Bedding security in at the planning stage is key, this should cover all of the above, ensuring:

• The solution is even viable
• What authentication is right for connections
• How access is controlled and maintained
• What NFR's (Non Functional Requirements) are required

How to do it in Power Platform

Ensure you have create a intake process, this process should ensure that all development only starts once everthing is considered and planned correctly. Additional meetings like Impact and Desgin Reviews are also useful in building out robust plans.

---

Make

An obvious stage, but in the Power Platform the key things to consider are:

Sustainable Code
Is the solution developed in a way anyone can pick it up and understand it.

Scalability
Will the solution operate consistently across all demand levels

User-centric
Does the solution solve the users requirements, the developer should have a simple path for feedback during development, and have regular check ins to ensure right path.

Agile
The development should be completed in a way that focuses on pieces of value. Ensuring that the solution can be deployed early ensures we get our ROI (Return on Investment) back quicker, and the feedback cycle removes incorrect work.

Security
The idenfied NFR's should be built in from the begining, ensuring it is the 'founation', not a 'add on'. The key to this is the maker understands why the NFR's are required, and how they mitigate the risk. This core understanding ensures that any in design course corrections can be made to deliver the value of the NFR.

How to do it in Power Platform

Build out Best Practices and Standard Operation Proceedures so that your org has consistent code. Training and cerification should be required for all makers. Additionally code reviews are key, automate where possible but a revie from a senior developer is in my experience is the only way to go.

---

Package

Ensuing everything you have developed is ready to deploy ensures a smooth deployment process. Saving valuable time and dealing with completely close to you (the deb environment instead of test environment).

How to do it in Power Platform

As this is very Power Platform centric it's easy to see how to do it. Ensuring you solution contains everything you need, ideally no dependencies. I have rules around environment variables and connections references never being cross solution to stop an unexpected behavior. Everything else follows sane pattern unless good reason except for Custom Connectors. Custom Connectors because you can't deploy without it already being in the environment. And Dataverse tables, as they are generally a shared resource/have different life cycles, so it keeps things simpler if deployed separately.

---

Test

There is a sliding sale on impact of bugs, in development little impact, test a small impact, production large impact.

So having robust testing to catch bugs is key, your testing should have the following:

Automation
Where ever possible automated testing. This makes the testing process consistent and quick, and ideally can be run with little effort on every deployment.

Documentation
Documented test scenarios, with consistent 'Inut this, get this' process.

Independent Testing
The testers should always be independent from the development team. They need to have 'no skin in the game' when it comes to deployment deadlines. The testing ideally should be split into 2

• User Acceptance Testers - selection of the end users
• Product Testers - professional testers

Security
This is where product testers are key, they understand stand pen testing they should be doing, combined with testing any NFR's set. Security bugs are considerably less likely to be found by day today users, and their impact considerably higher.

How to do it in Power Platform

Build out automations to test as much as possible, additionally ensure you best practices has a 'unit test' approach to design (great example is Power Automate levaging Childflows so that testing can be targeted).

Automated testing where possible, I wish Test Studio was in a better place, but it can be considered, along with Power Automate Desktop/RPA solution and pro code solutions like Playwright.

Last but not least, the CoE should provide a testing resource, with experience testers available to be used.

---

Deploy

The deployment process should focus on 2 main areas, simplicity and governance (and security of course)

Simplicity
Your deployment process has to be simple, else makers will be motivated to either bypass you or find another solution (cough, Excel).

And its not just the solution deployment process you need, you need to ensure all the operation processes are simplified/automated, including:

• Code Reviews
• Change Requests
• Go Live Approvals
• Post Deployment Checks

Security
With power paltform solutions becoming more and more business critical our deployment stage needs to maintain stability and not introduce risks. Solution layers are a perfect example of when unexpected behaviour can force (often paniced) updates, which can introduce security vunrabilites.

How to do it in Power Platform

Pipelines are a must, with added extensability to ensure all of the gatekeeping and approvals is complete. In house pipelines with Power Automate handing the extensability is in my opnion hte easiest way.

Levaing Dataverse to hold additional information, like project NFR's, testing results and code review history is also a good idea.

---

Operate

Operate is the key actions needed to ensure the solution continuelly runs. Like you would service your car, you solution should have regualr updates and check ups.

In most DevSecOps is focused on the infrastructure, but as the Power Platform is a PAAS, we don't need to focus on that, but more on:

• Managing Access
• Secret Rotations
• Broken Connection Fixes
• Data Retention

Having good processes not only limit down time, but gather feedback/learnings that are flowed back into the development cycle.

Security
Secret rotation and access management are the areas that are often 'simplified' to make the process easier, but with the side effect of introducing security risks. Secret lifespans should never be extended and access is always on going, with the process to remove access when not needed often overlooked.

How to do it in Power Platform

The above are great examples of when the single team/dev approach doesn't work, as segregation of duties and approval processes are required.

This is where a platform team is needed, as automing this is challenging, and the added human in the loop validation good for security. Seperet from your CoE, the platform team should be ready to maintain and update the platform. Just ensure the team has tight SLA (Service Level Agreements) and a simple process to raise a request.

---

Monitoring

Even though we would love it to be true, things don't always work. External factors like system updates and increased demand can causing outages. Monitoring is key to ensure quick response to issues and limiting down time.

Security
Understanding what potential security issues you have and building in conditional logic to send notifications allows the teams to react before potenial security breaches.

How to do it in Power Platform

The platforms monitoring isn't the best, with features locked behind managed environment pay walls and insights shown only to System Admins.

A good setup is Application Insights set for environment (flows) and app (shared for standard apps, individual if business critical). This data is then fed into a Power BI dashboard for teams to see.

App insights also enables notifications on conditions like high failure rates.

---

DevSecOps can sound like a lot, but hopefully most of the above yo are already doing, you just need to layer on collaboration and streamlined process between the makers, operators and security.

This added complexity can seem like a pain and its so much easier just to do it all yourself, but in my experience that is simply not scalable, with security and stability the first things to fail because of it.

---

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