From Sandbox to Production: Managing the lifecycle of your Power Platform solutions
Having an effective environment strategy in place is critical for a successful ALM deployment process within Power Platform, especially when you are working with solutions. Your environment strategy does not only accommodate what environments are used during deployments, but also governs how they are setup, managed, updated and secured. This clearly involves quite a bit of work. In order to implement a working environment strategy, it is very important to understand your requirements and build this process around a well-defined plan with clear guidelines. These guidelines, per environment, will govern the environment type, who has access to them, what solutions should exist in them, how Dataverse is audited, how the environment is updated, what security roles are applied, and if they will be a managed environment.
You may already be familiar with environment types, such as Developer Environments, Sandboxes, Trial Environments and Production Environments, but lets extend this to what environments you need. Off the tip of your tongue, you can probably imagine you need a Developer, Test, and Production environment, and you 100% right. Microsoft have also documented an ideal ALM environment strategy advising that its also ideal to fit in a QA (Quality Assurance) environment right after Dev. This strategy is complimented by the ALM accelerator, a topic we will touch on much later. Although Microsoft have advised on an environment strategy, you still need to find what works best for you. However, lets dive into these recommended environments anyways.
This is your starting environment where all development should begin for a solution. You can create a generic Developer environment as either a Sandbox or Developer environment that other developers can have access to. Alternatively, you can also create your own developer environment with a Developer Plan specific to you.
The developer environment should provide Power Platform developers with the tools, accessibility and permissions they need to begin building a new solution. You may even want to use preview features in these environments; however this is not recommended especially when you start deploying these preview features with the intention of ending up in production. At the same time, you also want to ensure that appropriate security is in place to guarantee sensitive data is 100% secure at all times.
All your defined governance and standards should also apply within a developer or sandbox environment. This includes understanding that in most cases, a new solution built in this environment is now set to version 22.214.171.124 and any changes or updates made thereafter, will ultimately impact the production solution as a later version.
Quality Assurance (QA) Environment
Once the developer has completed the solution in line with stakeholder requirements, and of course adhering to development standards, the developer will deploy the solution to a QA environment where the solution will undergo some intense quality checks. The QA process can vary based on your requirements; some even refer to it as a Peer Review. The idea behind this process, is to review the solution build and ensure that the solution meets all requirements and complies with standards. This can be validated against the project user stories (not going into testing just yet), as well as a detailed checklist that needs to be ticked off. Having measured scores that place the solution into a sourcing bracket can help identify how compliant the solution is with QA, ie, scoring the solutions component’s naming convention a 3 out of 3 reflects that standards were adhered to, whereas scoring a 1 out of 3 for accessibility reflects that the developer has not accounted for screen readers etc. Having an overall score will place the build in a category defining if its ready to go to testing, if it meets requirements, but does not reflect well on standards, or it failed all defined standards completely.
User Acceptance Testing (UAT, or just Test)
When the solution has passed QA and had been deployed to UAT, the solution will be tested against its requirements. Testing can be done in various ways, such as through manual testing, designated UAT individuals, development team testing, and stakeholder testing. Each of these testing plans can be specific to project types. For example, in a case where you are delivering a solution to a client, you may want the stakeholders to run a UAT on the solution. They can do this by accessing a related DevOps Test Plan with steps and parameters governed by the captured user stories. This will guide the stakeholders to test the solution and validate if it meets their requirements. Should it not, they can easily raise a bug or change within the plan and assign it to the related user story.
Your testing environment should be treated as a production environment. This can further ensure that test results reflect what would occur within the actual production environment. Should tests fail, the failures should be logged against their related user story and development can begin fixes back in the development environment. Doing this will guarantee you have structured version control throughout these deployments. On a successful UAT or Test, the solution can then be prepped for a production deployment.
Finally, your quality assured and tested solution lands in production. This is the environment where all production solutions live, ie, what is actively being used by all users. These end-users will begin interacting with your final deployed version 126.96.36.199 solution until a later version is released to them following the same environment strategy. Following this type of environment strategy, allows for developers to continue enhancing solutions in the sandbox without effecting the production solution. This ensures that end-users will always have the most stable version, whilst unstable and untested solution can continue being built behind the scenes.
Throughout this deployment process, starting from your sandbox and ending in prod, you still need to govern how these solutions are deployed. Ideally, you would want to deploy your solution across all your environments as a managed solution thus mitigating any hotfixes in an incorrect environment whilst ensuring a stable version control is maintained.
Additionally, there are many ways you can go about deployment. Without diving too deep into deployment options (we will discuss this later in the series), you can either export the solutions and import them into each environment, you can utilise the Power Platform Pipelines or ALM Accelerator, or you can even build your own Azure DevOps Pipelines. At the same time, you may also want to keep a source control for each solution per deployment stage in DevOps projects and repositories.
Again, an ALM Framework is very specific to your requirements. The above environment strategy may work for some, but not for others. The example I used is very specific to a single tenant deployment. Think about the bigger picture. You can apply the same logic across multiple organisations within a tenant, or you can apply it on a regional level as well as on a departmental level. At the end of the day, a structured and governed environment strategy will always ensure your solutions are in the right place, at the right time.