I recently got down to writing a process document for synchronising SharePoint production, test and development environments to ensure consistant, predictable behaviour when moving developments through these farms. During my analysis of the deployment process it became evident that several separate solutions were copying the same files to the hive directory. This would mean that the order in which these solutions were deployed would determine which development functioned correctly.
So how can we fix this? What is best practise when dealing with deployments to the hive directory? I am not entirely sure myself and there seems to be a few schools of thought on the subject but in my opinion, the better of the options would be to source safe the relevant hive sub directories and communicate this to all developers so that they can update or add to the relevant project when needing to make a change in the hive.
The project files should be organised in their hive directory structure. For example, the TEMPLATES project might look something like this (most sub directories have been abstracted from this view):
Only production-ready files should be checked into the project so that developers are not deploying error prone files to the hive unknowingly. Alternatively, developers can modify the build events and solution manifest file in their local environment to package and deploy only the files they are developing. The central, checked-in copy of the project should build a cab file containing all hive directory files and deploy them to the relevant hive sub directories.
The FEATURES directory does not need to be organised using a VS solution like the TEMPLATE directory. Each new feature to be deployed to SharePoint should have its own VS solution which is deployed separately and consequently can be activated and deactivated without effecting other hive files and solutions.
It is important to note here that Microsoft do not recommend the modification of hive directory files as hot fixes or service packs may over-ride the changes. In my experience though, sometimes it just makes customising a SharePoint environment to a clients specific needs that much easier but if you really think about it, there is always another way 😉