SharePoint Development Sever Yes\No

Question

My department head is insistent on having a Development and Production Server for our SharePoint sites. After speaking with some other professionals and working with the technology for several months, I am beginning to question the necessity of having this.

It seems that SharePoint is a fairly stable platform, and solutions that we are developing could be hidden from users while we work on them.

I am experiencing incredible difficulty while building workflows and Info Path form Libraries and then trying to migrate them to a different web\site application.

Should you have a development server for your SharePoint, or is this just causing more work for your developers?

Answer 1

I would lean more for having at least two server environments - development & production. In many enterprises there is a third (or perhaps more) server environments - QA/Testing/Staging.

There is also a matter of the business industry where the IT development & deployment takes place. In certain industries like HealthCare and Financial Services, there are very strict protocols and processes that have IT very heavily regulated (including fines & legal actions). For HealthCare, it is the HIPAA regulations and for Financial Services, it is the Sarbanes-Oxley regulations. Both emphasize security, privacy & audits in the IT environments. For example, in many such businesses - the developers are not "permitted" in the production environment and direct development on the production servers are verboten.

Answer 2

My personal opinion in regards to InfoPath and (SPD) workflow development is to do it in production. These activities and functions are nondestructive to the platform. Users are blocked access to the site and granted when the solution is ready.

Answer 3

The term "Development" has a lot of meanings within SharePoint. If you mean that you are doing customizations via SharePoint Designer then you can make those directly in production, as Eric said. Content can be created directly in production as well. However, if your development involves compiled code in any way then you really want that moved to a separate farm as deploying solutions with code can restart your application pool which would result in an outage of your production farm. Developers also have a habit of attempting to debug code and that process will block all requests from your site.

In almost all companies I've worked at that deploy SharePoint, there was a true production farm, an optional Authoring farm (content management) a QA farm (restricted access), and Integrated Dev farm (for bringing dev solutions together) and numerous virtual machines (one per developer) each acting as stand-alone farms for the purposes of development. This may seem like a lot but if you have any of the Separation of Duties requirements that sbc111 points out then you likely need them all.

Answer 4

Microsoft's pattern and practice group released guidance around SharePoint development http://spg.codeplex.com/. The guidance suggests the route of multiple environments (DEV -> QA -> Prod).

It sounds like you are creating content rather than traditional code artefacts.

You could always use content migration jobs to move your content between your different SharePoint environments.

In my opinion just because its SharePoint doesn't mean you that can't follow the traditional SDLC workflow and have all the advantages that brings.