The Plan for Evaluating a New Release

SQL Server 2008 R2 is now out, and you can get the “Customer Technical Preview” or CTP here:

But it seems like SQL Server 2008 just came out! I’m still installing and upgrading it on the systems I manage. I tend not to focus too much on a new release, but it’s foolish, I think, to ignore them until they are out. The organizations I serve depend on me to be aware of the technology in my field, and how it can (or can’t) help them do their jobs. That’s what I do.

So I need to keep up with the newer releases, even if I don’t spend the majority of my time on them. To do that, I need to organize that effort so that I am efficient with my time. I thought I would share the way I evaluate a new release with you, and perhaps you can leverage the information in your own environment.

1. Set up a Virtual Machine with a clean OS, and all security software. I use the MSDN version of Windows Server, at the most common version of my organization, install my anti-virus and all patches, and then save that off to a USB drive. When I’m ready to do my evaluation, I copy it down, fire it up, and install the latest patches. Now I’m ready to run the install – and I always install. I never test an upgrade until I’m all done with the CTP process, since Microsoft doesn’t always guarentee that an upgrade from a CTP will work, so I start with a fresh machine for each CTP. THat’s why I use VM’s for this.

2. Read up on the changes. There are three parts to a new release: some things are deprecated (removed), some things are altered (enhanced or changed), and other things are brand new. I do a web search on the release, normally hitting the MVP sites and Microsoft, as well as SQL Server Central, SSWUG, TechNet, SQL Server Magazines and more. I read the release notes, and then I look at the “What’s new” section of Books Online for the new things: I look for anything that is deprecated that I’m using, and start the plan for migrating that technology. It’s probably the most important thing I check. Next I check to see if something is enhanced, which might save me from buying a third party application to deal with any issues I’ve had. Then I look at the new features and match that up with what I know about the business in my organization. Here’s the latest link I’m using for R2:

3. Install and configure the new software. I document any “gotcha’s” during the process, but I don’t don’t panic on these too much. Things change with each CTP. I also test an unattended install.

4. Install a workload. I restore a production database, run an app, run my test scripts, and take a look at any processes I currently use with the new release.

5. Provide feedback. I make sure that I keep my other DBA’s in the loop, as well as the rest of the IT team. I also discuss with the business about any changes to licensing and so on that have been announced. I also close the loop with the Microsoft product team using, to let them know if I ran into any issues with the CTP. After all, that’s why they have the program to begin with, so that they don’t release something I can’t use.


Comments (2)

  1. SamSQLz28 says:

    Hi Buck,

    I wondered what directory/folder, that after you completed a Build, you copied/saved to a USB drive? a whole C: drive or C:program files and C:Windows?…



  2. BuckWoody says:

    I want a "fresh" VM for next time. I then install SQL Server or whatever else, play with it, and when I’m done I can just copy the "OS Only" VM over the top of it and start clean. In Hyper-V, You can just use a snapshot, but VPC doesn’t have that feature.