SharePoint ALCM: A real world example

For the past year, I’ve been working with a client that is in a very unusual position, at least one that has been rare in my career.  My client is an established business being spun off from their corporate parent, so they are starting up their IT department from scratch.  I had a similar experience almost a decade ago, when I joined an IT department right before a huge growth spurt in staff and responsibilities.

I was brought on board to help with their SharePoint portal initiative.  This included not only developing the SharePoint sites, but also helping to define the application lifecycle management for the portal.

First, here’s the technologies we used:

  • Windows Server 2003 R2
  • Windows SharePoint Services 3.0
  • Visual Studio 2008
  • WSP Builder
  • WSeVSS
  • SQL Server 2005
  • Visual Source Safe 2005

Some of these choices were made by other teams (Server 2003 and SQL 2005), but the rest my team got to decide.

We decided on the following environments:


The development environment is set of VPCs running locally on the developers’ laptops.  It is two VPCs running Windows Server 2003.  One VPC is a domain controller and the other VPC is the actual SharePoint server.  The developer is completely responsible for and in control of this environment.


The build environment is a typical development environment, including all of the development tools, plus SharePoint and SQL Server.  Build is intended to only be used and seen by the development team.

As the name suggests, the primary purpose of this environment is to build the code.  Since we’re doing SharePoint development, this means compiling the code and creating the SharePoint solution files (*.WSP’s).

The secondary purpose of this environment is integration testing.  The WSPs are installed and deployed on the build server.  This gives the development team an opportunity to check that the newly deployed WSP doesn’t negatively impact another developer’s code.  This same step could happen in the development environment, but for this project we didn’t take the time to continuously update all portions of our dev SharePoint sites.


The test environment consists of two servers: a SharePoint Server and a separate SQL Server.  All code is migrated to test using WSP files by the development team.

The primary purpose of this environment is to give the IT testing team an environment to do their testing. Since the development team controls deployments to the Test environment, we’re able to react more quickly to issues raised by the testing team.


The UAT (User Acceptance Testing) environment consists of three servers: two SharePoint servers and a clustered SQL Server. 

UAT serves several purposes.  First, the development team does not have access to promote code to UAT.  Instead, the Windows Admin team takes responsibility for code migrations.  This forces the development team to document the code deployment procedures and allows the Admin team to practice them.

Second, since UAT has more than one web front end, it allows the code to be tested on an environment that more closely resembles the production setup.

Third, UAT is the primary testing environment for our business users.  By having a separate testing environment for IT testers and business testers, we’re able to avoid scheduling and data conflicts.  We’re also able to present a more stable environment to business, since the test environment is more fluid with code updates.

UAT is also serving another group of business users that we didn’t really anticipate early in the project, but we were able to accommodate anyway: training.  We were able to have a week of training without impacting our development team or our IT testers.

There is also at least one more important reason for UAT: it serves as an troubleshooting environment for any production issues that might arise.  Again, since it closely resembles prod, prod backups can be restored to the UAT servers for debugging without taking down the entire prod farm.  In an extreme disaster, it could also serve as a production farm while prod is rebuilt.


Production is the actual environment used by end users (kinda obvious).  It consists of three SharePoint servers plus a clustered SQL Server.  Code is migrated by the Windows Admin team from the UAT environment.

At this point in the project, I do think these environments and the procedures we put in place are serving the client well. Of course, like any project, we have areas where we realize that we can improve.  Below is a list of some of our ideas for improvement:

Automate the build process

This is something that the team is starting to look into.  The client recently hired a strong developer who is familiar with Cruise Control.Net, so he is working to automate the code build and deployments.  This will greatly reduce or even eliminate the time a developer spends on the builds/deploys.  Also, like any automated process compared to a manual process, it will reduce build mistakes.

Separate the Active Directory domains

This is something that I haven’t mentioned up to this point.  Due to business requirements, we had to be able to authenticate users with both Windows Auth and Forms Based Authentication, with the user accounts stored in Active Directory.  Working with the Windows Admin team, we set up a Dev/Test AD domain and a UAT/Prod domain.  The prod domain was the only one that had a trust relationship to a domain owned by another company.  This relationship had to be tested, so we put UAT in the prod domain.

However, as we approached our prod date, it was decided that we couldn’t do certain things because the domain will be prod.  This started to reduce our ability to test certain scenarios.

What we should have done and what we may yet do, is create a UAT domain, with a “partner” domain that would mimic the real partner’s domain.

Change source control

A lot of developers will be surprised to read that the development team chose Visual Source Safe.  The client was already licensed for Source Safe (through their MSDN licenses) and the development team was familiar with Source Safe.  We didn’t have time to evaluate too many options for source control,  so in this case the team went with the devil we knew.  I think the development team will be looking into some flavor of Team Foundation Server in the next six months.

This project has been very interesting and I’m glad I got to do it.  My co-worker has written a few blog posts covering specific topics for this same project, so if you found this interesting, you may want to check out his blog as well.

Print | posted @ Sunday, November 1, 2009 12:43 AM