Reputation: 33
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:
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;
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 e.g. 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?
Upvotes: 1
Views: 594
Reputation: 788
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.
Upvotes: 1