TDS workflow when content items need to be deployed

Question

This likely applies to other serialization solutions as well, but I'm specifically using TDS in this case.

Here is the scenario:

• A site is developed and has gone live with some baseline content. This base structure is in TDS.
• Content authors have made edits to content items (as they do with a WCM).
• Meanwhile, development is being done which adds new fields to templates, potentially restructures pages with new renderings.
• Now this new development needs to be deployed without overwriting content changes.

Typically you will configure your Deployment Properties in TDS so that your production packages do not include items "owned" by content authors. But what about cases where new functionality requires introducing new content, or structural changes to existing content?

Is there some sort of best-practice workflow with Razl or TDS that can help with this? It just a matter of syncing production content and having a content "freeze" prior to deploying the new functionality?

Answer 1

In my world I try to make sure templates are controlled by the development team so that we always deploy those. That allows us to make minor changes across the board without worrying about deployment issues. Training for authors to stay out of the templates is required, or you have to split up the template into a 'structural' and 'marketing' template with inheritance so that the authors have a place to play separate from where you deploy.

This doesn't work as well when you need to do something like add a component to specific pages in a specific placeholder. For me, this isn't something that should be automated with TDS, nor should it be in source control. This is an authoring task.

If the task can't be accomplished because it requires something that hasn't been deployed, that code/structure should be deployed first and then the authoring task should occur in production. (You might want to take a copy back into pre-prod/staging/UAT/wherever just to double-check everything works before you go to prod.) In this continuous delivery model, you are deploying code that needs to be able to work without the author needing to make the change. Perhaps you have feature toggling, perhaps you have things triggering alternate display flows based on the presence of a component, but in some way you need to make this 'safe' for delivery to production.

When you do have a lot of authoring edits that need to be made in production, I would consider that part of the package that needs to be deployed is a Sitecore Powershell Extensions (SPE) script or something similar that can be executed in production to avoid manually executing all the steps.

Answer 2

Even the Helix Guidelines make a distinction between "Definition Items" and "Content Items". In your case, you seem to be asking about Content Items that are created in production

Even if Content Items are owned by the production environment, sometimes the business logic will have to know about the specifics of these items, for example their location or type, or the development process might need to change specific data in them – for example, if business logic introduces new settings or fields in a template that require initial values in the content of the sites. Therefore, Content Items can be split into two sub-categories: items that are created in development and deployed once into production, and items that are created and managed in production.

link

That said, one must be careful to properly segregate this business logic-dependant content items from content truly owned by the production environment. With that, you should be able to deploy this content at will. In the case of new fields (coming from definition items), you may need a one time script to populate these fields (if setting a standard value for the field will not suffice).

If there is a case where this is not possible, you probably have to approach this with the same mindset of re-architecting the solution, because by definition, your are. And at this point, you're well beyond an issue of tooling.

Answer 3

Technically there is a option in tds. I will give a good thought on JayS comment though.

You can set the item's "Item Deploy" field to "Deploy Once", which will prevent deploy already existing items to instance.
I think already deployed items tracked by item id.

Answer 4

This is a bad strategy in overall as a Business Approach, we had the same when I worked on KIA, and we had issues when client could create new content, at the same time we were bringing new changes to the content, which conflicted with their new content created in Production. To avoid overriding I had to package up things from Prod, bringing it to Dev and syncing the difference, then redeploying to PreProd with all the changes you've done and validating it, then pushing to Prod.