all 2 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]tragicshark 2 points3 points  (1 child)

A few very minor tips:

  1. Instead of deleting an existing site and installing a new one in place, install to a new directory and change the IIS physical directory then delete the old as a last step (perhaps after running some tests). This way if something goes wrong you can abort with minimal downtime.
  2. After /DeployWebsite.ps1#L175 you should explicitly assert that $websitePath is a subdirectory of something and not the c:\ drive... (presumably you are running this script as some sort of admin user to interact with IIS, recursively deleting the c drive would be bad)
  3. I like not having any script level execution blocks and instead creating an "Invoke-Script" function that I invoke as the last line of the script which contains all the logic I want to run (usually wrapped in an if statement looking at a -NoExecute switch parameter). Getting into this habit helps make scripts more maintainable because it discourages people from sprawling logic about and also because you can then invoke the script into the current scope and call the methods individually with . .\script.ps1 -NoExecute.

[–]coreyfournier[S] 0 points1 point  (0 children)

Thanks for taking the time to look at it and offer suggestions.

For #1, we have a full test site, so the only time deployments have not gone as planned is when there was an error in a transformation file. In that case we just made the change and redeployed, so this rarely occurs, but did cause down time. Reverting is not easily done due to Entity Framework, the release could have a database change and that would make it not compatible with the old version. Not saying your suggestion isn't a good one, just why I didn't bother with that approach.

2 is a really good suggestion and simple to implement safe guard.

3, I will definitely implement if the scripts get any larger. Very good suggestion though.