Community

• Blogs
  • Expert Blogs
  • Community Blogs
  • Create a Blog Entry
• Discussions
  • Start a Discussion
• Job Center
• Chapters

Minimum Code Required

• 
• 
• 
• 

If you read my introduction, you won’t be surprised to know that one of my favorite TV shows is Holmes on Homes. Holmes on Homes is an HGTV production where Mike Holmes goes in and repairs construction jobs that have gone south. A lot of times he finds substandard work, work that does not meet the minimum code requirements i.e. Uniform Building Code. Well, if there was a uniform building code for SharePoint farms, it would include a few things that some people tell me they don’t have. One of those things is a Test Server.

I used to think that I didn’t need a test server. I thought I could get by with building test sites under my department’s site, or, if I really wanted to get serious, I could create a separate content database for testing. I was wrong. One day, I made some changes to the configuration of a third-party web part I was testing. The changes were accepted, but they didn’t seem to work; I made a note and planned to return later. Unfortunately, when I returned the page failed to load. A few well crafted URLs later and I had deleted the offending web part and my department site returned to action. That’s when I realized we needed a test server.

If you are using SharePoint for ECM, the above example isn’t even the worst case scenario. You may be imagining disasters resulting in lost documents, but I am thinking about something a bit more subtle. Consider a workflow, developed without proper testing, that is occasionally causing a simple mistake; say the wrong value being set in a column. When you discover that error, you will fix the workflow and then go back and edit the incorrect entries. Whoever does the editing is now associated with the document. That association may have to be explained at some point, perhaps in conjunction with a discovery order.

A test server need not be an expensive undertaking. Your test server can be virtualized, or like our test server, it can run on a fairly inexpensive workstation. The point is, we have a server where we can try out trial copies of web parts, and applications. Also, I have a content database on the test server where I can develop and test workflows and code that I develop. My Systems Administrator loves our test server. By using our test server, he has perfected his ability restore and upgrade SharePoint – there’s nothing like destroying a server and recreating it to make you feel good about your backup strategy.

Testing the technology we rely on to keep our business data, store our business documents and exchange information with our customers, should be standard procedure. Testing should also be a first class operation; it should be able to be conducted without limitation, for the appropriate length of time and without risk to production documents. The minimum requirement for testing would include a separate test server.

Comments

Submitted by Chris Riley, ECMp, IOAp September 07, 2010 - 10:36 AM

Daniel,

Great post. Your point about testing is absolutely critical. Both in new farms, and upgrades. Part of the problem we have seen that has been causing a lot of push back from testing, is the amount of effort not necessarily cost. Because the standard SharePoint configuration wizard does not usually give companies the flexibility and scalability. The admins are forced to use STSADM commands or hopefully now with 2010, PowerShell scripts to setup a farm. However, the effort in creating the scripts is not trivial, and where the effort complaint often comes.

I don't usually talk shop on blog posts but the tool we created to solve this problem is really cool. What we have been doing is automating our scripts with a tool we built called Composer ( www.sharepointcomposer.com ). Basically, we create an XML file that represents the configuration of our test environment. Because it's simply a file, we can easily re-deploy it using Composer + Maestro to build our farms. This then dramatically reduces the effort and gives the admin the flexibility and scalability the lacked in the past. What is also very nice is that the design of the farm is visual. Using MindManager as the canvas you can design your farm, setup users, add application pools, start services, etc.. By the time your done with the deployment not only was the testing optimized, but you also have documentation, and a change management tool.

You are dead on. Lack of testing, and planning are the two weakest points of SharePoint deployments not only from an architecture point of view but also use case. And when organizations let SharePoint run wild the resulting disaster is discouraging them from utilizing a great platform.

Report

Was this helpful? Yes No

Reply

Subject  

Comment  

Submitted by Daniel Antion September 07, 2010 - 7:34 PM

Chris,

Coming from a background in systems development, it is interesting to see tools starting to emerge for building and testing SharePoint. The demand alone for such tools tells me that SharePoint is starting to be taken seriously. Of course, most people point to the rapid grown in the market as evidence that SharePoint is being taken seriously, but I would disagree; SharePoint is still somewhat in a Wild West mode, IMO.

We are small enough to build, destroy and rebuild pretty quickly, but we have invested in some tools for documentation. Being able to rebuild quickly is only useful if you know what you’re rebuilding.

I appreciate your comments and hope you keep reading.
Dan

Report

Was this helpful? Yes No

Reply

Subject  

Comment  

This post and comment(s) reflect the personal perspectives of community members, and not necessarily those of their employers or of AIIM International