Sean Holmesby

.NET and Sitecore Developer

By

Team Development for Sitecore (TDS) – Part 2 – Advanced Usage

I originally published this post on the Igloo blog.

teamwork11

In this blog post we run through how we attack some of the issues we’ve had with the advanced usage of Team Development for Sitecore (TDS).

In Part 1 we talked about what TDS does, how to use it, and item ownership and deployment strategy. We will now go deeper to talk about the more complicated issues with deployment.

If you have any questions, tips, or improvements on what is listed here, please post comments below. We’d love to hear how others are using it, and further our understanding of what can be done with this product.

This Part 2 in a series of three blog posts about our experience with TDS. Here are the links to all of the blog posts about TDS:-
Part 1 – General Usage
Part 2 – Advanced Usage
Part 3 – Settings and Builds

Field Level Deployments

When you have an item that is only needed to be deployed once, there may be a field on that item that you don’t want editors to change. Consider a content item that an editor can change the text, or image on. It will have a security field that you, as a developer, will want to control. With TDS you have the ability to set the field to always deploy, leaving the other content fields like a Title, Summary text, or Image to be content-editor-owned.

This is done through Field Level Deployments, where you can set a field to always be deployed. Simply right click on the item, and select ‘Field Level Deployments’. A dialog will show up with a list of fields, and you can select which ones you want to always deploy.

Field-Level-Deployment
Field-Level-Deployments-2

Hedgehog Developement have uploaded a video to Youtube where you can see this in action.

Resetting Fields to Standard Values

Field Level Deployments only work for fields where a value is set on the item. You cannot set the field values of an item to the standard values through Field Level Deployments. There does not seem to be a way around this, as the values of the field values don’t actually exist on the item (have a look at the serialised file of an item using standard values). For this, we just had to manually reset the fields… You know….the old way, by going into Sitecore, chosing the item, and going Versions->Fields->Reset.

Changing the template of an item

There is currently a bug with Sitecore serialisation where an item with a changed template will not properly serialise (as it may be missing the new fields from the new template). As a result, TDS cannot handle this, so wherever you change the template of an existing item you will have to change it manually in all of your environments.

Existing Item, Existing Template, New Field

We ran into an issue where we had an existing template and existing items that needed to be changed. There was a new field that was added, and needed to be set on each item, however once it was deployed, it was then to be content editor owned.

The items themselves were set to ‘DeployOnce’, as they are editor-owned. We set up Field Level Deployment for the new field so it would write the value when we deployed. The problem being that it would ALWAYS overwrite….so further deployments would stomp any changes from editors for that field.
Our solution was to set the field using the Field Level Deployment, but then, once the field was deployed and live, we had to remove the Sitecore items from the TDS Project altogether. Another solution would be to remove the Field Level Deployment after the inital deployment, but either way, we needed to do a ‘fix-up’ after the deploy.

Steps:-

  • Add the new field to the template, and bring that field item into your TDS Project.
  • Set the value for that field on each of your content items that use that template.
  • Bring each of those items into your TDS Project, ensuring that ‘DeployOnce’ is set on each.
  • For each, choose Field Level Deployment, and select the field that you’ve just added.
  • Once your feature gets deployed live, go back to your TDS Project, and remove the content items from your TDS Project. This will ensure that those values aren’t pushed live again.

The Sitecore Update Package

TDS allows continuous integration through builds, and automated Sitecore item deployment. There is a way to set this up using some of the settings mentioned in Part 3 of these blog posts. There is also an option to create a Sitecore Update Package. This package is similar to the update packages for Sitecore Upgrades (.update files), and can be created through the properties of the TDS project.

Right click on the TDS Project and select ‘Properties’. Click on the ‘Update Package’ tab and you will see the options available to you. Using your Visual Studio configuration, set the properties, and build the application. The update package(s) will be created in the location where your Build Output Path is set, in a folder called ‘Package_[Configuration]’.

Update-Package-Settings

Head to /sitecore/admin/UpdateInstallationWizard.aspx and upload the package. Sitecore will then install your changes.

I’m a little unsure when to use the Sitecore Update Package method, as opposed to CI builds using our build server. It is possibly useful for deployments to staging and live environments.

Links

Getting Started with TDS– See the section ‘Scenario: Setting up packaging of TDS items’

Field Level Deployment video -Youtube video from Hedgehog Development

5 Responses to Team Development for Sitecore (TDS) – Part 2 – Advanced Usage

  1. Pingback: Team Development for Sitecore – Field Level Deployments | Sean Holmesby

  2. Pingback: Team Development for Sitecore (TDS) – Part 3 – Settings and Builds | Sean Holmesby

  3. Pingback: Team Development for Sitecore (TDS) – Part 1 – General Usage | Sean Holmesby

  4. Shakti says:

    Hi,

    I have a question about language item package creation in Sitecore. Could you please tell me how to create a package for the items in a particular language in TDS? Example: I want to create a package only for fr-CA items, how would I do that using TDS? Could you please help?

    Regards,
    Shakti

    • sholmesby says:

      Hi Shaki,
      I think the thing to look at hear is that items are not per-language. A single item contains language versions… so english is part of the item, spanish is part of the item, french is part of the item etc.
      What you could do is choose to partially deploy items… i.e only certain fields.
      This can be done with Field Level Deployment in TDS, where you can select the language versions of fields you wish to push. i.e you can select field level deployment of the French version of the Title field.
      So while the item is set as DeployOnce overall, the French Title field is pushed using Field Level Deployment.
      This is a bit of a manual process, but it shows it can be done with TDS if you wish.

      Another point I’d like to mention is, TDS is a development tool…. So your content items should generally be separate from TDS deployment as they are content-editor owned, vs developer owned.
      Consider moving content between environments with tools like Razl….where again you can have that per-field-level granularity.

      Does this make sense?
      – Sean

Leave a Reply

Your email address will not be published. Required fields are marked *