Hello, I have a question about the best way to deploy MSI packages with DSC that maintain the Continues Deployment/Delivery principles.
Currently in my organization our developers create an MSI for each component version that we develop, now I am using the Release Management for VS to deploy with Powershell scripts, all works good but I would like to migrate these scripts to the DSC format.
My problem starts with the "Package" resource, which requires me to set a product code parameter for the MSI deployment and that is bad for automation, because I need to manually go to the scripts and set the product code for each version I want to deploy.
I would like that my scripts will not be effected of the MSI product code or at least not to deal with that manually.
What is the best way to deal with that situation?
The Package resource is problematic on good days. Frankly, I think your time would be well-invested creating a custom resource to help you deal with this in a way that makes sense for your environment – perhaps querying the latest version from a central repository, checking the local version, etc.
Thanks for the reply, like you said I've found a way to create my own resource with the script resource (TestScript,SetScript), which starts the msiexec.exe process inside within the SetScript phase, and also checks the currently installed version from the Registry in the TestScript phase to see if the product is already installed, maybe it's not the best but at least it works.
Timor, Just to reconfirm: I use exactly the same strategy for all my own resources: Making sure no changes need to be made in de DSC configuration to be able to deploy a new version of a product. Like yourself, I've created a custom resource. It makes sure that whatever is the newest MSI in a specified share, is installed locally.
Using this strategy, I don't have to train everybody who deploys releases in using DSC. All they need to be able to, is copy a file.