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.
- 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.
- 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.