SharePoint 2010 team development environment
SharePoint 2010 release date is closing (H1/2010) and there is huge interest on the product capabilities. There’s already few ongoing projects, which are scheduled to be released on H2/2010 and using currently beta 2 version for development.
One of the key questions currently asked, is the setup for team based development. This blog entry defines few alternatives and some recommendations based on personal experiences.
So how do you actually setup large development teams in efficient way, so that the investments done for the development environment are reasonable? As it has been documented, the hardware requirements will increase compared to 2007 at least in some level. Personally I’m mobile person, so I’m using my laptop with 8Gb and dedicate 5.5GB for the development VM. For storage of the VMs, I use secondary SSD hardware (speed is brilliant), but when we are setting up team based development, this is not the only option.
What about when you actually setup development environments for example for 40 developers?. We do have few options…
- Running SharePoint from developer’s laptop or desktop – few options here
- Running development environments from virtualized hosts
Let’s go the options one-by-one.
Client side setup to client OS
Basically each developer is having their own SP environment as client side OS install. VM is connected to corporate network to have access to centralized source control system. VM installation can be scripted to have new environment ready to be used within less than one hour. For setting up these, you can use either dedicated AD with network access to corporate net or use corporate network accounts for VM. Details on the setup obviously this depends on corporation policy.
Advantages
- Flexible development without necessarily constant requirement to access the corporate network
- Easy access of development, no delays concerning VM booting up etc.
Disadvantages
- If developer is involved in multiple projects, possibility to accidently create dependencies between them
- No project based software setup - for example office client version
- Requires heavy hardware for each developer’s computer - 8Gb memory and secondary fast hard drive (at least 7200RPM) would be good for productivity
- Cannot be centrally managed
- Synchronization and patching of the environments can be difficult
- High hardware requirements for each lap top or desktop – hardware is not efficiently utilized during vacations, sick leaves etc. – “hardware utilization shortage”
Client side setup using virtualization
Similar mode as above, but using virtualization software.
Advantages
- Flexible development without necessarily constant requirement to access the corporate network
- Virtualization provides snap-shot support
- Each developer can dedicate one VM per project – each project can create the base setup (SPF or SPS) + browser support + client versions (office 2003/2007/2010) etc.
Disadvantages
- Requires heavy hardware for each developer’s computer - 8Gb memory and secondary fast hard drive (at least 7200RPM) would be good for productivity
- Cannot be centrally managed
- High hardware requirements for each lap top – hardware is not efficiently utilized during vacations, sick leaves etc. – “hardware utilization shortage”
Virtualized host setup
Let’s setup multiple centralized VM hosts, which can be even dedicated to single projects. This way we can have even tens of VMs on one of the environments, since if we only keep active those VMs, which are actually used, we can free flexibly resources. In our projects (MCS Finland), we’ve been successfully utilized this model already in 2007 development – and of course for 2010 development as well. VM hosts have to have more expensive hardware, but it’s still much more cost efficient, compared to investments for each developers.
Whenever projects are switched to maintenance mode, we can degree the amount of hardware used for single project – which will adjust the developers work as well. In our case, we have two primary development servers, where on both we have around 25 VMs, from which approximately 5-6 are running at the same time. This model has been extremely suitable for up to 10 persons with developers roles in 5-7 different projects.
How many developers can utilize on VM host? – depends on the hardware and virtualization engine, but 5-6 is easily doable even with relatively simple setup. Biggest bottle neck will be file IO – so disks will determine how many developer VMs you can actually have in single VM host. Obviously memory required in the host servers is also one of the key considerations.
In this case, heavy hardware is required, but you can also manage and phase your investments based on the projects for SharePoint 2010. Whenever new 300-500 man day project starts, buying 4500$ hardware for it, is not a big deal… depending of course on your profit model – after the project, server can be utilized also by others. “Hi manager, so to be able to do this 300.000$ project, we need to have initial investment of 4500$ - ok?” – “Definitely, since we want the do the project .”
Advantages
- Centrally managed environments
- No high hardware requirements for developers own machines - used only for office content etc.
- Efficient utilization of the hardware based on project demand – easy scale up and out
- Easy setup for more larger farm setups for testing purposes
Disadvantages
- Requires additional resources or roles to manage the centralized virtualization server – just to ensure that it’s online and available all the time
- Possible single point of failure – depends on virtualization model and software used
Additional considerations
For overall costs, we also need to include the dev integration server and possibly also the setup used by test team. If we are using centralized model, with VM host, we can start and stops these environments as well easily.
Dispute the fact that if the development would happen on individual laptops or desktops, we need to have at least few VM’s running to imitate the production deployment. So virtualization has be nevertheless done. Obviously everything depends on project size and requirements, but for enterprise projects, we need include the environment requirements and setup for the plans concerning the overall project / portal life cycle planning. This planning has not changed that much from 2007, expect the new possibilities to manage and update already deployed functionalities in production environment.
Summary
Centralized virtualization model is definitely the most cost efficient options. This way the developers should be able to utilize their current lap tops for client side tasks (outlook, power points, docs), but actual work is done on the virtualized hosts. Servers can be easily used also to host other requirements, like if there’s projects where we need to integrate OCS and Exchange, we can add those as additional server to virtualization rack and they are good to go – we can relatively easily created internal networks and farm based installations for testing purposes.
Key cost savings with the centralized model are also dependent on the fact that the hardware is efficiently utilized – if some of the developers are on vacation, those VM’s can be stopped and resources can be allocated to other projects. This provides lot of flexibility and cost efficient way to utilize the investments done.