blocks|key|1858917|text|我倾向于在另一个环境中进行所有测试(而不是在活动环境中！)。这让我可以在知道代码应该正常工作的情况下将更新推送到实时站点，并且我只需要对实时数据进行健全测试-确保我没有将文件忘在哪里，或者出现了一些奇怪的错误。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1858918|因此，在测试或暂存环境中进行适当的测试，然后进行简单的健全性检查。无需停机。|1858919|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I tend to do all of my testing in another environment (not the live one!). This allows me to push the updates to the live site knowing that the code should be working ok, and I just do sanity testing on the live data - make sure I didn't forget a file somewhere, or had something weird go wrong.

So proper testing in a testing or staging environment, then just trivial sanity checking. No need for downtime.

blocks|key|1859397|text|在工作中，我们花一段时间将代码冻结在测试环境中。经过几周的通知后，我们在周五午夜关闭了网站，通宵部署和验证，并在周六上午晚些时候将其发布。流量统计显示，这是完成此操作的最佳时间框架。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1859398|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

At work, we spend a period of time with the code frozen in the test environment. Then after a few weeks of notice, we take the site down at midnight Friday night, work through the night deploying and validating, and put it up Saturday late morning. Traffic statistics showed us this was the best time frame to do it.

blocks|key|2072829|text|如果您有一组负载平衡的服务器，您将能够逐个单独离线并对其进行更新。用户无需停机！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2072830|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

If you have a set of load-balanced servers, you will be able to take one by one offline separately and update it. No downtime for the users!

blocks|key|1859505|text|有一个可爱的、解除武装的图像和/或备份页面。一些网站实现了简单的javascript游戏，让你在等待更新时保持忙碌。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1859506|例如，失败的鲸鱼。|1859507|-Adam|1859508|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Have a cute, disarming image and/or backup page. Some sites implement simple javascript games to keep you busy while waiting for the update.

Eg, fail whale.

-Adam

blocks|key|1859166|text|这在一定程度上取决于您是否也在更新数据库。在过去，如果数据库正在更新，我们会在计划的(和发布的)维护期内关闭网站-通常是影响最小的非工作时间。如果更新不涉及数据库，那么在负载平衡的环境中，我们将从混合中取出一个盒子，部署和测试。如果成功了，它就会进入混搭中，另一个盒子(假设有2个盒子)就会被拿出来更新/测试。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1859167|注意:我们不是在测试代码，只是部署很顺利，所以停机时间是最短的。如前所述，代码应该已经在另一个环境中通过了测试。|1859168|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Some of that depends on if you're updating a database as well. In the past, if the DB was being updated we downed the site for a planned (and published) maintenance period - usually something really off hours where impact was minimal. If the update doesn't involve the DB then, in a load balanced environment, we'd take 1 box out of the mix, deploy &amp; test. If that was successful, it went into the mix and the other box (assuming 2 boxes) was brought out and updated/tested.

Note: We're NOT testing the code, just that the deployment went smoothly so down time any way was minimal. As has been mentioned, the code should have already passed testing in another environment.

blocks|key|1859601|text|对于一个免费的网站，长时间的停机时间(小时)是可以接受的。如果你对用户进行了充分的教育，他们就会明白这是一种必需品。也许给他们一些东西玩，直到网站恢复正常(例如。flash游戏，显示开发团队正在工作的网络摄像头实时馈送，等等)。对于一个人们付费访问的网站，如果你给他们提供定期的停机时间，很多人会因为抱怨而浪费你的时间。如果我在运行一项向用户收费的服务，我会避免像瘟疫一样的停机时间，并非常缓慢和谨慎地推出更新。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1859602|在我目前的设置中，我有一个辅助网站连接到与实时副本相同的数据库和缓存，以测试我的更改。|1859603|我还在cron作业上运行了几个“页面观察器”脚本，这些脚本使用正则表达式来检查网站是否正确地呈现关键页面。|1859604|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

IMHO long downtimes (hours) are acceptable for a free site. If you educate your users enough they'll understand that it's a necessity. Maybe give them something to play with until the website goes back up (eg. flash game, webcam live feed showing the dev team at work, etc). For a website that people pay to access, a lot of people are going to waste your time with complaints if you feed them regular downtime. I'd avoid downtime like the plague and roll out updates really slowly and carefully if I were running a service that charges users.

In my current setup I have a secondary website connected to the same database and cache as the live copy to test my changes.

I also have several "page watcher" scripts running on cron jobs that use regular expressions to check that the website is rendering key pages properly.

blocks|key|1859286|text|在非80端口上运行您的主服务器。在其前面的80端口上放置一个轻量级服务器(例如nginx)。更新站点时，请在新端口上启动另一个实例。测试。如果您对已正确部署感到满意，请编辑您的代理配置文件，然后重新启动它。在nginx的情况下，这将导致零停机时间或失败的请求，并且还可以提供比更典型的仅Apache托管选项更高的性能。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1859287|当然，这不能替代合适的临时服务器，它只是在有限资源下执行移交的一种“礼貌”方式。|1859288|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Run your main server on a port other than 80. Stick a lightweight server (e.g. nginx) in front of it on port 80. When you update your site, start another instance on a new port. Test. When you are satisfied that it has been deployed correctly, edit your proxy config file, and restart it. In nginx's case, this results in zero downtime or failed requests, and can also provide performance improvements over the more typical Apache-only hosting option.

Of course, this is no substitute for a proper staging server, it is merely a 'polite' way of performing the handover with limited resources.

blocks|key|1859705|text|为了在上线前在单独的开发站点上尽可能好地测试一切，我使用Selenium+(一个网页测试器)来运行站点的所有可导航部分，将虚拟值填充到表单中，检查这些值是否出现在正确的位置，等等。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1859706|它也足够强大，可以检查大量的javascript或动态内容。|1859707|然后，在升级实时站点后再次快速浏览Selenium，以验证更新是否有效，并且没有丢失链接或数据库错误。|1859708|它捕获了一些细微的错误，这让我节省了几次时间，而这些错误是我手动浏览时可能会错过的。|1859709|此外，如果您将活动站点放在某种“反向代理”或负载均衡器(如果它很大)后面，这将使它在出现问题时很容易切换回以前的版本。|1859710|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

To test everything as well as possible on a
separate dev site before going live, I use Selenium
 (a web page tester) to run through all the navigable
parts of the site, fill dummy values into forms, check
that those values appear in the right places as a result, etc.

It's powerful enough to check a lot of javascript or
dynamic stuff too.

Then a quick run-through with Selenium again after 
upgrading the live site verifies that the update
worked and that there are no missing links or database errors.

It's saved me a few times by catching subtle errors that
I would have missed just manually flicking through.

Also, if you put the live site behind some sort of "reverse proxy"
or load balancer (if it's big), that makes it easy to switch
back to the previous version if there are problems.

blocks|key|1859798|text|使其对用户透明的唯一方法是将其置于负载平衡代理之后。当您更新另一台服务器时，您需要关闭一台服务器。然后，当你完成更新时，你把你更新的那一个放到网上，把另一个拿下来。我们就是这么做的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1859799|如果你有任何类型的“beta”版本，不要把它放在实时服务器上，如果你有一个“实时、繁忙的站点”，人们很可能会在它上面砸坏一些东西。|1859800|这是一个典型的高可用性设置，为了维护高可用性，您至少需要3台服务器。2个活动服务器和1个测试服务器。如果你想要一个专用的数据库或者别的什么，再加上任何额外的服务器。|1859801|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

The only way to make it transparent to your users is to put it behind a load balanced proxy. You take one server down while you update another server. Then when you done updating you put the one you updated online and take the other one down. That's how we do it.

If you have any sort of 'beta" build, don't roll it out on the live server. If you have a 'live, busy site' chances are people are going to pound on it and break something. 

This is a typical high availbility setup, to maintain high availability you'll need 3 servers minimum. 2 live ones and 1 testing server. Plus any oter extra servers if you want to have a dedicated DB or something.

blocks|key|1859928|text|创建一个主机类，并在该主机类上部署您的活动站点。所谓主机类，我指的是一组主机，其中设置了负载平衡，并且很容易在类中添加和删除主机。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1859929|当你完成beta测试并准备好投入生产时，不需要关闭你的网站，只需从生产主机类中删除一些主机，将它们添加到新的主机类中，并在那里部署最新的代码并进行适当的测试。一旦您确定一切工作正常，请逐渐将所有主机移至新主机，并将新主机类作为生产主机类。或者，您可以使用最初使用的相同内容，此活动背后的整个想法是确保您在生产机器上测试您的部署，在部署之后，您的站点将在那里运行，因为部署问题非常可怕，很难调试。|1859930|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Create a host class and deploy your live site on that host class. By host class I mean a set of hosts where load balancing is setup and its easy to add and remove hosts from the class.

When you are done with the beta testing and ready for production, no need to take your site down, just remove some host from production host class, add them in new host class and deploy your latest code there and test properly. Once you are sure that everything is working fine move all your host gradually to the new one and point new host class as production host class. Or you can use the same you were using initially, whole idea behind this activity is to make sure that your are testing your deployment on the production boxes, where your site will be running after deployment, because deploy issues are scary and hard to debug.

When you roll out changes to a live web site, how do you go about checking that the live system is working correctly? Which tools do you use? Who does it? Do you block access to the site for the testing period? What amount of downtime is acceptable?

How do you update a live, busy web site in the politest way possible?

负载均衡

测试服务

数据库

服务器

当您对一个实时网站进行更改时，您如何检查实时系统是否正常工作？你使用哪些工具？是谁做的？在测试期间，您是否阻止访问网站？停机时间是多少是可以接受的？

问如何以最礼貌的方式更新一个活跃的、繁忙的网站？
EN

回答 10

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何以最礼貌的方式更新一个活跃的、繁忙的网站？EN

回答 10

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何以最礼貌的方式更新一个活跃的、繁忙的网站？
EN