The Three Dimensions of TDS Classic Deployment
TDS Classic, a widely used tool for managing Sitecore item deployments within Visual Studio projects, offers three key settings that dictate how items are handled during a deployment. These settings, often configured once at the project's inception, can lead to unexpected consequences years later if not fully understood. Misconfigurations can result in the accidental recycling of template trees or deletions that fail to propagate to the web database. This article breaks down each setting, their interactions, and the critical combinations to manage for both the master and web Sitecore databases.
Item Deployment Control
The first critical dimension is Item Deployment, which operates on a per-item basis. This setting determines whether an individual item within your TDS project will be created, overwritten, or entirely skipped during a deployment process. When set to deploy, TDS Classic will ensure the item exists in the target Sitecore database, creating it if absent or updating it if it already exists. If set to skip, TDS Classic will ignore the item, leaving its state in the target database untouched. This granular control is essential for managing specific items that might have unique lifecycles or require manual intervention outside the automated deployment pipeline.
Child Item Synchronization (CIS)
Next, we have Child Item Synchronization (CIS). This setting governs the behavior of an item's children. When enabled for a parent item, TDS Classic will synchronize its children with those defined in the TDS project. This means any children present in the TDS project will be deployed, and crucially, any children in the Sitecore database that are *not* present in the TDS project will be deleted. This feature is powerful for maintaining a clean and consistent item tree, ensuring that only intended items exist. However, it requires careful management. If a parent item has CIS enabled and its children in the TDS project are accidentally deleted or removed, a subsequent deploy could wipe out a significant portion of the Sitecore content tree under that parent. Conversely, if CIS is disabled, TDS Classic will not touch any child items, regardless of whether they are present in the TDS project or not. This offers a safety net against accidental deletions but can lead to an accumulation of orphaned or outdated items if not managed manually.
Item Version Control
The third dimension is Item Version Control. This setting dictates how versions of an item are handled. When enabled, TDS Classic will deploy new versions of an item if they exist in the project, and importantly, it will preserve existing versions in Sitecore. This is the default and generally recommended behavior for content items and templates where version history is valuable. If Item Version Control is disabled, TDS Classic will overwrite the item with the version from the TDS project, effectively discarding any existing versions in Sitecore. This can be useful in specific scenarios, such as deploying a brand new template structure where you want to ensure only the latest definition exists, but it carries the risk of losing valuable historical data. The interaction between Item Deployment and Item Version Control is crucial: an item must first be set to deploy (or overwrite) for its versioning behavior to take effect.
Interactions and Database Targets
Understanding how these three settings interact is key to mastering TDS Classic deployments. The primary target for these settings is typically the Sitecore master database, which serves as the authoritative source for content and templates. However, the implications extend to the web database, which is what your live website users interact with. When you deploy to master, changes are then published to web.
The interplay between Item Deployment and CIS is particularly sensitive. If an item is set to deploy and its parent has CIS enabled, any children *not* in the TDS project will be deleted from master. If you then publish this change, those children will also be removed from web.
Item Version Control is only relevant if Item Deployment is set to deploy or overwrite. If an item is skipped, its versions are not affected. If Item Deployment is set to overwrite and Item Version Control is disabled, the item will be updated, and all its existing versions in the target database will be replaced by the single version from the TDS project.
Critical Combinations to Watch
Several combinations of these settings warrant special attention:
- Item Deployment: Skip, CIS: Enabled: This is a safe combination for the parent item, as it won't be touched, but its children will still be synchronized. However, if the parent item is *not* in the TDS project at all, CIS will not apply to its children.
- Item Deployment: Overwrite, CIS: Enabled: This is the most powerful and potentially dangerous combination. The parent item will be overwritten, and all its children in Sitecore that are not present in the TDS project will be deleted. This is ideal for enforcing strict content tree structure but requires meticulous project management.
- Item Deployment: Overwrite, CIS: Disabled: The parent item will be updated, but its children will be left untouched. This is useful if you only want to update the parent item's fields without affecting its children.
- Item Version Control: Disabled: Use this with extreme caution. It forces the latest version from the TDS project, discarding all others. It's best reserved for initial template deployments or specific, controlled updates where version history is irrelevant.
Teams often encounter issues when a project evolves, and items are moved, renamed, or deleted within the Sitecore content tree without corresponding updates in the TDS project. Without a clear understanding of these settings, a seemingly innocuous deploy can have cascading negative effects. Regularly auditing your TDS project's item settings, especially when major structural changes occur in Sitecore, is a critical practice for maintaining stability and predictability in your Sitecore development workflow.