I imagine that would work just fine. The XML is fairly consistent so you should be able to just define it with the same structure Blue Prism expects.
There are a few downsides that I see:
- You'll have to validate/update your utility each time you upgrade Blue Prism, especially with upgrades such as from v5 to v6 or from any version to v6.6.
- You lose the ability to verify the contents of the package in your lower environment. This isn't a big deal if you are using some external repository in order to maintain a history of the components.
Also, what if you considered not worrying about releases in Blue Prism itself and instead just maintain 'packages' in your external repository. For example, you could do as you suggested and export all the needed processes and objects of a particular automation. Then upload to your code repo. In that repo, build packages that contain each of those components. But then when you import into the higher environments, it downloads the 'package' from the repo but it imports each process and object individually into Blue Prism. There is still an easy to reference audit history (given the right SQL queries if not using the UI), and you have your external repo tool that shows what was in the package and which components are tied together. This would avoid the need to build a tool that would build releases. In my opinion, the release functionality is nice, but it isn't really required.
Anyway, eventually Blue Prism will likely be either adding more CLI commands or creating a better API for Blue Prism to handle scenarios like this. Not sure that you'd want to wait for it, but there's that too.
------------------------------
Dave Morris
3Ci @ Southern Company
Atlanta, GA
------------------------------
Dave Morris, 3Ci at Southern Company