Partager via

Experiences on using a single farm for developers (WCM)

  • Article

Scenario:

  • 5-8 developers
  • WCM portal with lots of sites (SPWeb) and pages, but not a large database
  • Development is focused on Fields, Content Types, Layouts, Web Parts, Controls, HttpModules

Typical environments:

The general recommendation is for developers to have their own virtual machine (or physical machine) that contains a complete SharePoint installation.  There’s a variant where the SQL Server is shared but it will still be several SharePoint farms with a single server in each.

The problem with these is that you end up with multiple farms to manage.  This can work good for the first deployment but will be difficult for incremental releases.  It can also be good for developers working for different production environments. 

However, when developers are working for a single production environment, other requirements will come in:

  • Download content artefacts from Production to Development (especially for WCM or light collaboration scenarios)
  • Update all developer environments with new artefacts
  • Update all developer environments with new or updated layouts & styles
  • Update all environments with a new CU or service pack

Developers already had those requirements without impacting anyone else:

  • Update file system files in the web folder (web.config, browser file, etc.)
  • Execute an IISRESET
  • Update assemblies

 

What impact would a single farm have for development?

After living with multiple farms using shared resources, I implemented a single farm at a customer.  While there are identifiable caveats, it also bring a lot of value while diminishing overall time spent on maintenance and on bug due to non-synchronized environments.

 

For WCM, you will have 2 types of development : 1) content related and 2) pure development artefact.  The first is easy to handle, your web designer can simply work like before and it will generally not impact anyone else, in fact, it’s beneficial since page layouts will be updated for everyone at the same time.

The only drawback is that I’ve often seen web designers doing check-ins or publishing layouts to test them.  This isn’t optimal for anyone as it uses more resources on SharePoint and if the layout has a display issue, everyone will have it.  Therefore, some assistance (how-to’s) should be planned to ensure that web designers are working optimal for everyone.

 

For Development artefact, it can be a little bit more complicated depending on what type of artefact.  For example, if you are developing a custom SharePoint Field, results will be inconsistent if you add a new field instance to a content type that is used for everyone.  In the same fashion as the previous case, working on a separate site collection (or at least content type) might be a more manageable solution for the few times when you are developing those artefacts.

In fact, for most cases, it’s the visibility that is more important than the actual change.  The reason for this is that a single developer working on a custom Field or a Web Part will only work on his development machine for obvious reason.  If the farm + web application + site collection are shared, then we may have to create an unused sub-site for testing purposes during the development.

 

While this may seem cumbersome, at least on “paper”, it’s actually quite simple and is much simpler to manage than multiple environments.  This allows to have less requirements on the development workstations and resources are shared – the database/disk/backups footprint is lessen.

 

Mixed topology

At the next level, you can have the bulk of your development done in a single shared farm but this doesn’t mean you cannot have 1 or 2 other farms for specific development artefacts if they prove too cumbersome.  For example, you may want to have a specific farm (with content) used for various special operations such as testing new CU/Service Packs, 3rd party tools and solutions, etc.  All without affecting your standard integrated testing environment – it’s still easier to maintain 2 farms than 8-10.

I had a scenario where we created a development farm for support.  It’s purpose was to test anything else that wasn’t in the standard development line.

 

Conclusion

So far, I’ve had good success with the single farm topology.  There is some added governance to be done while implementing – primarily for developers and web designers – but this ensures that you have a good definition of what type of work is being done and which one you wishes to support.

On a daily basis, developers didn’t have a negative impact due to improper updates by someone else.  On a longer basis, management was much easier, especially with content updates and patches – we are now 100% positive that everyone sees the same thing.

While this may not be ideal for some situations, it certainly proved to be working well for WCM development.

Comments

  • Anonymous
    July 08, 2009
    Great post. I've used this model frequently (also mainly for WCM), and am also a fan if the scenario is right. For me, a use a rule of thumb of how many site collections the solution comprises - if it's just one (e.g. many WCM sites), I think this works well (and you have the option of just using Content Deployment to deploy DB assets to downstream environments), but if it's multiple site collections, you then have to deal with provisioning in the 'classic' way (e.g. with Features) so you may choose to use the 'isolated dev' model. I talk about this in my 'Approaches and Best Practices for deploying SharePoint sites through multiple environments' presentation. Definitely benefits to be had with this approach though - significantly that no time is 'lost' to provisioning tasks. Chris O'Brien.

  • Anonymous
    July 08, 2009
    Just went to check out the deck, good stuff and I'm glad I'm now alone :) The first opinion is always "aren't developers going to hit each other?" and it's rarely an issue -- if it's used for the right development type of course. Thanks for the input!