Power Pages portal deployment strategies how-to

Power Pages is a CMS portal solution from Microsoft and based on Power Platform. It allows you to create secure, low-code websites for external users (customers, partners, vendors, etc.) to interact with your business data stored in Microsoft Dataverse. Today I would like to discuss possible release management strategies related to Power Pages-based solutions and explain differences between different approaches and tools that make solution deployment possible.

PAC CLI

Power Platform Command Line tools give you the possibility to download Power Pages configurations, modify them in your local development environment, and upload them into the selected destination environment. It looks like the great and easy option for releasing new application version. However, there are some cons you need to take into consideration when using PAC CLI for moving Power Pages between Dataverse instances.

The main problem is that all the Dataverse components (for example, custom tables and their forms) are not copied together with portal configuration files. They may be used by our site’s web pages, so many functionalities may not work correctly if we do not copy them with a separate process (manually or with some DevOps automation tool). Also, other Dataverse components that may be used by our portal (plugins, flows) are not part of our download package and need to be exported separately.

On the other hand, despite what the most popular IA tool 😉 told me when I asked it about it, security artifacts like web roles or table permissions are exported by the pac pages download command at this moment. So there is no need to use additional tools (for example, the Configuration Migration Tool) for copying them into target environments.

Dataverse Solutions

Dataverse solutions, on the other hand, are perfect for moving Power Pages portal configurations between environments together with dependent artifacts (plugins, flows, tables’ forms, etc.). What’s more important, there are many DevOps tools supporting exporting solutions from source, unpacking them into repositories, and importing them into destination environments. If we’re thinking about version and release management processes for all the Dataverse-based components, using solutions for this purpose may definitely be a better option.

Summary

So, let’s try to summarize when use which option of exporting a Power Pages website. In case we’re developers trying to modify its configuration or code on your local machine, using command-line tools is a definitely better option. It gives you the possibility to work with portal code locally using your favorite development tools (for example, Visual Studio Code). You can also commit your changes to your GIT repository,, which gives you an option of working with code branches, solving conflicts, etc. On the other hand, when you need to move build artifacts into destination environments, Dataverse solutions feel like a betterer option. You may pack your website together with other solution components, and you’ll be able to deploy a fully functional, working artifact into destination environments.

People say that a picture can convey as much information as a thousand words. So let me summarize this short text with diagrams below.

The first diagram visualizes the process of Power Pages portal development by a single developer. The solution with site configuration and code may be imported into the target environment with Power Platform Pipelines.

On the other hand, the second one describes a multiple-developer Power Pages development process scenario, where every developer uses his/her own Dataverse instance. Power Pages configuration and code may be run in developers’ owned environments, however the final ready-to-deploy version is exported to the GIT repository, and all the changes are merged in the code repository. The final step is building a solution with a portal and other components by DevOps pipeline and releasing it into the target environment.