Reading Time: 5 minutes

First off, before I even begin to dive into this topic, I should mention this project is currently EXPERIMENTAL. So, please, PLEASE, don’t use it in a production scenario. Unless of course you enjoy giving yourself headaches or just want to be this guy:

Ok, now that I’ve provided my little warning if you will, lets jump into it.

YAML you say…

Before jumping into the nitty gritty of exporting your Power App to YAML, lets take a look at what on earth YAML is.

So perhaps you were like me and you had heard of YAML, but simply had never touched it (most of my experience is with JSON or XML). Or perhaps you have no clue what I just said. Regardless of where you sit, lets take a brief look at what is YAML? Well YAML stands for YAML Ain’t Markup Language (yeah it’s a recursive acronym) made 19 years ago (it’s oldddd) and is a human-readable data storage language (much like JSON and XML). The first question I had when I heard they were using YAML instead of JSON is what is the actual benefit of using one over the other? Well the one major difference that stood out for me is YAML supports comments! Perhaps I’m the only person that thought this was cool, but I always found it quite saddening that JSON didn’t provide this feature (cries in the corner). Another major difference is YAML uses double spaces to denote hierarchy instead of curly brackets. So its sort of like comparing Python syntax to C++, maybe not, but you get the gist.

Ok, enough YAML talk, lets get to the meat and potatoes

Mmmm potatoes. If you currently or have every worked with Power Apps, especially with a team, you probably know how frustrating it can be to track changes. For example, a large Power App that I’m currently working on for a client is broken out into two distinct major app versions, the development app and the production app, each with their own environment. The development environment also has development apps for each developer working on the project, in this case two extra apps that are based off the development app from the previous sprint.

So you’re probably thinking to yourself, how do you apply your changes that you have implemented into your dev app to the main dev app and then to the production app. Well, manually of course. Yeah, up until this point, version tracking was non existent (yes you can revert to previous published version, but you can’t track changes). For a developer like myself this is quite painful, especially when you are working on a Power App that is quite big and complicated.

So how is Microsoft going to solve this issue? That’s right, YAML. Now, you may be arguing that YAML is probably not the greatest approach to fixing this problem, and maybe you are right, but for now I’m just happy that there is a step in the right direction to be able to track changes to Power Apps. Also, it means you can check your changes into git (all developers clap ecstatically).

Lets take it for a test drive, shall we

Like any new shiny product, sometimes its best to just fire it up and drive it on the track. To begin, make your way to the GitHub page for the product and follow the instructions to install the CLI. In the future, this feature will reside in Power Apps CLI. Once you’ve downloaded the repository, double-click on \build.cmd to build the exe.

Let’s test this out. First thing you will want to do is make your way to make.powerapps.com and export one of your Power Apps. For the purpose of this article, I will create a sample app, in my case Power Apps Training for Office.

Now that we have a Power App to export, lets export it. In the studio edit mode of the app go to File > Save as > This computer. You will now have a .msapp file downloaded to your machine. Next thing we want to do is unpack our msapp file with your new and shiny CLI Power App tool. So in PowerShell, cd into the directory \bin\Debug\PASopa\ from the repository folder. Below I’ve listed command to unpack your msapp to your machine.

.\PASopa\PASopa.exe -unpack {YourPath}\PowerAppsTraining.msapp {YourPathForUnpacking}

Once you’ve run this command, you’ll notice it will spit out a bunch of folders and files that you can start playing with. The screenshot below is what happened when I ran it for the training for office Power App.

What you’ll notice is there a few key folders that might peak your interest here.

• Connections
  • This is where you all of your connectors live. They all reside in a single Connections file which is of file type JSON.

• DataSources
  • If your app connects to any data sources, you should find them all listed here. You will also find your galleries listed here. Unlike your connections, data sources are separate. And yes, they too are JSON files. 🙂
• pkgs
  • These are the various packages that you use in your app. So if you use a drop down menu for example, the package for that will be included here. Now these puppies are of file type XML, because hey, who likes to be boring and stick with JSON (I kid). What’s neat about this is you can take a peak at the inner workings of each object. I haven’t tried playing around with these package files yet, but I will try changing them to see if I can package them with my changes and if something comes out of it will write a blog article on it.

• Src
  • And finally, we reach the pièce de résistance, our screens! You might have been thinking when I was going to mention YAML, well here it is. YAML for days! Each object and its properties are listed here that you can modify and track.

So, where to now?

Git baby! That’s right, time to check this app into your favourite version control service so we can actually track what’s going on. Something I’m going to look into and plan to write a blog on is automating this process. Now that we can unpack and package our Power Apps, it would be awesome to build a quick little pipeline that does that all for us. Only thing I’m not sure how or if its possible to do is to update your app on Power Apps’ service without you having to manually upload it yourself. This is something that if doesn’t exist, I hope (please Microsoft it you’re listening) will eventually be implemented.

Lets wrap it up already

Hope you enjoyed this little article. Make sure to follow along to catch my next blog posts. Will definitely be exploring using this tool more and once it’s pushed to GA will be using it for client projects to make life easier to track changes and push builds out.

Until next time! ✌️