Weekend Scripter: Building Test Servers
Summary: Ed Wilson, Microsoft Scripting Guy, talks about building test servers. Microsoft Scripting Guy, Ed Wilson, is here. This morning I am listening to my favorite Swiss classical radio station on my computer, and I am sipping a cup of herb tea. I have a nice strawberry scone that I picked up in town at a local bakery. I am reminded of a conversation I had with a friend of mine who was a TAM in Zurich. We were talking about testing changes prior to implementation. In the old days, having a test network meant building racks of servers, restoring tapes, and trying to keep track configurations in sync with production machines. In fact, some customers still maintain this approach. The trick is that the test network and the production network need to mirror one another as much as possible. Depending on what change might be made, the level of duplication may become crucial. For example, if one is testing router configuration changes, it is important that the test network mirror the production network in at least a similar fashion so as to not destroy routes to distant networks. If you are testing software updates, it stands to reason that the test network should have the same versions of the production software installed. Once when I was in consulting, I remember that a network administrator tested a software update on his test network. He then tested various applications, and everything worked properly. He then configured his deployment package and deployed the software update to his network. Suddenly, the Help Desk phones began ringing off of the hook. He had overlooked a particular database application that was installed on approximately 5 percent of his networked computers. Unfortunately, that five percent of the workstations was also 100 percent of the customer service workstations. He basically had shut down his company. His boss took little solace in the fact that his testing procedure had covered 95 percent of the use case scenarios. One of the cool things to do with Windows PowerShell (and especially with Desired State Configuration (DSC) and Windows PowerShell) is to duplicate environments. If I use a particular Windows PowerShell DSC script, and it configures a particular server, I can easily use it to play against another server, and I now have two servers that are identical (as far as my script goes). With Windows PowerShell and the various DSC resource kits available, my script can go pretty far in configuring lots of stuff. Indeed, various third-party vendors are also creating DSC resources to enable manageing the configuration of their various products. So, when you think of automating deployment via a nice DSC script, don’t forget that you can also use it to configure a duplicate test environment. And if your production already takes advantage of virtualization, your test environment can be as exact as you want it to be. This week, I will be talking about using Windows PowerShell and DSC. Remember, with Windows PowerShell, it is “write once and deploy many many times.” WooHoo! Windows PowerShell for the win! I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy
Light
Dark
0 comments