ALM - Application Lifecycle Management - Build and deployment challenge

Question

I am stuck with a problem that I could use some feedback on to solve it in the best possible way.

The issue revolves around source control -> automated builds -> deployment. Basically ALM (Application Lifecycle Management).

We have a product – an ASP.NET Web application with a MS SQL database. This product is running on hundreds of websites with associated databases across multiple virtual machines in our production environment. At the moment the web applications and database are running on servers with IIS 7 and SQL Database Server 2008 R2. The product itself is source controlled in Team Foundation 2012.

For years the release of new versions of the product has been once or twice a year for years. Now we are going to focus on releasing more frequently and hence we need a strategy for the ALM for the product.

The deployment strategy now:

In the development period between the releases, the SQL update scripts has been created manually – each time a database change was made a script was updated. When the application is ready to be deployed it gets compiled on a developer machine. The database with all the changes used would be backed up into a .BAK file. The web application, the .BAK file and the update SQL script would be packaged (.zip) and uploaded to the production environment ready for deployment.

Update existing running products:

• Copy/paste the web application in the target website physical folder.
• Update the web.config file – connectionstring and application
• variables. Run the update script via SQL Management Studio

This would be done for each and every customer – hundreds of times.

This is a very tedious and error prone task and I don't like it at all!

What I would like to do instead is;

• Source control the database as a Database Project in Team Foundation
• Automatically build the web application with Team Foundation 2012 Build Server.
• Deploy the output from the Build Server to the multiple websites of the production environment along with automatically generated SQL update scripts run against the SQL Server.

I have been googling my ass off - only finding bits and pieces regarding builds, deployment, automatic SQL update script etc.

What I think is partly the right direction is to source control the database and use the TFS Build Server. I am very confused on how to do the deployment itself in an easy and controlled way using the output from the TFS Build server.

Ideally I would want to the TFS Build server to create a package with the latest version of the Web application, the latest version of the database, post deployment script including an auto generated SQL Update script from the previous build to the current build. This could be contained in eg a nuget package. Then I would want to be able to create an additional web application which should manage the deployment – target, version, iis website, sql server, web.config connectionstrings etc.

Does anyone have any advice on how to achieve this? How do you do this?

Answer 1

You can use a release management tool to do this, no need to create an additional web application.

One such example is Deployment Manager, from Red Gate. (Disclaimer: I work there.) It has built-in deployment actions for ASP.NET apps and SQL Server databases. The command line tool RgPublish.exe can be used to create a package for the web app as you describe from TFS Build. The same can be done for the database using the sqlCI.exe command line and associated NANT/MSBuild scripts.

The same packages can then be deployed to each of your servers. You may run into scalability issues with 100s of websites though.

The database deployment works by generating the upgrade script automatically, though you can change the behaviour to put the upgrade script in the package, when the package is first built. These are called "dynamic" and "static" upgrade methods respectively.