I read an interesting article recently (Straight to Production), it highlighted how someone working directly in prod can be exponentially more productive. It hit a chord with me because of the Power Platform, Microsoft's original vision for the Power Platform was Direct to Prod.
The Default environment was and is production, and Microsoft enforces that everyone that wants any interaction with the platform has access to that environment (and that includes SharePoint users of custom App forms).
So in this blog I want to talk about 3 main things:
- The Pros of Direct to Prod
- The Cons of Direct to Prod
- How to Walk the Line
1. The Pros of Direct to Prod
The main benefits of Direct to prod is simplicity and speed.
Simplicity is evident in the overheads created by following ALM, there are 3 main overheads:
Systems
To enforce ALM you need additional systems, these systems come at a cost to uses, cost to train, and time cost to use.
As an example you will most likely need:
- Repository like GitHub (though that isn't bad idea for Direct to Prod too)
- Pipeline implementation like GithHub Actions
- Testing like Smartbear
- Project management like Jira
- Change Approvals like Service Now
You will have to pay license costs, you will need support staff for each, trained developers to use them, and all of the time interacting with them instead of coding.
And this is not just for pro code, Power Platform should have similar requirements
- How do you back up your solutions
- How do you deploy across environments
- How do you track your work
- How do you manage change controls
Code
Working with ALM adds additional code to your projects. For pro-code its pipeline configs, testing scripts, libraries, etc. And its even the same for low-code and the Power Platform. When it launched there was no environment variables or connection references, guess why, yep because you don't need them if you are working directly in prod.
Adding this extra code not only takes straight development time, it adds complexity to your main code. This complexity makes it even harder to read for other developers, so you invest in documentation and knowledge transfers, and all future development work takes longer.
Storage
Similar to code but this is just around duplicates. Instead of storing your code in 1 or 2 places (Prod and backup), you now have:
- Dev
- Test
- Staging (not always)
- Production
- Backup
That's at least double the storage (and don't forget storage is not free). This can be mitigated if you spin down your Dev/Test/Staging but not all do, especially in the Power Platform.
As for speed, well this one is quite evident, and its all about the process.
Process
If you are updating straight to prod, it generally looks a little like this:
- Requirements for change
- Make changes
- Unit test
- Finish
If its a real simple change (10 mins of development), then this whole process can be in the minutes, now lets look at a ALM process:
- Requirements for change
- Added to project management tool
- Dev spun up from repo
- Environment variables configured
- Make changes
- Unit test
- Create test cases
- Update management tool
- Create test environment
- Deploy to test
- Complete test cases
- Deploy to staging
- Add change request to change approval tool
- Product owner and tester approve changes
- Deploy to prod
This is not an exhausted list and could be less depending on systems/organisation
4 steps compared to 15, and just imagine that simple change, the value added time is 10 mins. Yet above will take over hour of productivity time, and most likely weeks of wait time (waiting for approval, can't deploy and test in same sprint etc).
Finally there are other misc benefits like:
One Version of the Truth
One version of the truth code, if you have a dev and prod instance they can get misaligned. Example I see is there are undocumented edits to dev, and then when a bug fix is required, those changes are missed and get pushed to production.
More Developers
Requiring your developers to know the full ALM cycle means they need to be skilled more, this shuts off a pool of citizen developers that could do the dev work but not the rest.
2. The Cons of Direct to Prod
So why would we not go direct to prod if all those benefits, well 1 main reasons, risk.
Risk will never go away but needs to be managed and processes added to both decrease the likely hood of it happening and limiting the impact if it does happen. And this is why we do not edit directly in prod.
Lower the likely hood of the risk
The first key one to this is the Test environment. By having a separate but identical (and it really should be) we are able to fully check the code. Every developer will make a mistake and having a process to check for them is key. Even when the code is perfect there might be unexpected configuration or external dependencies that cause issues. Having the Test environment allows a "dry run", making sure all the moving parts work.
The stage gate approach as allows for validation checks like Code reviews. Code reviews can spot bugs as well as ensure coding standards. Coding standards help ensure that future updates by different developers are easier, again generating less bugs.
Lower the Impact
By its very nature the ALM process creates redundancy and rollbacks. By having previous deployments any critical issues in prod can be rolled back to the previous version.
Additionally having Dev and Test environments means that any bug cause can be identified quicker and fixed quicker. In an ideal solution for a critical incident would be:
- The bug would be documented
- Previous version redeployed
- The bug replicated in Test
- Solution built in Dev
- Validated fixed in Test
- Redeployed to Prod
This process has the minimum impact to the end user, quickest and most efficient fix development, and definitely not possible in a Direct to Prod approach.
There are also additional benefits like:
Accountability
Ensuring UAT pass and Go Live approval ensures that the right people take account for any results of the deployment
Communication
By having a process and accountability communication is a beneficial by-product. The users and connected system owners will have advance notice of changes and have preparation time.
3. How to Walk the Line
How to get the benefits of Direct to Prod but not the risks is an age of question. The Power Platform was originally focuses on Citizen Developers, who by their very nature are perfect for Direct to Prod. They don't have the training and tools, they are single dev teams, and the solutions are small and low risk.
But the Power Platform did not stand still, it got more powerful, it got broader adoption, and that lead to big business critical solutions, and more instances, both of which raised the risk. Not to mention that when a platform evolves like this external threats will focus more resources on it, raising the risk again. This has not gone unnoticed by Microsoft and its enterprise customers, who have driven the rollout of:
- Solutions
- Environment Variables
- Connection References
- Sharing Limits
- Pipelines
- Granular DLP
- Solution Checkers
- Test Studio
and more, but it has never changed its spots. The Default is still the same, and they have added improvements like version control to flows (creating a mini dev/prod with rollback capability). So how do we walk the line, well for me its around a simple scale, low risk then Direct to Prod, higher risk, then ALM.
Call outs:
low risk = low impact and low instances, as a thousand small risk add up to a high risk
hard level of criticality that above will always be high risk, even low instances
hard limit of high instances that above will always be high risk, even low criticality
The metrics I recommend are:
Low Risk Flows
- Personal solutions - they fix my problem and failures are contained to my role.
- Low impact - the automation is not expected within my role, so if it fails I have the time and skills to complete manually
- Low quantity - individual developers should not have high quantities of flows (20 limit)
- Non Sensitive Data - sensitive data should not be risked and needs to be disclosed for legislation like GDPR
Low Risk Apps
- Limited sharing - only used by a small team / max 5 users
- Limited connections - should not be using custom integrations
- Low quantity - individual developers should not have high quantities of apps (10 limit)
- Non Sensitive Data - sensitive data should not be risked and needs to be disclosed for legislation like GDPR
- Focused - solves one small specific problem
The app rating can be thought of as harsh, but apps have 2 critical considerations for risk:
They use the users connections, so bad actors could miss uses those permissions and access secure data.
They can scale rapidly, a app could quite easily go from being used by a handful of users to the entire organisation. At that point if it went down its impact could be catastrophic. The developer might not even know how many users it has or how important it is to those users.
Once you reach these limits then you then need to move over to a ALM process. That process needs to be as automated and simple as possible to ensure that citizen developers can still use the platform.
Implementing this is practice is all around your environment strategy, your Direct to Prod environments should have sharing controls (ideally using managed environment features else retrospective flows that remove sharing, and please please turn off 'Share with Everyone') and a limited DLP policy (ideally just the non-block able). Monitoring and communication should be a focus, with new developers getting intro email explaining limits of platform and anyone building high quantities of flows or high api call flows should be contacted to validate it is not business critical.
The normal practical split is:
Top comments (3)
This is certainly something I've struggled with at my organization. I see the benefits of the hybrid approach but that requires clear guidelines and principles as to what projects will fall under D2Prod or ALM lifecycle processes. This was a really good article documenting something most organizations using Power Platform should be considering. Thanks for writing.
Wow... this will be my architectural article to consult and discuss. Generally the database will have a huge impact in the decision, I put as first topic of discussion
thanks for the detailed factors to be considered while designing automation