Several times over the last few weeks I've been confronted in one way or another with the need to protect coding from the interloping of the user and site administrator in SharePoint and conversely I've seen attempts to pour concrete around development that could be better left in sand so that it could be changed and moved. Through this I realized that there's a need for better understanding around the model shift with SharePoint and its impact on software configuration management (SCM).

SharePoint's a Different Kind of Animal

It's often been said that SharePoint is a desert topping and a floor wax – paying homage to Shimmer a fictional product from Saturday Night Live. It's also been said that SharePoint is like the proverbial elephant discovered by five blind men – each having a different perspective of what the animal is. Even within SharePoint you can see very different parts of the platform, however, some of the most interesting changes aren't about the product itself but in the things that it enables organizations to do.

By removing the barriers to creation (what Microsoft calls composites) the tool allows business users to create solutions to their problems. They dynamically create storage for new kinds of information – which in the past required a database administrator to create a table or add a column. The business user can string together a list, a workflow, and some alerts and create a system for managing or supporting some business process. The agility afforded by this toolset means that changes can be made at any time. In SharePoint many of these changes are version controlled so if a mistake is made the user simply reverts to the previous version.

This agility is in stark contrast to the structure of a large scale development effort. Organizations spend an inordinate amount of time building structure around the software development process so that systems can be recovered and recreated. This effort is necessary in a world where specialized skills are necessary to create and maintain systems. You simply can't have the payroll system changing everyday – and changing in ways where it's difficult to explain to an employee – or the government – why a person was paid exactly what they were paid. So there are source control systems where code is maintained and controlled. There are configuration management practices which are used to govern changes to the system.

All of this leads to both repeatability – you can restore to any point in time and replicate it anywhere at any time – and control. This is desirable from a recovery perspective. These two outcomes are very desirable in a traditional system – and since traditional systems don't allow users to create solutions on their own their relatively limited flexibility and need for coordinated activities is not a major barrier.

The real question comes when the rigidity of a SCM meets the agility of SharePoint and we have to answer hard questions about whether something should be treated as traditional code or whether it should live in the user world of agility.

Mapping the Extremes and the Middle

Even in SharePoint there's some level of clarity that some things are software development and need SCM. If you're deploying farm based solutions there's a need to have a brief outage as the software is deployed – this is a clear reason to control the rate of deployments of solutions. Equally clearly if you are adding a contact to a contact list, you know that this is content and therefore should be handled like content – instead of being handled like code. That's the easy part. Where it gets more difficult is when you look at items which are markup languages and non-compiled languages.

Consider that Cascading Style Sheets (CSS) controls the look and feel of the web site. It's a language for expressing how the display should look. Most folks don't consider CSS to be a programming language; it's a markup language much like HTML. However, there is a sense that CSS should be protected like code because it has a great potential for causing issues on the site. Yet, many new web parts need their own snippet of CSS to work, sometimes overriding the behavior of the code CSS for the solution.

Like CSS, eXtensible Stylesheet Language Transformations (XSLT) isn't a programming language. It's a markup language with potentially huge power to change the appearance of the site. With that sort of power it "feels like" it should be a part of SCM and managed. But what about the XSLT used to format search results, or the results from a Really Simple Syndication (RSS)? It seems like our rules break down when the same technology is used for core system things and for user controlled formatting of resulting data.

JavaScript is the language for manipulating objects in HTML once it's at the client. It's a programming language, no question about it. This would lead you to believe that it should be a part of the SCM – but again with SharePoint we often have JavaScript that is a part of a web part that a user might add to a page. Do we restrict all JavaScript to being a part of the SCM process?

In SharePoint we also have the unique challenge of SharePoint features and the XML they contain. XML can tell SharePoint to create a content type, a list or even to create data. So does the XML that sets up your list and the sample data count as code – or content? Making the situation more challenging is the user code host – sandbox execution – which allows compiled code to run in a restrictive environment.

Does your head hurt yet?

Criteria for Decision Making

It used to be that we could make a simple decision. If it was compiled it was code – and if you didn't have to compile it then it wasn't "real" code. However, over the years the lines have blurred to the point where making the decision based on the file type doesn't work. Instead we need to make decisions based on the intended use of the file.

Breaking down intended use a bit there are two key things to think about. First, what's the worst that can happen? In other words, if the file gets modified, out-of-sync, or destroyed what's the worst case? Second, how are changes going to be managed?

In the case of what's the worst that can happen, you might have a style sheet that drives the rendering of the entire site. In this case the impact of the file being modified or deleted is pretty large. As a result you would want to protect against that. Conversely, if there's a style sheet that is responsible for a minor part of the web site – it might be OK to treat that as content. SharePoint has built in version control and a recycle bin so recovery should be as simple as reverting to a previous version or recovering the file from the recycle bin.

The other side of the coin is how the changes are going to be managed. If you go the code approach to management you have to go through the configuration management process to deploy the code to controlled environments. This can add weeks and weeks of time to the deployment cycle. If there's any need for agility you can't treat it as code. Conversely, if the item never or rarely changes it might be acceptable to treat it as code. When making the decisions you should consider how many variations of the same thing that there may be – if there are many variations it's harder to manage them as code.

Of course, some items, those items which are compiled code that can't be deployed to the sandbox must be treated as code and managed through the software configuration management process so the decision has been made for you due to technical or design limitations. For everything else, the question is how you're planning on using it.

Making it Concrete

Treating anything with a configuration management process is like pouring concrete around it. It's certainly possible to remove something buried in concrete by breaking the concrete out and starting over – but it's not nearly as easy as pulling up stakes and moving on. There are some things you need to pour concrete around. A backyard basketball goal needs concrete to steady it. However, Pouring concrete around the stakes of your tent may not be the best choice. Pour concrete when you need to – and avoid pouring concrete when you don't need to.