Deploy ASP.NET web site and Update MSSQL database

2019-02-02 00:31发布

I have question about ASP.NET web site and MSSQL database deployment. We are hosting asp.net web site and developed new version, the some asp.net files are changed and database is modified a little. What is the best why to upload new version of web site and upgrade MSSQL database without downtime?

3条回答
成全新的幸福
2楼-- · 2019-02-02 01:10

Not to do it. Point.

ZERO downtime installs´s are VERY hard to do and involve multipel copies of the database, prechecking it in a staging engironment, carefull programming and resyncing the database.

It is pretty much always better to take a small downtime. Sleep long in the night, deploy at 2 in the morning. Or wake up earlier. Identify when it is lease inconvenient for your users.

100% uptime is VERY expensive to imeplement, in terms of the amount of time spent on it. Unless here is a strict business case for it, occasional downtime is a much saner busienss decision.

查看更多
迷人小祖宗
3楼-- · 2019-02-02 01:13

Even large sites like salesforce.com and ebay.com have scheduled maintenance windows in which at least portions of those sites are unavailable for a certain period of time due to changes to the backends.

For ebay it's every Thursday night and lasts for 4 hours in which "certain features may be slow or unavailable during this time". For salesforce, they schedule and notify users as needed.

Depending on your site, you might be better off scheduling a 1 hour window at some late hour in which your site is at it's lowest traffic level. Notify users ahead of time at 1 week before, 1 day before, and 1 hour before.

Prior to taking it offline make sure you test your deployment from a copy of your current production database on a different server. This will give you an idea of any problems you could run into as well as let you know exactly how long it should take. Double that number when notifying users. Run the tests multiple times to ensure not only the time it's going to take but also to verify data consistency.

Duffman has a good answer with regards to running versions in parallel for a very short window in order to get the updates pushed. However, their is usually a reason for data model changes and it's typically better to transform all of your existing data at the time of deployment. Running this transformation might make certain transactions invalid while it's going on and result in corrupted data.

Having gone through many "hot" production pushes I can say with 100% certainty that neither I nor my clients ever want to deal with those again. There is absolutely no room for error.

查看更多
干净又极端
4楼-- · 2019-02-02 01:16

I've managed a large website for the past 5 years with monthly releases and manage to have zero downtime more than 95% of the time. The key, unfortunately, is ensuring that the database is always backwards compatible, but only to the previous release, so you have the opportunity to rollback.

So, if you plan to drop a column, for example, that your application depends on:

  1. Change your application code to not depend on the column, and release that (without removing the column in the database).
  2. In the next release drop the column (as the application no longer relies on it).

It takes some discipline from your dev team, but is surprisingly easy to achieve if you have proper the right environments setup (dev/test/staging/production).

When you release:

  1. Deploy database changes to a staging environment, which is as close to production as possible. Do this preferably in an automated fashion, using something like SQL Compare and SQL Data Compare, so you know the database is completely up to date with your test environment.
  2. Perform "smoke tests" using the old application, but the new database schema, ensuring no major breaking changes have been introduced to the database.
  3. Release your application code.
  4. Smoke test your staging application.
  5. Release to production.

Another thing we do to ensure zero downtime on the website is blue-green deployment. This involves having 2 folders for each website, updating one and switching the IIS home directory once it is up to date. I've blogged about this here: http://davidduffett.net/post/4833657659/blue-green-deployment-to-iis-with-powershell

查看更多
登录 后发表回答