Testing .NET updates across the enterprise?

A question today for the bloggers (and readers) out there.

With a size of the organization I work for (7000+ desktops, 120+ servers) it's hard to do a lot of acceptance testing when something like say a .NET patch/upgrade comes out. With hundreds of web apps out there, there's no telling what will break and what won't and frankly, individual testing on each app is just unobtainable given time and budget constraints the business usually is under.

So the question is, when something like an update comes out how do you test across the entire enterprise to an acceptable level of comfort? Imagine the scenario if/when the .NET framework is updated from 1.1 to 1.2 (or even the large switch we'll have to make to 2.0). You have hundreds of web apps written in .NET out there. Presentation, business, and data tiers all depending on the framework. It's impossible to run through a manual testing effort on each app. In a perfect world, every app would have a good set of Unit tests which you could run.

However the testing effort is really around making sure the framework doesn't break something in the environment, but how do you test for something like this? How do you be proactive rather than reactive? How do you mitigate risks with such an update and make the environment management people happy with the change? Thoughts, ideas, comments?

2 Comments

  • I hope that one of .NET advantages is that differnt framework version can coexist and you don't have to worry about framework version upgrades :) The problem is when you deploy app to the environment having just one version of framework, but it's the other question.

  • I'm coming from organization more or less in the same size that you describe. Here what we are doing when we upgrade .Net framework.



    First of all our staging servers are composed from integration, test and production server. The first step it to call each team that responsible for certain system and to run unit test for given system on the integration server. This stage usually tracks most of the technical issues. Next step is to call each team and ask them to activate their system on the integration server. This stage is usually tracks any flaws regarding integration problems between systems.

    Last step is to deploy changes into test servers and ask our testing team to operate all the systems (on the test server). if all the systems running well on the test server, we install the new CLR version together with systems update to production server.



    Those steps works great and we hardly ever got any problems in our production servers due to changes in Microsoft framework, our frameworks or in systems.



    HTH

Comments have been disabled for this content.