Continuous Delivery to IIS or Windows Azure Web Sites

Deployment pipeline in TeamCityDeploying ASP.NET applications can be done in a multitude of ways. Some build the application on a workstation and then xcopy it over to the target server. Some use a build server, download the artifacts, change the configuration files and xcopy those over to the server. The issue with that is something bad creeps in: deployments become unpredictable.

Using the premise of Continuous Delivery, we can make deployments predictable. Automating all the steps will ensure that deployments can always be done and reproduced, ideally by going through a pipeline of environments.

TeamCity may have been developed with Continuous Integration in mind, it also comes with all features required for doing Continuous Deployment!

Head over to our tutorial about Continuous Delivery to IIS or Windows Azure Web Sites and see for yourself. We’ll go over the basics of deployments for ASP.NET applications and see how we can deploy an ASP.NET MVC project to IIS or Windows Azure Web Sites from our TeamCity server by promoting our CI build to development, staging and production.

Are you already deploying with TeamCity? Or would you like to? Where to? Let us know!

Happy deploying!

About Maarten Balliauw

Maarten Balliauw is a Developer Advocate at JetBrains, working on .NET tools. He focuses on .NET, Azure, web technologies and application performance. Maarten is a frequent speaker at various national and international events. In his free time, he brews his own beer. Follow him on Twitter or check his personal blog.
This entry was posted in Features, How-To's and tagged , , , , . Bookmark the permalink.

3 Responses to Continuous Delivery to IIS or Windows Azure Web Sites

  1. Robert whitelock says:

    In the tutorial it mentions about pinning builds using the api.

    At what part would you a pin a build , each step or the last part of the chain

    • Maarten Balliauw says:

      Hi Robert,

      As pinning is meant to be used to prevent a build from being removed during cleanup, it really depends on your workflow. In the example outlined in the tutorial, I would probably pin the CI builds that are promoted to any of the target environments. It could be useful to also pin the deployments as well, because those are the actual binaries that are in production and they can be used to do troubleshooting if needed. It would be a shame if a cleanup removed those binaries, right?

      Hope this helps,

Comments are closed.