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?
相关问题
- sql execution latency when assign to a variable
- Carriage Return (ASCII chr 13) is missing from tex
- How to store image outside of the website's ro
- What is the best way to cache a table from a (SQL)
- php PDO::FETCH_ASSOC doesnt detect select after ba
相关文章
- asp.net HiddenField控件扩展问题
- asp.net HiddenField控件扩展问题
- Asp.Net网站无法写入错误日志,测试站点可以,正是站点不行
- asp.net mvc 重定向到vue hash字符串丢失
- FormsAuthenticationTicket expires too soon
- “Dynamic operations can only be performed in homog
- What is the best way to create a lock from a web a
- Entity Framework 4.3.1 failing to create (/open) a
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.
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.
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:
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:
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