Categories

Vanilla .NET
Non Techie
SharePoint
Bak2Basics
Books Authored
Books Reviewed
Community
Silverlight and WPF
WCF
Azure

Other material

SharePoint Environments - when developing as a team

Posted on 10/6/2007 @ 3:29 PM in #SharePoint by | Feedback | 5247 views

I just got done talking about what you need to have on a single developer's sharepoint environment.

But, when you develop stuff as a team (which we all do), things are a bit different. They are both good and bad. Good because you can leverage better tools, and bad because you have further complications such as source control, versioning, automated testing, deployment etc.

This blogpost intends to demystify all that and more.

The very basic environments you need:

When developing as a team, the following diagram depicts the very basic environments you will need -

As you can see in the diagram, there are two kinds of "things" you need to manage in your MOSS project.

  1. Assemblies (Visual Studio): What developers will create. Anything that involves VS2005, and requires compilation, strong naming, deployment - that kinda stuff. This is what a developer will be hella familiar with. Note that there is no "F5" and a SharePoint environment is assembled for you on the fly. The mentality here is that, the environment exists already, and an F5, adds your widget to the pre-existing environment. That environment exists on your developer environment machine, and the widget is being developed on your local virtual machine, and source controlled by a source control server.
  2. Artifacts (SharePoint Designer): This is what designers in a team would work upon. The role of this portion becomes extremely prominent in WCM scenarios. Once developers have created an environment, authoring a new page should be possible via a browser, and authoring new page layouts is done using SharePoint designer. This stuff is moved over to production, using - content deployment paths.

And you can keep the whole picture in sync by using simple source control techniques and backing up/restoring content databases.

A few more points of mention:

  • Keep the Dev machines and Integration environment in a seperate domain. Why? This has many advantages.
    • Better isolation: You don't want to use production user ids, and accidentally overwrite production stuff.
    • Your written code will never rely on hard-coded ids, deployment instructions will remainforcibly clean.
    • It will be easier to give developers ownership of the environment, without risking production sanctity. In other words, it will reduce the fights between developers and infrastructure people.
  • Designers need an environment that may or may not be on the same production farm. But their 'stuff' gets deployed using content deployment paths.
  • Environments can be kept in sync using content db backup/restore + running deployment scripts. This is a great way to maintain your backup/restore disaster recovery process also. Please read this blogpost for specific step by step instructions.
  • The development environment for a team, differs a tad bit from a lone developer's sharepoint development environment.

SharePoint Developers Environment in a Team:

Before you read this portion, go read A single developer's MOSS dev environment first. Why? Because many of the concepts are same.

Once done reading that, come back here and continue reading.

Okay, so again the advice is "Virtualize".

But, here you have the advantage of using a domain for your development all the time. This applies well to an environment where developers physically get together in a brick and mortar office on an everyday basis.

As you can see from the diagram above,

  • Developers share a SQL Server, this reduces the workload on their Virtual Machines. To keep everyone's life sane, the following standards are followed:
    • Config databases are created for you - and the GUID'sh name is prevented using a commandline to perform the initial setup that allows you to specify the config db name.
    • Content databases are named as SM_WSS_CONTENT_80, i.e. initials_WSS_CONTENT_PortNumber. So when SM gets fired, it is easy to clean up all of SM's content DBs. :).
  • Developers stay in synch with each other using a source control server. There are best practices for source code control specific to MOSS environments (upcoming blogpost).
  • All standard development source control techniques apply. Remember all you learnt about branching/versioning/deployment? Yeah all that applies.
  • It is super damned easy to setup an automated build process (upcoming blogpost), and have that code deploy automatically in integration web front ends as packages.
  • Note that the code is physically deployed on only one WFE. The other WFE is automatically replicated using sharepoint itself or application center for things that fall out of sharepoint's purview (example, custom web controls, or third party products).
  • The WFE is load balanced with 2 WFEs atleast. Why? because your production environment will be. (For resilience). And you need to ensure that your custom code will work in a load balanced environment.
  • Code that requires multiple machine development scenario, is automatically tested in this manner.
  • The final package is delivered to QA - this is a manual process which considers branching/versioning - whatever you would otherwise follow in a plain vanilla .NET project. (Every organization is different in their maturity level frankly).
  • And QA sits in the production domain, and can also be used for user acceptance testing. Integration environments are used for prototype demonstration with fake userids.

Sound off but keep it civil:

Older comments..


On 10/7/2007 9:54:23 PM AC [MVP MOSS] said ..
I disagree with your first graphic. You should not use content deployment for moving your "artifacts" as you say it from your designer env. to production. This would require a very customized Content Deployment code implementation as with the Web UI you can not deploy only certain files. To preach the model you propose (and I advocate as well), there should be no "left" side of that graphic... ASPX, CSS, etc... all those files should be deployed just like assemblies... use file provsioning using Features to achieve this. This is outlined in Ch4 of the Real World SharePoint 2007 book by WROX.


On 10/7/2007 11:42:34 PM Sahil Malik said ..
AC -

Point taken. In practice Content Deployment does not work nearly as well as advertised by that graphic, and this MSDN article - http://msdn2.microsoft.com/en-us/library/bb428899.aspx (see Figure 6).

Sahil


On 10/7/2007 11:50:11 PM AC [MVP MOSS] said ..
Sahil-


You missed my point. It isn't that Content Deployment "doesn't work nearly as well", it is that this process keeps all your content in the database exclusively. Nothing resides on the file system. I don't advocate that at all and, with WCM sites specifically, I recommend putting these files in Features and on the file system as I outline here: http://www.andrewconnell.com/blog/archive/2006/12/20/5451.aspx

Just a difference of opinion.


On 10/8/2007 12:50:43 AM Brian H. Madsen said ..
Hey Sahil,

It doesn't quite seem to be such a great way of working. there's a lot of code involved with developing anything and that's naturally (yes!!!) stored in a source code repository, but how are you going to handle the problems you face when configuration changes are done on the sharepoint install in a virtual environment? eg. for instance, you cant VSS a whole VHD and you can't store your config files etc from MOSS in a source code repository without it becoming rather messy.

I see it as one of the problems in working with Sharepoint as a development platform - it's very much integrated into the OS and as such it poses a massive issue in terms of development efficiency in a team environment...

dunno...there must be better ways of working..can't believe this is the most efficient way...


On 10/8/2007 1:29:37 PM Sahil Malik said ..
Yo Brian -

"there's a lot of code involved with developing anything"

.. not in sharepoint land there isn't :). You write only the missing peices that didn't come OOTB. SO it is nearly not as bad.

And explain "configuration changes"? What are examples of such config. changes?

SM


On 10/9/2007 5:01:15 AM Brian H. Madsen said ..
Hey Sahil,

I've recently had to develop a custom document request management system for WSS/MOSS and one of the limitations I had was that i couldn't create sharepoint web parts and/or install them into the GAC to give them full trust.

To circumvent the limitations I used a Web Page Web Part to pull in a virtual site (under the sharepoint install). This was all well and good till i was told I had to imlement features that contained calls to the WindowsPrincipal.

To enable this i needed to add certain assemblies to the minimaltrust.config file.

Another problem I had was that i needed to use AJAX within the solution. Again, configutration changes to the web.config files.

In a virtual environment i'd have had to re-configure the original site's config files twice over. What if another team member had similar issues and needed other assemblies entered into the SecureClass section of the minimaltrust.config file? we'd either have to ensure we didn't overwrite the other member's changes by manually entering them again. Couldn't just copy and paste the file into the directory.

I hope this explains what i meant by "configuration changes"?

Its a small issue as long as communication is solid - but we all know we don't live in a perfect world.


On 12/14/2007 3:58:39 PM Francis J said ..
The overhead and complexity of this environment is considerable. You would need at least one admin, possibly multiple ones to handle all of the ADs and servers you need to stand up in this type of environment.

Also, who handles the database migrations/backup-restores? That's a complicated process which has to be managed closely. There will always be lag between the designers producing artifacts and developers consuming it. What happens when developers work on artifacts which are out of date because designers have made a change which hasn't been migrated?

I go back to my original point. There is a ton of hardware and infrastructure to setup here. This could potentially take months to stand up and debug. There are also some wicked synchronization issues.

The more I read articles like this, the more I begin to realize that SharePoint development just isn't worth the effort.

On 12/14/2007 5:28:48 PM Sahil Malik said ..
Francis -

You're making it sound tougher than it really is.

SM

On 3/25/2009 8:55:20 PM David Bullock said ..
I really appreciated this advice, thank you.