I blogged about it before, but now that ItAintBoring.CDS.PowerShell library has been fine tuned, it might be time to do it again.
There are three parts to this post:
- ItAintBoring.CDS.PowerShell installation instructions
- ItAintBoring.CDS.PowerShell usage example
There are different ways we can set up ci/cd – we can use Azure Devops, we can use PowerApp Build Tools, we can use various community tools, or we can even create our own powershell library.
Each has some pros and cons, but this post is all about that last option, which is using our own “powershell library”.
What are the main benefits? Well, it’s the amount of control we have over what we can do. You might say that “no code” is always better, but I would argue that, when you are setting up ci/cd, “no code” will probably be the least of your concerns.
Anyway, in this case we can use the library to export/import solutions, and, also, to export/import configuration data. Including, as of v 1.0.1, word templates.
1. Create a new folder, call it “CDS Deployment Scripts”(although, you can give it a different name if you prefer)
2. Create a new ps1 file in that folder with the content below
$sourceNugetExe = “https://dist.nuget.org/win-x86-commandline/latest/nuget.exe”
$targetNugetExe = “.\nuget.exe”
Remove-Item .\Tools -Force -Recurse -ErrorAction Ignore
Invoke-WebRequest $sourceNugetExe -OutFile $targetNugetExe
Set-Alias nuget $targetNugetExe -Scope Global -Verbose
./nuget install ItAintBoring.CDS.PowerShell -O .
Here is how it should all look like:
3. Run the file above with PowerShell – you will have the scripts downloaded
4. Update system path variable so it has a path to the deployment.psm1
For the remaining part of this post, you will need to download sources from Git (just clone the repo if you prefer):
That repository includes all script sources, but, also, a sample project.
1. In the file explorer, navigate to the Setup/Projects/DeploymentDemo folder
2. Update settings.ps1 with the correct environment url-s
Open settings.ps1 and update your connection settings for the source/destination. If you are just trying the demo, don’t worry about the source, but make sure to update the destination.
3. IF YOU HAD A SOURCE environment
Which you don’t, at least while working on this example. But the idea is that, if you start using the script in your ci/cd, you would have the source.
So, if you had a source environment, you would now need to update Export.ps1. The purpose of that file is to export solutions and data from the source:
You can see how, for the data, it’s using FetchXml, which also works for the Word Document Templates.
4. Run import_solutions.ps1 to deploy solutions and data to the destination environment
5. Run import_data.ps1 to deploy data (including Word Templates) for the new entities to the destination environment
As a result of those last two steps above, you will have the solution deployed and some data uploaded:
Most importantly, it literally takes only a few clicks once those export/import files have been prepared.
And what about the source control? Well, it can still be there if you want. Once the solution file has been exported, you can run solution packager to unpack the file, then use Git to put it in the DevOps or on GitHub. Before running the import, you will need to get those sources from the source control, package them using the solution packager, and run the import scripts.
Hi there! qq, does this apply to power automate solutions? thanks
It just works with solutions – does not matter what’s in them