Automated Power Apps Solution Checking in Build Pipelines

The Role of Static Analysis in Power Platform ALM

From your experience in C# and .NET development, you're familiar with static code analysis tools like Roslyn Analyzers or SonarQube, which check code for potential bugs, style violations, and security vulnerabilities without executing it.

The Power Apps Checker serves the same purpose for Power Platform solutions. It performs a rich static analysis check on your solution against a set of best-practice rules defined by Microsoft. This helps you identify problematic patterns related to:

• Performance: Detecting inefficient FetchXML queries, client-side scripting issues, or plugin designs that could slow down the user experience.
• Stability & Reliability: Finding unsupported customizations, uses of deprecated APIs, or error handling omissions.
• Security: Highlighting potential vulnerabilities in your configuration or code.
• Accessibility: Ensuring your apps can be used by people with disabilities.

By integrating this checker into our build pipeline, we create an automated quality gate. The build will fail if the solution doesn't meet the defined quality standards, preventing poor-quality code from ever becoming a release artifact.

Integrating the Power Apps Checker into a Build Pipeline

Let's modify the build pipeline we created a few lessons ago. The goal is to add the checker task after the solution has been exported but before the managed artifact is created and published.

Step 1: Add the Power Platform Checker Task

The Power Platform Build Tools for Azure DevOps, which you've already installed, includes a dedicated task for this.

To start, let's watch a brief demonstration of how this task is added and configured in a pipeline.

As the video demonstrates, you'll add the Power Platform Checker task to your build pipeline's agent job. The logical sequence of tasks should be:

1. Power Platform Tool Installer (already present)
2. Power Platform Export Solution (already present)
3. Power Platform Unpack Solution (already present)
4. Power Platform Pack Solution (already present)
5. Power Platform Checker (the new task)
6. Copy Files and Publish Artifacts (already present, may need adjustment)

The checker needs to analyze the .zip file of your solution. It's often most efficient to run it on the unmanaged solution file you just packed.

Step 2: Configure the Task Parameters

For a detailed understanding of all available options, the official Microsoft documentation is the best source.

Based on the documentation, here are the critical parameters to configure:

• PowerPlatformSPN: The service connection to a Power Platform environment. The checker is a service that requires an authenticated context to run, even though it analyzes a local file. This can be the same service connection used for exporting the solution.
• FilesToAnalyze: The path to the solution zip file(s) you want to check. You can use wildcards. For example, to check the unmanaged solution you just packed: $(Build.ArtifactStagingDirectory)/*_unmanaged.zip.
• RuleSet: This determines which rules to check against. You'll typically use Solution checker, which is the standard set of rules run from the Power Apps maker portal. The Marketplace ruleset is more stringent and is used for solutions being certified for AppSource.

Step 3: Configure the Quality Gate (Controlling Failure)

Simply running the checker is not enough; we need to use its results to enforce quality. This is where the task becomes a true quality gate.

As the article explains, you can control the pipeline's outcome using these key parameters:

• ErrorLevel: Specifies the minimum severity level (e.g., High, Medium) that should be considered when evaluating the threshold.
• ErrorThreshold: The number of issues at or above the ErrorLevel that are allowed before the task fails. A value of 0 means the pipeline will fail if even one issue of the specified severity is found.
• FailOnPowerAppsCheckerAnalysisError: If set to true, this will fail the task if the checker service itself encounters an error during analysis. This is a recommended setting.

For example, a common strict configuration would be:

• ErrorLevel: High
• ErrorThreshold: 0

This configuration fails the build if any issue classified as 'High' or 'Critical' is detected, forcing the developer to fix it before their code can be merged or deployed.

RulesToOverride: '[{"Id":"il-avoid-specialized-update-ops","OverrideLevel":"High"}]'
ErrorLevel: 'High'
ErrorThreshold: 0

Reviewing Checker Results

When a build fails due to a checker violation, developers need a clear, actionable report to understand and fix the issues. The checker task outputs its results in a standard file format called SARIF (Static Analysis Results Interchange Format).

Azure DevOps has excellent support for viewing these files directly within the build summary. To enable this, you need to install a free extension from the Marketplace:

• SARIF SAST Scans Tab

Once this extension is installed in your Azure DevOps organization, a new "Scans" tab will appear in your build pipeline's run summary. This tab provides a rich, filterable view of all the issues found by the checker, including:

• The rule that was violated.
• The severity of the issue.
• The specific solution component and even the line of code affected.
• A link to Microsoft documentation explaining the issue and how to resolve it.

This tight feedback loop is crucial for enabling developers to quickly address quality issues.

Conclusion

You have now enhanced your CI pipeline with an automated quality gate. By incorporating the Power Apps Checker, you ensure that every solution is validated against Microsoft's best practices before it's even considered for deployment.

Key Takeaways:

• The Power Apps Checker is a static analysis tool that finds performance, stability, and security issues in your solutions.
• It should be added to your build (CI) pipeline after exporting the solution to act as an early quality gate.
• The PowerPlatformChecker task requires authentication and the path to the solution .zip file.
• You can control when the pipeline fails using the ErrorLevel and ErrorThreshold parameters.
• Checker results are output as a SARIF file, which can be easily viewed in Azure DevOps using the SARIF SAST Scans Tab extension.

Preview of the Next Lesson

We have now built a robust, automated CI/CD pipeline for a single stream of development. However, enterprise projects involve teams of developers working in parallel. In our final lesson of this module, we will address this by learning how to develop an environment and branching strategy for team-based Power Platform development.