INTRODUCTION
I just want to share with you my experience in managing Sharepoint environments (both server and custom code). Before, I came from a development background and purely think as a developer. As a developer, I used to think that as long as my code is bug-free and memory-leak-free then I'm safe.
Now, I've got some experience in managing the servers, I can share with you the things that we have to be aware of more than just having a bug-free and memory-leak-free code. This article will (as usual) come in series so if you're interested, please stay tuned and read the series. I also would also like to see comments and sharings from you so that we can all learn from each other.
MANAGING RISKS 1: KEEP YOUR ENVIRONMENTS ALIGNED
The Sharepoint environment I'm currently working on has the following server topology:
- 1 DB
- 2 WFE
- 1 Central Admin
- 1 Indexing Server
The same topology was also created for Test (yes, it's EXTREMELY important to have a Test environment for Sharepoint just like general .NET development). The goal is whenever we deploy things (code, solutions, features, etc) to Test, we would expect the same results in Production (ie. if it fails in Test then it will fail in Prod and vice-versa).
The idea is great but the problem is, this client's Test and Production weren't installed by the same person. One person setup the Prod and another person setup Test. Hence, we now have different settings and configurations in both Test and Prod.
This will create a huge risk, because if we deploy things in Test, we can never guarantee that the same would succeed in Production even if they successfully pass testings in Test.
Therefore, the very-very first step I would do is to ensure that both Test and Production are aligned. These are (and not limited to):
- The server topology
- The user accounts used to run MOSS/Sharepoint services (Search, SSP, etc etc)
- The configurations (SSP config, Central Admin config, email settings, etc)
- The solutions installed
- The features activated
- The code and DLL deployed (even third party DLLs such as stsadm extensions, etc)
- Web.config settings
- IIS settings
- SQL server settings
- AD settings for each user account used in Test and Prod
- The resource settings for both Prod and Test (RAM, Hard Disks, Processor Utilization, etc)
By ensuring that the settings above are the same for both Test and Prod, we can now expect that the deployment results will be exactly the same. If your deployment breaks in Test then it will most likely break in Production.
TAKE IT FURTHER
I would actually like to take this further. Even the developers' machine - although it's impossible to create the topology within each developer's machine - is at least installed using Test/Prod user accounts and configured using exactly the same configuration. This has worked really-really well for me. I can now be very confident that whatever fails on my machine will also fail in Test and Prod and vice versa (whatever succeeds on my machine will also succeed in Test and Prod).
DOCUMENTATION
This is the bit that I HATE! :) As a developer, there is nothing worse than writing a documentation. Anyway, it's EXTREMELY important to document the setup process for both Test and Prod. Take screenshots as you go through each step and document them. You can use MS Word to Copy Paste things easily or even OneNote with its screen clipping feature. It's really-really handy. Just like taking your wedding photographs for memory, that's how valuable documentation is for us.
From my experience, I will forget within one day what steps I took to setup MOSS. So guys...get your documentation tight.
STILL THERE IS ONE RISK LEFT
The CONTENT DATABASE is the major risk. You would never be able to always align content database. You will be surprised how quickly the content in your machine and in Test are outdated. People will upload more and more documents in Prod and even worse, some of the users are stupid enough to create content types and meta-data directly in Prod!
I'll discuss about this more later.
Hope this helps and please stay tuned for next series,
Tommy