Releasing to production best practices

[tranceporter]

Good information thanks, I can't give you any rep until I share it round but will do shortly.

I'm also looking to minimize downtime of the site, this is pretty important to us. After a release we often ensure people can still do certain things and importantly pay for specific products. But this adds to the time we cant open the site to customers.

Any approaches or methods? Directory swapping, pre-production etc.

We used Server Density for this. It's not exactly the greatest, but it serves the purpose. You can have some sort of wall display which will show the status of Web and DB servers in UAT and Prod environment. Anything going red (due to lack of memory etc etc) wil become red instead of the usual green, and people should start running. If you want to check if a certain set of links to webpages are accessible, you can use pingdom. Also, BDD test cases written using Selenium webdriver with SpecFlow, can cater to these kinds of scenarios (Given, when, then test cases. e.g: Given that user is on login page, when enters his username and password, and clicks on the login button, then he should be taken to the home page). Also, if you are deploying into the cloud using Amazon Web Servers or Rackspace, then they can also keep track of your uptime, and you can get reports about these things form time to time to impress the management Of the two, I would go for Amazon, since we found RackSpace support to be wanting in terms of DB management especially. Amazon is much better.

[jmo21]

+1 for Team City, 1 click trigger of a website deploy, and kicking off SQL scripts.

[woohoo]

In last 2 places I worked at, one of them used Jenkins for continuous integration and deployment, and the other one used Team City. I liked Jenkins more because it showed a half naked man when the build failed. I personally do not have knowledge about how to set up build servers etc, but essentially this is what used to happen:

1] A developer checks in code (using subversion or tfs)
2] Jenkins detects this, and grabs the latest code form the repository.
3] It builds all the code.
4] It also starts a parallel build to execute all unit tests and integration tests.
5] If any of the build fails, it throws a red alert as expected. If you install the Hudson tray tracker, and give it path of Jenkins build server, it automatically gives a tray notification (balloon alert) to know that a build has failed. This way you do not need to monitor the jenkins build in your browser window.

In case of Team-City, it used to send e-mail to all people who had subscribed to the build. I am sure you can do the same with Jenkins. Another thing is that you can also configure Jenkins to do, is to execute code analysis (fxcop/stylecop rule adherence) and show those stats in the build. Apart from that it offers the usual reports/history thing about he previous builds, failure/success history etc. Both subversion and jenkins are open source as you already might know. Team City is free upto 3 agents (3 separate scheduled builds in total), and then you pay. TFS is only useful if you have Team Edition/Ultimate version of Visual Studio.

Regarding SQL server, it might be useful to consider investing in RedGate SQL Source Control and SQL Toolbelt. Though it has got nothing to do with deployment as such directly, it is immensely useful to maintain your SQL databases, create replica using database schema, and even replicate databases with complete data. You can also commit some of the tables as "static tables with data" (for example, a table named Cities might have the same number of rows all the time, since it not part of transactional day to day stuff, and purely used for lookup etc). That way, when you initialize a blank database using Redgate, you can also choose to seed the static SQL tables with data, which is pretty handy. Good Luck!

Good information thanks, I can't give you any rep until I share it round but will do shortly.

I'm also looking to minimize downtime of the site, this is pretty important to us. After a release we often ensure people can still do certain things and importantly pay for specific products. But this adds to the time we cant open the site to customers.

Any approaches or methods? Directory swapping, pre-production etc.

[tranceporter]

In last 2 places I worked at, one of them used Jenkins for continuous integration and deployment, and the other one used Team City. I liked Jenkins more because it showed a half naked man when the build failed. I personally do not have knowledge about how to set up build servers etc, but essentially this is what used to happen:

1] A developer checks in code (using subversion or tfs)
2] Jenkins detects this, and grabs the latest code form the repository.
3] It builds all the code.
4] It also starts a parallel build to execute all unit tests and integration tests.
5] If any of the build fails, it throws a red alert as expected. If you install the Hudson tray tracker, and give it path of Jenkins build server, it automatically gives a tray notification (balloon alert) to know that a build has failed. This way you do not need to monitor the jenkins build in your browser window.

In case of Team-City, it used to send e-mail to all people who had subscribed to the build. I am sure you can do the same with Jenkins. Another thing is that you can also configure Jenkins to do, is to execute code analysis (fxcop/stylecop rule adherence) and show those stats in the build. Apart from that it offers the usual reports/history thing about he previous builds, failure/success history etc. Both subversion and jenkins are open source as you already might know. Team City is free upto 3 agents (3 separate scheduled builds in total), and then you pay. TFS is only useful if you have Team Edition/Ultimate version of Visual Studio.

Regarding SQL server, it might be useful to consider investing in RedGate SQL Source Control and SQL Toolbelt. Though it has got nothing to do with deployment as such directly, it is immensely useful to maintain your SQL databases, create replica using database schema, and even replicate databases with complete data. You can also commit some of the tables as "static tables with data" (for example, a table named Cities might have the same number of rows all the time, since it not part of transactional day to day stuff, and purely used for lookup etc). That way, when you initialize a blank database using Redgate, you can also choose to seed the static SQL tables with data, which is pretty handy. Good Luck!

[woohoo]

Hi all,

I'm starting to look at implementing best practices for releasing software to a clients website. Well anything is better than the current half baked approach.

This is a small dev team with frequent releases.

I've done this in a number of ways over the years but would be interested in how you guys have approached it, would be really interested in experiences with IIS, ASP.NET MVC, SQL Server environment.

Ideally I want something that automatically deploys to test or live. I want to reduce the amount of manual intervention.

I also want to minimize the down time of the site. I know this isn't always possible for example if database changes are involved. But I'm thinking of having two live sites one active the other inactive. So changes can be released to the inactive, testing to ensure all is ok then swap the active for inactive.

Perhaps a pre-production server may be an idea.

Any ideas, tools that you recommend or questions are welcome

Cheers