The Zen of Deployment Automation

You may also like...

7 Responses

  1. Jason says:

    Great post.

    Though one thing. Our steps are

    – Check dependencies
    – Deploy package into new folder
    – Do transforms
    – Create *new* IIS website
    – Swap bindings
    – Delete old website
    – Notify team

    There’s no outage as there would be on a stop/deploy/start (well maybe a millisecond or two, tops). There’s a post lined up about this process on the Domain tech blog, due to be published soon. It’s been working great for the last several months, and last time I checked we’d put something over 500 individual incremental deploys through it, with individual deployment tasks numbering well into the thousands.

    • ianpaullin says:

      Good point. The step really isn’t configuring IIS as it’s creating it if it doesn’t exist; if it does exist, it’s using the settings/values given but yes, your point is more succinct: create a new IIS site.

      Oh I see now. Clever. Two IIS sites and then swap bindings and delete the old site. That’s pretty interesting. I might have to give that a try.

      • Jason says:

        Yeah, it’s pretty cool. I used to be an IIS MVP and I stood there and went “whoah” when it was explained to me.

        Then again, I was an MVP before IIS 7 and powershell arrived so there you go.

        I shared the step template with the guys over at OctopusDeploy, so maybe this’ll be native in 😉

        • ianpaullin says:

          Pretty slick the more that I think about it. Granted for our environments, we have load balancers so we typically deal with Keep-Alives, but for the general public the swapping of the sites makes sense and it’s just another web deployment method available for Octopus. How do you deal with naming the sites within IIS? Do you use the same AppPool or create a new one? Do you generate the name to be used for the swap or do you have a standard format you stick to?

          • Jason says:

            New app pool, new site. There’s a version that does a basic warmup of the newly created site before switching, but we have the luxury of being on a microservice platform, so that’s minimal work. It also sometimes fails in AWS so we generally leave it out.

            new site name is based on the service name with a prefix, so I guess you could say partially generated. using the Octopus deploymentID or taskID would be a good way of handling that in a future version

            Once it goes live, it’s renamed ready for the next deployment to roll through, and the old sites are cleaned up.

          • ianpaullin says:

            Now that 2.6 can do steps in parallel, do you think you can leverage them in doing the swap or maybe doing the warmup first then the swap?

  1. July 2, 2015

    […] the same step across your environments is a treacherous path and can only lead to problems. In my Zen of Deployment Automation rant, I cover this exact issue of repeating specific steps but assigning different environments. […]

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.