The Scenario:
The standard rule, “all code must be backed up”, or more specifically for a Microsoft shop, “all code must be in Visual Source Safe (VSS)”, definitely applies to an organization’s SharePoint “12 Hive” customizations. Wherein, their developers have produced uniquely branded master pages, css and javascript resources, custom site definitions, and the list goes on and on. Any given installation may have hundreds of “man hours” invested in the hive. The question is, how do I effectively backup all this work? Simply put, the answer is of course VSS, however, much like any other topic that is worth blogging about, it’s never straight forward.
The situation with VSS that I have seen in many SharePoint environments is that it is treated much like a typical network drive that gets routinely backed up, rather than what one would expect from VSS where its features are fully utilized. Since the hive files are files on the server and are not inherently associated with VSS or a .NET project, the natural temptation is to just copy the whole directory onto a backed up network share or the subset of altered files into VSS. With this approach, there are 3 obvious problems:
- It is difficult to ensure that all the files altered in the hive, are actually being backed up (unless you backup the entire hive, but that consumes valuable disk space needlessly).
- Subsequent changes to the files may never get pushed up to VSS or the share, leaving you with obsolete code in your VSS database. Your only choice to combat this is to have a policy that if a developer changes files in the hive, he would have to be diligent enough to thereafter deploy the changes back up to VSS. This approach makes it nearly impossible to guarantee retention of all their work if some sort of disaster scenario ever occurred. The bottom line... if it is not easy, it won’t happen.
- Check-in and Check-outs are irrelevant because the developer can change the files in the hive on a whim.
The Proposed Solution:
The solution is to create a .NET project that houses a copy of all the new and customized files for your farm’s hive (you can include files outside the hive, but it is generally accepted as the best practice to house site dependant files within the hive). This way your developers can check out and in the files, and on their distributed dev sandboxes, you can enforce a level of consistency that is impossible otherwise. Additionally, this is an effective approach to help keep developers from overwriting each other’s code.
However, this alone isn’t enough. There is still nothing keeping your developers from simply going to the hive and editing the files directly, which is undoubtedly much easier than manually copying the files from the project directory every time they make a change. Unfortunately, I know of no way to force them to stay out of the hive (assuming the need to be box administrators).
The trick is to make it even easier than a direct edit, giving them no reason to go in there in the first place. You do this by specifying an output script in the project properties. When the developer builds the project, the script automatically deploys all their changes for them and can even recycle the app pool, essentially leaving them with an F6 deployment (very easy indeed!) .
Keeping your files centrally managed in a project linked to VSS plus giving your developers a one click deployment from that project is the combination that can keep them out of the hive and give you confidence that your $$$ are being protected and your environments are consistent.
Steps to Take:
I’m not going to take the time to describe how to configure a VSS connection to a .NET project. That is rather common knowledge and is documented elsewhere. However, I will go through how to setup the project folder structure needed for the hive deployment, as well as how the post-build script functions.
Figure 1 shows a typical .NET solution for a company’s intranet code. I propose creating a new project titled something to the effect of “12Hive”. In it, you’ll notice a directory structure that is similar to what is present in the hive. Start off by identifying each file that is custom or modified in your hive, replicate the folder structure manually in the project, and lastly copy and paste the files into the project.
Figure 1
As you can see, the example shows what one would typically be working with in the hive. I have a custom site definition called “Contoso” at the bottom, with its dependant WEBTEMP file. There’s also a feature called “AltHeader”, and some other resource files in the “LAYOUTS” directory.
This is all pretty straight forward. The “magic” lies within the command line script that takes each of these files and deploys them to the hive. To add an output script, right click on the project and choose properties. Under the “Build Event” tab, click the “Edit Post-Build…” button. Notice the command line script below:
cd "$(ProjectDir)"
xcopy "TEMPLATE" "%CommonProgramFiles%\Microsoft Shared\web server extensions\12\TEMPLATE\" /ys
%SystemRoot%\system32\iisapp.vbs /a "SharePointAppPool" /r
The “cd” command is the command to change the directory on the command line.The “ProjectDir” is a reference to the project Marcos (figure 2) that specifies the location of the project.
Figure 2
The first line is simply changing the command line directory to that of the project directory. The “xcopy” command is copying the “Template” directory that’s in the project, and putting it in the “Template” directory that is at the root of the hive (notice the path). The “/ys” at the end of the line specifies to only overwrite (or add) files in the hive that are in the project, not to overwrite the whole directory (that would be bad). The last line recycles the specified app pool (note, “SharePointAppPool” should be changed to whatever your app pool name is). This saves you time if you made changes to the ONET.xml file whose changes require a recycling before they would take into effect. If you don’t want to specify an app pool, you can change this to run the command to reset IIS which recycles every app pool.
After you hit ok, and build the project, all your files in the project will be automatically deployed into your hive!
If all your developers use this approach to making hive changes, you can effectively enforce keeping your code updated in Source Safe. Once the file gets into the project, hitting F6 becomes easier that editing the files directly. Plus, your developers will be less inclined to edit them directly in fear of them being overwritten.
Taking this to the next level:
Part 2 of this post will cover deploying your hive files easily from one environment to another. You probably noticed the path “%CommonProgramFiles%” that the “Template” directory was deployed to. It is easy enough to change this to something like “\\ContosoServer01\c$\program files\common files\...” (or a mapped drive for that matter) to deploy your hive to a remote server, rather than locally. However, in most organizations you’re going to run into an environment that you don’t have access to (i.e. production). Even if you have access, you will have to run a build for every web front end as well as check out the project to even make these changes, which will adversely affect other developers if it gets checked in. Obviously this is unacceptable! I have literally spent a week typing up 100 page implementation plans to hand off to my system administrators to do installations, but gist in part 2 is that you can enable your system administrator to deploy all your hive changes to all of the web front ends in your farm with one double click of the mouse, making drawn out implementation plans a waste of time. Thank Goodness!