As a development manager, I truly admire the architectural design of the Sitecore CMS platform. Its design intentionally addresses a specific customer need that a lot of CMS platforms failed to recognize or address. It is the need of accommodating how more than one developer can work on the same website at the same time. The process of making it easier to perform development duties without major system dependencies or additional tools. Sitecore is set up in such a way that multiple developers can contribute to the same codebase, use standard web application development practices, and maintain the integrity of the platform for a single website solution.
Below are some points that I believe Sitecore does very well to accommodate the need of multiple developers working on the same web project.
Package Manager
The Sitecore package manager is one of my most beloved features of Sitecore. The package manager allows a developer to create a single file of content from an instance of Sitecore and install that same package on A DIFFERENT instance of Sitecore WITHOUT destroying the target instance and KEEPING relationships to all related content IN TACT. This feature alone is worth buying Sitecore as a development platform for building new websites. This means I can truly move the work what I am doing in a development instance of the CMS to a quality instance of the CMS without breaking links to other content items. Sitecore stands apart from other content management systems that claim to have this feature but the execution of the feature has not been done to the extent of what Sitecore offers. This is a feature that a developer builds its entire practice and software development lifecycle around. That is how powerful the Sitecore “Package Manager” feature is. After using this feature in Sitecore and then going to other platforms to try to mimic the process you find yourself saying “I wish this was Sitecore”.
GUIDs as Unique Identifiers for Content
A support reason as to what makes the “Package Manager” so powerful is because Sitecore uses a GUID base content identifiers system instead of numeric identifiers which is a common practice in web application development. I am going to call this approach a feature because it amazes me that still today content management systems are not designed to use this identifying method as opposed to the numeric based system. For example if a CMS is using a numeric based system to uniquely identify content, and if there are two installs of that CMS on different web servers, and people are creating content in both systems, each system will increment is unique identifier usually by 1. Logically at some point each installation of that CMS could have generated the same identifier for different content items. Install 1 could have “Page1” with identifier “100” and “Install 2” may have “Page 100” with identifier “100”. Now each of the two installs would operate properly, until the need a rise of transferring “Page 100” from “Install 2” and move it to “Install 1”. How should the system react to that use case? Some CMS systems will give “Page 100” on “Install 1” a new identifier. This will cause “Install 1” to work, except that it will not be able to keep the relationships to content it created in “Install 1” as a result have broken links or broken relationships. Sitecore does NOT have this problem because it is using a GUID based system for content identification. When content is moved from one place to another, it will have the same identifier in whatever install/instance of Sitecore it is moved to. If more than one content item is moved all links and relationships to those links are maintained.
In conclusion, the “Package Manager” is a POWERFUL tool for transferring content from one instance of Sitecore to another. As a development manager, I have the luxury of providing my developers the ability to code with their local development instances without having a shared environment for development. This also allows for those local development changes to be integrated into a single environment for integration testing without the fear of conflicting content identifiers. This core design of Sitecore demonstrates the thoughtfulness of the system architecture that support easier IT/Dev management which often times leads to reduction in overall maintenance costs.