The Wheel of Time
August 4, 2011 Leave a comment
13 Books
11000+ pages
3,5 months
I’ve had things to keep me occupied.
SharePoint; putting the mystery back into computing
August 4, 2011 Leave a comment
13 Books
11000+ pages
3,5 months
I’ve had things to keep me occupied.
January 11, 2011 Leave a comment
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.
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:
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.
January 10, 2011 Leave a comment
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.