<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>ALM on Chris Worth</title><link>https://chrisworth.dev/skill-tag/alm/</link><description>Recent content in ALM on Chris Worth</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Wed, 10 Dec 2025 16:57:31 -0600</lastBuildDate><atom:link href="https://chrisworth.dev/skill-tag/alm/index.xml" rel="self" type="application/rss+xml"/><item><title>Implementing Power Platform ALM with CLI Solution Export and Unpacking</title><link>https://chrisworth.dev/posts/power-platform-cli-alm-solution-extraction/</link><pubDate>Wed, 10 Dec 2025 16:57:31 -0600</pubDate><guid>https://chrisworth.dev/posts/power-platform-cli-alm-solution-extraction/</guid><description>&lt;p>Manual Power Platform deployments create unnecessary risk. Exporting solutions through the UI produces opaque .zip files with no visibility into what changed. Canvas apps remain binary .msapp files that source control can&amp;rsquo;t diff. Teams work blind, with no code review process and no way to track who changed what or why.&lt;/p>
&lt;p>The Power Platform CLI solves this by extracting solutions and canvas apps into source-controllable files. Once unpacked, you can version components in Git, review changes in pull requests, and automate deployments through CI/CD pipelines. The workflow transforms Power Platform development from manual exports to proper application lifecycle management.&lt;/p></description></item><item><title>Why You Should Be Using Solutions in Power Platform</title><link>https://chrisworth.dev/posts/power-platform-solutions-guide-best-practices/</link><pubDate>Sat, 15 Mar 2025 09:00:00 -0600</pubDate><guid>https://chrisworth.dev/posts/power-platform-solutions-guide-best-practices/</guid><description>&lt;p>I spent a painful weekend manually recreating flows between environments, only to discover on Monday morning that I&amp;rsquo;d missed several critical dependencies. That experience taught me a harsh lesson: building Power Platform components without solutions is like building a house without blueprints. Eventually, you&amp;rsquo;ll pay the price when you need to move or rebuild anything.&lt;/p>
&lt;h2 id="the-true-cost-of-unstructured-development">The True Cost of Unstructured Development&lt;/h2>
&lt;p>Let&amp;rsquo;s be direct: if you&amp;rsquo;re building anything in Power Platform without solutions, you&amp;rsquo;re creating technical debt with every component. I learned this through painful experience:&lt;/p></description></item><item><title>Power Platform Best Practices: Managing Connection References and Environment Variables</title><link>https://chrisworth.dev/posts/power-platform-connection-references-guide/</link><pubDate>Fri, 28 Feb 2025 00:00:00 -0600</pubDate><guid>https://chrisworth.dev/posts/power-platform-connection-references-guide/</guid><description>&lt;p>The first Power Platform solution I deployed from Development to Production failed immediately: every flow was still pointing at my Dev connections and Dev SharePoint URLs. That&amp;rsquo;s the exact failure mode connection references and environment variables exist to prevent, and it&amp;rsquo;s why managing them across environments isn&amp;rsquo;t a &lt;em>nice-to-have&lt;/em>. It&amp;rsquo;s essential.&lt;/p>
&lt;p>If you build solutions in Microsoft Power Platform across multiple environments (Dev, Test, Prod), you need a clear strategy for connection references and environment variables. Done right, it makes deployments smoother and maintenance easier. In this post, I&amp;rsquo;ll outline the best practices I&amp;rsquo;ve learned (often the hard way) to keep these components organized.&lt;/p></description></item></channel></rss>