The .NET approach to releasing apps

From the start, .NET folks are quite happy with the technologies and tools they use, and their deployment processes. Unlike in Java, they do not complain about the need to redeploy and time it usually takes, right from the very start.

The “Microsoft way” of releasing apps carried out using visual tools like Visual Studio and Team Foundation Server. It involve several mouse clicks and setting numerous checkboxes. The integration between Visual Studio and Team Foundation Server provides a well-defined, but not very customizable process. They build and package releases, generate MS SQL Server database evolution scripts and deploy directly to Internet Information Server (IIS). Few teams take an alternative approach. They prepare releases with continuous integration (CI) servers like Jenkins, CruiseControl or TeamCity, and deploy to IIS using command-line tools like msdeployappcmd and scp.

So what wrong with the current process?

Since the releases happen either by executing scripts or by copying application files over to a virtual folder in IIS, there is no reliable way to keep track of which app version is deployed in which environment. Furthermore, updating apps interrupt end users and any deployment failures take time to recover from. We asked .NET folks about these issues and here are the answers we got:

  • How are app versions and the environments they are deployed to currently tracked?

    • CI servers provide logs about successful builds

    • List in team wiki

    • Shared document (e.g. an Excel sheet) on a shared network drive

    • Folklore (asking someone who knows)

  • Do app updates in production cause user interruption?

    • Typically, 100% availability is not guaranteed. Updates and maintenance require downtime and can lead to the loss of user sessions.

    • Some companies use expensive load-balancers (e.g., F5) to drain sessions and reroute new requests to another server while performing the update. This process is still very “manual” and requires a system administrator to “flip the switches.”

  • How long to recoveries from production failures take?

    • Recovery is performed manually and could take up to several hours.

The Cure

LiveRebel orchestrates deployments after an application version has been built and packaged by the IDE or a CI server. It addresses all the issues brought up in the previous section and more (environment-specific configuration management, overview of application deployments, automatic rollback in case of failure, custom scripting, database schema management, etc). You can get familiar with all features of LiveRebel on our website.

***

For more about deploying your .NET app with LiveRebel 2.7, please read the rest of the post with screenshots here: http://zeroturnaround.com/blog/liverebel-extends-support-for-failsafe-net-application-deployments/