Maker Deployment page

Makers can now view all their deployments in one place, regardless of solution or pipeline. If their deployment began from (or was deployed to) the current environment, they will be able to view the run history status of it. Failed Deployments and Active Deployments are highlighted in a convenient overview, so you don’t have to go looking for them either!

In addition to deployment visibility, we’ve included a Get started section that will evolve over time. For now, it will link to documentation to help a maker begin their journey to healthy application lifecycle management (ALM).

To further improve understanding of what healthy ALM looks like, we’ll soon be adding recommendations, where makers are alerted to resolve any potentially unhealthy ALM-related behavior, such as housing high-use apps outside of a solution.

Admin Deployment page

The Deployment page in the new admin center provides a streamlined experience to help administrators learn about, setup, and operation best-in-class ALM. The initial preview provides a central location to view all deployments in the tenant, approve deployment requests, and troubleshoot failures.

Select a pipelines host from the picker to see all the pipelines and deployment history managed with that host. A dedicated Failed deployments view helps admins quickly identify and troubleshoot failures and trending issues.

Admins can approve or reject deployment requests assigned to them. First setup Delegated deployments with service principals as the recommended way to deploy securely.

It is important that admins review changes in the solution and the sharing request. With the help of Copilot-generated deployment notes visible in the request, this becomes easier, but if you want a more granular look, be sure to set up Source control integration and link the repository to the approval.

Managed Operations

The Deployment pages are an offering of Managed Operations, allowing all who make or administrate to gain further insight into their Application Lifecycle Management to ensure that business solutions are reliable and performant in production. Aside from just deployment pipelines, these maker and admin experiences will evolve over the coming months and include many more Managed Operations intersections to take advantage of. So, stay tuned for more updates and please leave your feedback below!

Learn more

Admin Deployment page

Maker Deployment page

Managed Operations

New Power Platform Admin Center

The post Introducing Maker and Admin Deployment Pages appeared first on Microsoft Power Platform Blog.

It just takes a few seconds to connect your Dataverse environment to Git. You can connect and use Git integration within Power Apps, Microsoft Copilot Studio, Power Automate, and Power Pages. You’ll also need access to an Azure DevOps Git repository.

Rollout is in-progress. Git integration is currently available in public geos outside the US. Your environment must be enabled for early access and accessed at https://make.preview.powerapps.com.

As the team develops, Dataverse tracks everyone’s changes. When ready, commit your changes to a branch in the connected Azure DevOps Git repository. A commit link is provided to view the changes within the repository and compare diffs. You’ll notice solutions and solution objects are now stored in human readable formats in the repo.

Professional developers can work in source control while others work in one or more environments. It’s easy to pull others’ changes into other development environments which are connected to the same source code location. This allows team members to build without others editing in their environment and share changes once they’re ready. Connect multiple development environments using the same repo, branch, and folder. Then, in each environment create or import an unmanaged solution with the same name and publisher.

When committing and pulling changes, conflicts may be detected – meaning someone else made conflicting changes to the same object. You’ll need to choose whether to keep the version that’s in your environment or bring the version from source control into your environment. You can also revert changes in the repository, then pull the prior version into your environment.

When the team is ready to deploy to test or production, you can use Pipelines in Power Platform for the release. Building and deploying using developer tools isn’t available yet for this new format.

We hope you enjoy the preview. There are many current limitations and you shouldn’t use this feature in environments or Git folders where you’re developing production solutions. Please leave your feedback below, in the community forums, on social media, or another outlet of choice. We look forward to hearing what you’d like to see prioritized next.

Learn more

Overview of Power Platform Git integration

Setup Git integration

The post Introducing Git Integration in Power Platform (preview) appeared first on Microsoft Power Platform Blog.

With these updates, we’re excited to announce the general availability of delegated deployments for pipelines in Power Platform!

Additionally, admins can now enable pipelines for multi-geo support, making it easy to centrally administer global deployments within a single management plane.

Build

As makers develop, customizations are automatically saved to their preferred solution (no need to understand or navigate to solutions). This avoids downstream deployment issues, painful debugging steps, and other common mishaps.

 When authoring solution cloud flows, drafts and versioning provides a history for each published version of the flow. Makers can view the version history, restore prior versions, and save draft changes without publishing them live – even if the flow has errors! Then, the flow can be published when they are ready to run the flow. Please leave your drafts and versioning comments and feedback here.

Test

Admins can improve quality by ensuring solution checker runs on every deployment, and configure issue tolerance levels for different environments. Pipelines can be extended to run additional code and security scanning tools, or automated tests by integrating your source control systems. Functional user acceptance testing is also recommended after deployment to test environments.

We recommend starting with pipelines in Power Platform and using extensions if you need to integrate more advanced workloads running in Azure DevOps, GitHub, etc. Similarly, if taking dependencies on test automation, we recommend Test Engine.

Release

Makers are guided to deploy at the right time. For example, when manually exporting and importing solutions or blocked by sharing limits.

Instead, sharing is requested during deployment to target environments, like production, where it’s appropriate to share broadly. Admins simply need to approve the combined deployment and sharing request, and the rest happens automatically. Sharing is rolling out for canvas apps and soon for cloud flows and security roles.

Makers can also update existing environment variables and connection references in pipelines and solution import. Combined, these capabilities protect production assets with least privileged access, reduce admin burden, and train makers to submit all updates via your organization’s change management process. If admins haven’t configured pipelines and governance policies, makers are empowered to create their own pipeline to environments (they must already have access to manually import solutions. Pipelines doesn’t escalate permissions). Admins can apply additional governance controls and manage security within the default host and custom hosts. There’s a new entry point within the solution experience to Manage pipelines and a Security Teams section in the app to manage pipelines access. Note: we currently recommend using a custom pipelines host when more advanced control is desired.

 

Why pipelines vs manual export/import? Unlike manual export/import, pipelines stores backups for every version of every solution deployed, and admin accessible audit logs describing who, what, when, where, and why (AI provided). Pipelines deployments enjoy higher success rates by pre-validating solutions against target environments and sequencing multiple deployments to avoid conflicts. 

 

Solution simplification remains an ongoing effort. Recent improvements include streamlined dependency management and automatic conversion of unmanaged to managed solution objects (see moving from unmanaged to managed solutions).

 

What if breaking changes are inadvertently deployed? Now makers and admins can now re-deploy prior solution versions using pipelines or developer tooling.

 

Documentation

• ALM Guide
• Pipelines in Power Platform
• Managed environments
• Power Platform Developer tools
   

The post April 2024 ALM blog: What’s new and what it means for you appeared first on Microsoft Power Platform Blog.

• Open and inspect the object.
• Delete the object.
• Remove dependency between the objects.
• Open documentation to learn more about the dependencies for that object type.
• Delete the solution taking dependency on the solution object.

The post Working with solution dependencies for objects made easier appeared first on Microsoft Power Platform Blog.

Solutions are used to transport apps and components from one environment to another or to apply a set of customizations to existing apps. A solution can contain one or more apps as well as other objects such as site maps, tables, processes, web resources, choices, flows, and more. A solution and its objects are stored in Microsoft Dataverse. Solutions are also the key mechanism for implementing application lifecycle management (ALM) in the Power Platform. For more information about solutions, see Solutions overview, and application lifecycle management (ALM) guide

Unlike model-driven apps and most other objects, makers can optionally create their canvas apps outside of a solution and outside Dataverse. This can lead to unhealthy ALM practices, and create an overhead for DevOps teams and admins as they try to automate their ALM process.

With this feature, environment admins will be able to set citizen makers and developers in a healthy ALM ready state from day one by enabling canvas apps as Dataverse solutions by default for one or more environments.

Enable canvas apps creation as Dataverse  solutions by default 

Canvas apps in solutions by default feature is disabled by default. However, environment admins can enable this feature by going to environment advanced settings, Product Settings, and toggle the feature “Create new canvas apps in Dataverse by default”  to “On” to enable the feature.

Default behavior

By default, this feature saves all canvas apps to the default solution named Common Data Services  (CDS) Default Solution published by Microsoft Dataverse Default Publisher (see below). As a best practice, we recommend that makers create their canvas apps in custom solutions or move canvas apps created from the default solution to a custom solution to facilitate the management of solutions and establish a common standard across all environments.

As always, we would love to hear from you on how we could keep improving this feature. Please leave your feedback and comments on this post so that we can keep track of your comments and requests.

For more information about adding canvas apps in solution by default, see Add canvas apps to solution by default (preview).

See related:

Manage feature settings in a Power Platform environment
Implement healthy solution ALM with canvas apps in solution by default

The post Creating canvas apps as Dataverse solutions by default (preview) appeared first on Microsoft Power Platform Blog.