This topic contains 2 replies, has 2 voices, and was last updated by
June 17, 2015 at 10:00 am #26575ParticipantPoints: 0Rank: Member
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.
Doing some Azure deployments and I'm trying to figure out how to properly configure my webdeploy packages. These packages are output from Bamboo with pretty simple msbuild build plans. There are 5 websites that are deployed for my application, and I currently support 7 environments. Environments consist of a mix of PaaS azure web apps and IaaS VMs with IIS. For each build I get 1 .zip package per component and then have to figure out how to deploy them with custom configs for each environment.
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).
I have tried just extracting the zips and injecting modified configs, but I get: "The resource you are looking for has been removed, had its name changed, or is temporarily unavailable." when I publish them.
Anyone have any tips/thoughts on how to streamline this? It works ok now but sometimes the nlog.config doesnt seem to work properly.
June 18, 2015 at 8:52 am #26629KeymasterPoints: 1,785Rank: Community Hero
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.
June 19, 2015 at 7:26 am #26671ParticipantPoints: 0Rank: Member
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.
The topic ‘Working with WebDeploy packages?’ is closed to new replies.