Almost a month has passed since the previous post on the DevOps topic, so, the imaginary “Debbie” developer has left the project, and, it seems, I have to finish development of that second feature myself… Oh, well. Let’s do it then!
(Tip: if you have no idea what I am talking about above, have a look at the previous post first)
1. Run Prepare Dev to prepare the dev environment
2. Review the environment to make sure unmanaged solution is there
3. Add new field to the Tag entity form
4. Run Export and Unpack pipeline on the Feature2 branch
This is to get those changes above pushed to the Feature2 branch
5. Make sure I am on Feature2 branch in the local repository
git checkout Feature2
Since I got some conflicts, I’ve deleted my out-of-sync Feature2 first:
git checkout master
git branch -D Feature2
git checkout Feature2
git pull origin Feature2
6. Update the script
At the moment of writing, it seems PowerApps Build Tools do not support solution packager map files, so, for the JS files and plugins (which can be built separately and need to be mapped), it’s done a little differently. There is a powershell script that actually copies those files from their original location to where they should be in the unpacked solution.
In case with the script I need to modify, the script itself is in the Code folder:
The way that script gets added to the solution as a webresource is through the other script that runs in the build pipelines:
So, if I had to add another web resource, I would do this:
- Open solution in PowerApps
- Add a web resource
- Run Export and Unpack pipeline on the branch
- Pull changes to the local repo
- Figure out where the source of my new web resource would be (could be added to the same Code subfolder above)
- Update replacefiles.ps1 script to have one more “Copy-Item” line for this new web resource
Since I am not adding a script now, but, instead, I need to update the script that’s there already, I’ll just update existing tagform.js:
7. Commit and push the change to Feature2
git add .
git commit –m “Updated tagform script”
git push origin Feature2
8. Run Prepare Dev build pipeline on Feature2 branch to deploy updated script
This is similar to step #1
Note: the previous two steps could be done differently. I could even go to the solution in PowerApps and update the script there if I did not need/want to maintain the mappings, for example.
9. Now that the script is there, I can attach the event handler
10. Publish and test
11. Run Export and Unpack pipeline on the Feature2 branch to get updated solution files in the repository
12. Pull changes to the local Feature2 branch
git checkout Feature2
git pull origin Feature2
13. Merge changes from Master
git checkout Master
git pull origin Master
git checkout Feature2
git merge –X theirs master
git push origin Feature2
14. Retest everything
First, run Prepare Dev pipeline on the Feature2 branch and review Feature 2 dev manually
At this point, you should actually see New Entity from Feature1 in the Feature 2 dev environment:
Then, run Build and Test pipeline on the Feature2 branch and ensure all existing tests have passed.
15. Finally, merge into Master and push the changes
git checkout master
git merge –X theirs Feature2
git push origin master
16. Build and Test pipeline will be triggered automatically on the master branch – review the results
Ensure automated tests have passed
Go to the TestMaster environment and do whatever manual testing is needed
Contents:
- DevOps project sample: https://dev.azure.com/itaintboring/_git/CDSDemo
- Part 1: https://www.itaintboring.com/dynamics-crm/cicd-for-powerplatform-round-3/
- Part 2: https://www.itaintboring.com/dynamics-crm/cicd-for-powerplatform-making-changes-and-merging/
- Part 3: https://www.itaintboring.com/dynamics-crm/cicd-for-powerplatform-developing-feature2/
Hi Alex.
I am following your CICD posts and those are great contents.
The project that I am working at the moment, we are also implementing CICD but we are behind you.
Are you using the new ‘PowerApps build tools for Azure DevOps’ instead of Wael Hamze solution? It would be good if you could share with us how you created your pipeline steps and how you created the access for PowerApps build tools.
Thanks,
Gabriel.
Hi Gabriel,
I am using PowerApp build tools, since this is what I wanted to try. There are a few things which are missing there, but, overall, they work. I think you should be able to see the pipelines, since it’s a public project: https://dev.azure.com/itaintboring/CDSDemo
Although, I do need to write something up for this kind of questions to clarify a few things, so that post is probably coming in the next week or two
Hi Alex,
Thanks for these blogs. They are very clear and well thought out.
I do I have a questions which arose when we tried to implement the same.
We have 2 developers each with own development environment, upon export of the solution we have noticed the solution.xml files differ in layout and when you do a pull request this will flag as conflicts which is causing us issues and concerns as they seem unnecessary as they are same content but on different lines. Basically the missing dependencies are all there but on different lines hence causes conflicts.
How did you handle this as seems from your blog you are doing the same scenario but not encountering this problem?
We tried using the .gitignore to untrack the solution.xml file but found when we added a new entity this was missing as was no in the root components of the solution.xml.
Any help would be much appreciated.
Thanks,
Peter
Hi Peter, if you are running into the XML “sorting” problem with the solution packager, the only workaround I know of is to actually sort the contents of those files before doing the merge. That file should still be in git, since it serves as a “reference table” for the solution. Might try to adopt/build on something like this: https://github.com/DEMCON/XmlSorter Although, I think I saw a library on github which does solution files sorting, but I couldn’t find it right now.
is it possible to maintain different translations for one solution using CI/CD? Need solution to manage different translations from one solution that will distributed to different customers using CI/CD? Can be source controlled as well