MOSSy Business

SharePoint Code Acceptance Process

While most companies make sincere attempts to stay as “out of the box” as possible, there comes a point at which custom or 3rd party code becomes necessary to meet the needs of the organization. This is NOT a bad thing… SharePoint is designed to be extended. However, there are certain steps that will help ensure deployed code is as well developed as possible.

On Open Source code (Codeplex.com for example): Remember that “Open source” code should be treated essentially the same as “Custom” code. That is, if you want to take advantage of the functionality someone else provided, you should also be willing to take ownership of the enhancements, bug fixes, compilation, and packaging. There is no company or support organization to help you or provide you with fixes if there is a problem, and there is no guarantee that the source code will be available at <insert custom code download site here> forever. (Welcome to the hidden cost of open source… you get what you pay for.)

Generally, the SharePoint development team is separate from the Administration team that supports the system and it’s users, and thus they have different objectives. Developers are trying to make new stuff, while the MOSS administrators are focused on keeping the existing stuff running as well as possible… or to put it another way, developers exist to create change, while administrators are focused on reducing change to increase stability and availability. To be clear, it is a GOOD THING that these two groups have opposing goals… think of it as checks-and-balances for your server environment… but we still need to get something done, so we need a process and clear agreement on what we’re doing and how.

Below are the minimum criteria I would recommend. Note that additional process steps or criteria can be added as appropriate.

1. All code (custom, 3rd party, purchased, whatever) MUST be provided/deployed as a SharePoint Solution Package.
   SharePoint has a software deployment model that puts the majority (if not all) of the responsibility of ensuring SharePoint code (features, templates, etc) is deployed properly into the hands of the SharePoint Developer. This is technically correct… the developer should know the location that files need to be copied, the GUIDs for web parts to be added to the Save Controls list, the naming of specific features, any dependencies in features, any feature activation dependencies, services that should be activated, etc., so SharePoint provides with developer with a way to define this via Solution Packages.
   3rd party vendors may provide code as installation packages (“setup.exe”) instead of pure solution packages. This may be acceptable as long as a solution package is ultimately the deployment methodology being used.
2. All code should return with no issues when analyzed using the SPDisposeCheck tool.
   Because the SharePoint object model relies on several COM components, the rules of “pure” .NET development do not necessarily apply. Specifically, the practice of relying on the .NET CLR to automatically clean up memory does not behave as is typically expected. This means that developers must ensure they specifically dispose of their objects properly in order to prevent significant memory leaks (that will only expose themselves during load testing) from occurring and creating significant problems in your production environment. SPDisposeCheck can detect the most common scenarios that these issues can occur, so provides a simple way to check for the most common errors. However, false-positives are possible, and this tool does not catch every possible code structure, so load testing should still be done… but this is a great way to identify possible issues quickly.
   Tip: You can analyze the code within a solution package by changing the package to have a .CAB extension and extracting the files. You can then run SPDisposeCheck on the extracted files. 3rd party code can usually be checked in this way also.
3. No Microsoft-provided or out-of-the-box files should be modified as part of the deployment (with exception).
   Overwriting or directly manipulating most SharePoint files is generally considered a severely bad practice. Doing so introduces a significant risk that updates to SharePoint will cause such changes to be lost, and/or cause incompatibility as “old” files from custom solution packages overwrite newer files that contain fixes or compatibility elements with updated DLLs or code. There are exceptions (ex., docicon.xml must be updated to include the common PDF icon association), but generally updated Microsoft provided files should not be necessary.
4. All code should be created in a company specific namespace.
   Occasionally, developers believe that in order to properly use the SharePoint object model, their custom code must be in the “Microsoft.SharePoint…” namespace. This is incorrect, and doing so will make troubleshooting significantly more difficult. Instead, the namespace (and related filenames) should reflect the name of the company doing the development. For example, “Contoso Company” might create all of their SharePoint development in the “Contoso.SharePoint…” namespace.
5. All post-deployment configuration must be done through a provide UI interface.
   In many cases there are two steps required: Deployment and Configuration. With deployment having been automated using Solution Packages, it would be ridiculous for us to now have several steps that require going into the configuration files we previously avoided and update numerous settings. Rather, it should be considered a requirement that, if environment-specific configuration is required, an interface for defining that configuration should also be provided. Further, the configuration for that item should be in the appropriate area for where the feature is scoped. For example, if a feature is farm-wide, the configuration should be accessible through Central Administration, whereas if the feature is scoped at the individual web site, access to the configuration pages should be visible in the Site Settings page. Interfaces for programmatically creating these links are available in the SharePoint object model.
6. Code must be reviewed and have sign-off from at least one additional developer prior to test submission.
   Code reviews significantly enhance the development process and team by A) reducing common errors in code that would otherwise be found in testing or development, B) increase knowledge sharing because the reviewing developer may learn new ways to interact with various components or new software development/design patterns, C) decreasing supportability risk if a single developer leaves or is on vacation because multiple developers are familiar and accountable for the code. This will also generally increase the overall quality of the code being generated (because no developer wants to be embarrassed by their code).

While these items may hover back and forth between “policy” and “process”, each item contributes significantly to the ability to catch errors early and/or identify errors easily and quickly.

If you think something is missing, comment below and I may update this post with the suggestions that provide the most value.

Happy coding!