This is a crosspost from /r/powershell since I haven't gotten any feedback there. Figured I'd see if any of you guys had experience with this, or maybe some alternate suggestions on how to accomplish what I'm doing.
Currently I do the following in powershell:
Extract .zip locally, locate web.config and nlog.config (the files that are customized per environment).
Based on environment/component (passed to script by parameters) I locate the correct web/nlog settings. (each environment/component has a json file that has all the necessary settings)
If Web App: Publish the .zip output by the build process (msdeploy command line remote publish)
Write new nlog.config and FTPS it to the correct directory overwriting the file from the package
Set app settings via Set-AzureWebsite
Write new nlog.config and web.config files with correct settings
SFTP the .zip package and both config files to file server in cloud
WinRM to the webserver and use Restore-WDPackage to publish
Copy/overwrite both config files
Package clean up
I would like to clean up this process, and my current thought is to go from 5 generic .zips to 35 customized .zips, one for each component/environment combination. This would make the packages authoritive and get me out of overwriting config files all over the place. (also for easier utilization with AWS beanstalk in the future possibly).
Anyone have any tips/thoughts on how to streamline this? It works ok now but sometimes the nlog.config doesnt seem to work properly.
Personally? I think you're doing the right thing.
Your JSON files represent the "desired state" for each environment. Those are relatively easy to edit and keep updated should changes occur.
Yes, the process of turning those into the end ZIP files is complex, but you've got a script doing it. Computers love complex stuff. I don't see your current process as being "not streamlined," actually – perhaps its just your familiarity with it that makes it seem clunky to you.
What you're doing is similar in spirit to DSC. You have an authoritative, human-readable source for desired configuration – your JSON files. PowerShell then does "a bunch of stuff" to implement those configurations.
What's more, those JSON files could be easily produced by other processes. So, if need arose, you could build a front-end that let someone else specify settings, and then produce the JSON that your deployment process uses. That's pretty elegant. The JSON serves as a configuration document, and it doesn't matter how it gets produced, so long as it's there, everything works.
Sure, maybe you have some functional clean-up to do, like making your blog.config work reliably.
But what you've got is a set of abstractions between major functional layers, and that's not a bad design approach.
Thanks Don, that's encouraging to hear.
I guess my biggest issue right now is trying to "repackage" the zip files, but from doing some more research that will probably mean getting involved in the MSBuild process directly.
You must be logged in to reply to this topic.