The Wheel of Time

13 Books

11000+ pages

3,5 months

I’ve had things to keep me occupied.

Environments

Now that you have decided that SharePoint is the solution to all your troubles, you have to get some hardware to build your magnificent system on. The number of environments will not surprise anyone with a certain level of software development experience, but the number of machines needed may surprise you. With each machine, the amount of storage needed also increases, so be prepared.

Development

SharePoint developers perform the following ritual a significant number of times during a day.

1. Compile code
2. Retract old code
3. Recycle the web server process
4. Deploy new code
5. Test our your change.

Between step 2 and 4 the system is unavailable. Steps 1 to 4 are done automatically by VS2010.

Each developer needs their own machine, trying to share one between several developers will not be practical. Since the web server process gets recycled all the time, it can take a considerable amount of time to load all your code so that you can test your changes. Once I was able to start a page refresh, go for a slash, and still have time to get comfortable before the page had loaded. It might be worth investing in some fast disk drives….

A developer machine should contain the following:

• SharePoint configured in farm mode, not single server
• SQL Server
• Active Directory domain

Since developers need to be the masters of their universe, putting all this into an isolated virtual machine is a practical approach. The active directory requirement becomes more important with the number of developers you have. With isolated domains, all the machines can have the same name and belong to the same domain. This ensures a common deployment experience for all developers; no need to create additional configuration files when adding more developers(machines)

As for hardware, I’ve tried various approaches. My favorite is actually my 8GB laptop. This I can take with me and work on wherever I may be. I have also tried the approach of logging into a virtual development server. In the environment I was using, I didn’t feel like it was much faster than my laptop. This was also because the virtual hosting environment was hosting all sorts of other things; it was overloaded to say the least. If you manage to have a dedicated hosting environment, it may work out really well. But for now my laptop rules.

Testing

The testing environment is the first environment where we are starting to resemble the actual physical architecture. The test environment should be deployed across multiple machines; 1 SQL server,1  application server, 2 web front end server.

Since this is the first place where we are using multiple machines, problems not discovered on the developer machines will surface. It’s important that the developers have full access to the environment so they can troubleshoot.

If you manage to get your code working after it has moved between environments, things are looking up. At least you then know that nobody has hard coded the developer URL’s. This may sound stupid, but I have seen it happen. ‘Works on machine’ takes on a whole new meaning.

Staging

This is the environment where final testing and approval takes place before deploying the code to production. In this environment developers should have very limited control. The people maintaining the production environment should be the ones in charge of this environment. The test environment was the playground for the developers, the staging environment is the playground for the operational staff. Service pack and patch management testing can be performed in this environment.

In an ideal world the staging environment should be a copy of production. How that looks will depend heavily on what parts of SharePoint you are using. Since we don’t live in a perfect world, it’s not going to happen very often. Reducing the amount of allocated storage is an easy way to reduce cost; you need to be able to store a certain amount of data for testing purposes, but probably not the entire production system. The servers will most likely be virtualized, so you can turn them off when they are not in use.

Production

This is just included for completness; shouldn’t require much explanation.

Multiple release development

Now that you have established the environments for your current release, time to think about the next version. Developing and testing a new release takes time, and during that time, issues may arise in your production environment. In order to perform bug-fixing in production, you shouldn’t use the test and staging environment for developing the next release. Separate environments should be established.

If you are a gambling man, you can hope nothing happens to your current production environment as long as development takes place on your next version.

What’s the story, morning glory?

Life would be grand if every SharePoint morning was glorious, but there is no such luck. To a very select few in this world, SharePoint may be as clear as crystal. To the majority however, it’s about as clear as mud. If you belong to the latter, you might find this blog helpful. I by no means count myself amongst the former, but a couple of years ago I decided to take a mud bath.  3 years later one would have hoped it would have had a soothing and relaxing effect, but it’s turned out more as mud wrestling.

So come along, click your heals, bring along the scarecrow and tin man and let’s all jump down the rabbit hole.