1. 测试
通常情况下，你不会在生产环境，尤其是生产数据库中进行测试，原因如下：
性能：测试可能会占用大量CPU资源和服务器的其他宝贵资源。由于你不希望在测试期间降低生产环境的性能，所以不能使用生产环境进行测试。
数据保护：你不想在测试期间更改生产数据库中的数据。这意味着不仅你的测试范围可能受到限制（即你可能会三思而后行地测试可能破坏实际用户相关数据的某些错误，使该错误稍后被黑客利用），而且你可能会意外更改数据通过在生产数据库上运行未经测试的代码。
安全性：如果你在公司中并有一个团队，则可能将与测试相关的工作分配给专门的测试人员。出于安全原因，让此测试人员访问生产环境不是一个好主意。
1.1 测试环境
测试环境必须尽可能与生产环境相似。例如，如果你为Windows XP提供了使用.NET Framework 3.5的应用程序，则不应该在Windows 7上使用.NET Framework 4进行测试，因为这样会导致测试时一切正常，而当你的客户开始使用该应用程序时失败。
例如：曾经我在一个使用NTFS备用数据流的应用程序上工作。在开发和测试期间，一切都完美无缺，没人想到在2009年，FAT32仍然存在。当然，一旦在生产中，客户将应用程序安装在格式化为FAT32的闪存驱动器上，它就崩溃了。
请注意，这并不意味着你应该在开发过程中使用相同的环境。
在数据库的情况下，情况有所不同。数据库引擎和版本必须相同，并且模式（相同的表，相同的约束等）必须相同，但大多数情况下数据应该不同，测试数据库填充了一些随机的数据，与你在生产中拥有的数据无关。
1.2 数据库：测试瓶颈
例如，如果一个网站最近发布，你没有大量数据。如果数据库包含注册用户列表，则一开始只有很少的用户。另一方面，你可能不仅需要测试你的应用程序是否正常工作，还需要测试性能是否正确以及瓶颈在哪里。在这种情况下，你将需要使用大量的数据进行测试：这样，你可以在生产环境中拥有数千个用户，在测试环境中拥有数十亿个随机生成的用户帐户。
1.3 数据库：测试输出的正确性
当您希望测试数据与生产数据不同以避免HTML注入并验证输出是否正确时，另一种情况是。如果您拥有一个电子商务网站，您会有一个SQL表Products，每个产品都有一个标题将显示在网站上。在测试环境中，您应该有像以下这样的产品名称：
1. A very long name of a product goes here. Oh, this name is really huge!
2. javascript:alert('<a>&\é<%щ你好')
3.
4. '; delete * from Users
这些名称将确保：
- 长名称正确显示，
- 名称被正确转义，支持Unicode并且编码正确，
- 空名称不会破坏布局，
- 避免SQL注入但在输出时不进行转义（如果可以通过网站更改标题）。
如果您开始用这种方式填充生产数据库，则您的用户可能会认为您的网站已经损坏或被黑客攻击了。
2. 部署
一切都取决于每秒实际请求的数量。
2.1 小型网站
如果您的网站很小并且不经常使用，则您真的不需要关心更新工作流程。复制更改的源文件可能少于一秒钟，因为这些文件很小。如果这真的让您困扰，您可以在访问者较少的时间安排文件复制。对于大多数小型网站，
在半夜更新源代码应该没问题。
此外，在显示消息时没有任何问题，即在凌晨4点至5点之间服务器可能会离线。有时在夜间工作，我经常在我的银行网站上看到这些消息，他们可能需要出于安全原因在维护或其他计划任务期间完全离线一次每周。
2.2 服务器群
如果您的网站很大并且每秒有数千个请求，则可能拥有服务器群。在这种情况下，更新过程不应该是一个问题，因为
服务器将一个接一个地离线，更新自己，然后返回到群中。
