Author Lewis Baybutt [MVP] discusses the significance of Application Lifecycle Management (ALM) in creating Power Platform solutions, particularly when SharePoint acts as the core data source. Lewis emphasizes the importance of organizing unique data repositories for every stage of your operation, from development to production.
Delving into the concept of Application Lifecycle Management, Lewis describes it as the process involved in developing a digital application, from the initial building stage, the transfer to end-users, and the following maintenance phase. The lifecycle usually involves stages like Development, Test, UAT, and Production, though the exact requirements can vary based on the team's needs.
To explore more on ALM, readers are directed to the informative posts on 'Low Code Lewis'. Lewis discusses how to support ALM just like a Dataverse solution. With SharePoint, this involves having identical SharePoint list schemas across four different SharePoint sites.Find more details on SharePoint Online here.
Starting with a development site, the author guides on building a SharePoint site with a necessary schema on your own. The schema would need to be the same in test, UAT, and production environments. Lewis simplifies the process of deploying a schema to these sites using a script.
Next, Lewis goes into detail about how to deploy schema and establish connections in multiple places. Taking advantage of environment variables, Lewis suggests avoiding incorporating SharePoint sites directly as hard-coded values. Such avoidance prevents creating superfluous unmanaged layers on application layer objects. Lewis provides detailed instructions on creating an environment variable for your SharePoint site.
Lewis explains how to connect to your SharePoint site in Canvas Apps, by referencing environment variables. The app will hence connect to those sites when updating variable values in future environments matching their ALM stage. The environment variables in Power Automate would make all variables available as dynamic content in your flows. The flows will reference the sites and lists stored in your environment variables.
When deploying the Power Platform solution, it is crucial to update variable values so the target environments reference the appropriate sites. Lewis suggests deleting existing values in data source environment variables before exporting the solution from development. During the import process to test, UAT, production, etc., you will be prompted to select new environment variable values to correspond to the particular environment and its ALM stage.
Lewis prescribes a rerun of the SharePoint PnP script across sites if any data schema changes occur in the development phase. The Power Platform solution would also need a redeployment for the new site schema to reflect in the apps and flows. He assures further guidance via comments if readers find any content incomprehensible.
This summarized post provides a deep dive into the use and management of SharePoint as a primary data source in a Power App environment. Leveraging ALM securely assists in the development to the production phase, ensuring consistent data management across environments. It also underscores how the strategic use of environment variables can circumvent complications involving hard-coded values.Read the full article ALM and SharePoint Based Power Platform Solutions
Application Lifecycle Management (ALM) plays a crucial role in designing Power Platform solutions, with SharePoint being frequently chosen as the principal data source. The need for efficient management of ALM in crafting SharePoint-based Power Platform solutions, including separate data storage for every environment from Development through Production, cannot be overstated.
If one's still a novice to ALM, to put it simply, it refers to the method adopted for creating an application, it extends from its creation to handing over to the end users and even afterwards. Without the intricacies, it is the movement from development of a solution to its delivery to end users.
These strategies typically encompass three core stages: Development, Test, UAT (User Acceptance Testing), and Production. However, they can be flexible to adapt to your development team's needs.
For an efficient ALM process akin to a Dataverse solution, four spaces for data storage are required. With SharePoint, this implies having four SharePoint sites with matching list schemas. The question then arises - how to achieve this?
You would start with your development site, created using standard SharePoint site protocols for the build. With record lists and columns in place, the question then becomes - what next? How does one seamlessly transition to the test environment, UAT or production environments? How can identical site schemas be maintained without adding uncontrolled layers on my solution everywhere?
The key here is deploying your schema to your other sites. These will be treated as environments aligned with your Power Platform environments.
Now that you know how to deploy your schema to SharePoint Sites or Environments, connecting your solution to these environments is your next step. How do you accomplish this? The answer lies in harnessing environment variables. By referring to environment variables in both your Canvas Apps and Power Automate Cloud Flows instead of treating SharePoint sites as hard-coded values.
In Power Automate, all your environment variables appear as dynamic content within your flows. Utilizing your site environment variable, derived from dynamic content in your SharePoint actions, will allow your flows to reference the dynamic sites instead of hard-coded ones. This results in flexible referencing of sites in your solutions.
As your Power Platform solution deploys, it is critical to update your environment variable values to ensure correct site references. Prior to exporting your solution from development as managed, delete all current values in your data source environment variables. When you import your solution to test, UAT, production, or more, new environment variable values will be requested. Here, you select your site corresponding to the environment you are in.
If you make changes to your data schema in development, remember to run your SharePoint PnP script or else redeploy your Power Platform solution. As you gradually get acquainted with the process, updates for future deployments become simpler unless the introduction of new lists is involved.
If my explanation raised questions or needs further clarification, feel free to post them in the comments below. For more details, do check this comprehensive post I authored on the Microsoft 365 Platform Community Blog here.
ALM Solutions, SharePoint, Power Platform Solutions, Application Lifecycle Management, SharePoint Based Solutions, Microsoft Power Platform, ALM and SharePoint, SharePoint Application Management, Power Platform Services, Microsoft ALM Solutions.