我们的.net应用程序结构就完全不同了（见图3）。我们在同一个网络底层框架上添加了.net服务器，因此就没有额外的成本了（除了网络连接外）。.net应用程序结构也具有我们的三阶段ad实施方案和共有的数据库后端，但是两者的共同之处也就只有这些了。因为我们可以在提供应用程序的性能的同时，降低其复杂性，我们的.net应用程序结构就只有五种不同类型的服务器——是dna结构的一半。例如，我们不再需要把设计用于数据存取的组件实施到一个共享的中间层dat服务器了。ado.net性能的提高及其对sql server的本地支持使我们可以在web服务器上实施这些数据存取组件，同时，提高了数据存取的性能，降低了我们sql servers上的负载。
由于引进了我们的.net应用程序结构的概念，我们就可以在每个阶段为每种类型的服务器提供至少一个服务器，这同我们的dna环境是不同的，在dna环境中，开发和staging中有共同的任务。开发中的任何变化几乎可以正确地反映在生产中将会出现什么样的变化。运用这种应用程序结构，我们在实验中可以有很强的灵活性，在我们将这些变化实现在我们重要的应用程序中前，我们可以评估它们可能带来的影响。这种新的结构也可以帮助我们更好地定义在我们的变化管理过程中，每个阶段所起的作用。
请传递任务

图3. .net的优势

除了简化我们的服务器结构外，asp.net和.net framework可以使我们改进我们的变化管理过程。在dna实施过程模式中，开发人员主要运用开发环境来创建他们的应用程序。因为dna应用程序固有的复杂性，开发人员需要这个环境用来单元测试程序的变化。而且，因为在开发阶段，我们的visual studio 6.0自动将迭代的变化实施到web 服务器了，所以，随着不同应用程序的开发，这些服务器的内容经常发生改变。
为了使生产环境保持一致，我们将应用程序的变化转移到staging阶段，通过详细设计应该去掉哪个文件，对商业功能进行测试。将代码转移到staging阶段会在我们的测试过程中产生一个重大的问题：当在staging阶段中发现bugs时，我们不知道它们是在代码中形成的，还是由于实施过程中的错误而产生的。staging环境在实施过程中有两个截然不同的作用：我们可以在这个环境中测试一个应用程序的商业功能；我们也可以在这个环境中测试实施过程。
我们有一个实施小组，与开发人员不同，他们构成了web站点管理员，他们将变化公布到staging和生产阶段。在staging阶段进行联合测试会给实施小组带来一些压力，因为他们经常需要解决一些与发布应用程序无关的bugs。例如，如果web页面上的一个按钮不能正常工作，开发小组和实施小组就需要共同来确定这个bug是由开发人员的错误导致的，还是由实施小组导致的。另外，在staging阶段发现的任何bug都会导致额外的实施过程，因为一些asp页面或com组件总是需要修改，然后重新实施到staging阶段进行重新测试。
在构建.net环境时，我们想分离staging阶段在我们的dna实施过程中所起的实施作用。最初，我们想我们应该需要称为测试的第四个阶段。然而，在我们了解了应用程序在.net中是如何工作的以后，我们意识到这个阶段是完全不必要的。现在，我们用开发环境来测试商业功能。在把程序转移到staging 前，开发人员和质量保证人员（qa）要先证明代码中没有bugs。这一步骤就减少了staging中发布版本的数量，而且提高了解决bugs的速度。
产品发布过程中的这种变化是可能的，因为我们已经不用com+了，而且去掉了中间层数据存取。现在，开发人员可以进行99%的单元测试了，过去，他们是在本地机器上的开发阶段进行单元测试的。由于xcopy实施方法和.net的更简单的应用程序结构，我们在开发人员的机器上就更容易模拟asp.net和基于.net framework的应用程序。例如，我们的.net应用程序运用多个xml web serivices，它们存在于我们的dna环境中，有许多实施步骤。为了在开发人员的机器上实施.net xml web services，你把xml web service文件拷贝到你的internet information services (iis) web目录中，点击iis管理控制台中的一个按钮，复制你的本地应用程序到那些服务，这就行了。
当需要从开发人员的机器实施一个web应用程序时，他或她运用visual studio .net（vs.net)内置的项目拷贝功能。这个功能只将必要的文件拷贝到目标网站，留下应用程序的源代码。这就创建了一个可重复的版本导向的过程，用来将变化发布到一个环境，传统意义上，这个环境不是用于测试目的的。现在，因为vs.net管理了我们实施过程的开端，我们就确信它会是一致的。当我们进行了项目拷贝后，开发环境就准备用于qa了。
我们用application center 2000来公布qa认可的从开发到staging的变化。以前，在转移到staging 前，实施小组必须手工重建应用程序。对于dna应用程序来说，这么做很麻烦。例如，在我们公司，我们有许多vb com组件，每个组件在它们自己的dll文件中。我们主要的dna订单应用程序在36个dll文件中有45个独特的com对象。一些对象存在于com+应用程序中，一些必须作为传统的com对象注册。所有这些com+应用程序和com对象必须正确配置以使我们的应用程序运转。运用这个程序的.net版本，我们只需要将包含应用程序代码、asp.net文件和我们单一的c#类库的目录从一个服务器拷贝到另一个服务器——如果的确有xcopy实施方法，这个例子正好可以加以证明。因此，根据这种改进的软件实施方法所带来的成本上的节约，我们就可以认为，我们将com+组件移植到c#所做的任何努力都是值得的。如果我们要用com+组件，那么实施过程就不会这么简单了。当你决定在.net世界中重用com+时，你应该考虑到这一点。
一旦应用程序在staging阶段中了，qa再次进行基本的系统测试，但是，这一次他们所发现的任何错误都与实施过程有关。这种情况很少发生，因为.net应用程序的实施很简单（除了关于数据库的变化外）。现在，实施中的大多数问题都与将数据库的变化从一个阶段转移到另一个阶段有关。如果sql server下一个版本同.net一样也支持xcopy实施方法就好了。
在我们的dna环境中，当我们从staging转移到生产阶段时，多数情况下，这是我们第一次这么做。因为我们必须在staging 阶段手工重建我们的应用程序，我们不能在生产环境中测试我们的实施过程，直到我们准备好了现场进行测试。运用.net实施过程，当应用程序在staging阶段进行测试时，我们就可以确信它已准备好投入生产了。在开发阶段，我们已经发现并解决了所有商业功能方面的bugs，而且在staging阶段，我们也已经解决了与实施有关的问题。将其投入到生产通常不会带来什么问题，因为我们已经在前两个阶段进行了实施演练。这就有助于我们在软件实施中实现零停机。
关于作者:
barry bloom是mary kay inc.公司的电子商务和技术工程部的主架构师。他负责mary kay网站的结构，该网站帮助700,000妇女经营她们的mary kay业务。在过去的三年中，他的网站使75%的订单都是通过internet完成的，这占了10亿多零售额。barry也是deploying and managing microsoft .net web farms (sams, 2001)一书的作者。他的e-mail是barrydbloom@hotmail.com。