I read an interesting article recently (
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.
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.
SOCIAL SHARE CARD GENERATOR