If you have decided to move to a continuous deployment model with your Sitecore solution, you now have several hurdles that you need to overcome to get your solution from development into production without risking the stability of the user experience.  One of these is the introduction of new ‘building block’ content items such as templates or sublayouts.  It may take several iterations to get new templates and sublayouts to be correct, so how do we introduce these into the Sitecore database without affecting the production experience?

Continuous Deployment?

If you are not familiar with the concept of continuous deployment, there are some great reads out on the web:

• Continuous Delivery vs Content Deployment: What’s the Diff?
• Continuous Deployment and Testing in Production
• Continuous Deployment at Etsy: A Tale of Two Approaches (slideshare)
• Continuous Deployment: The Dirty Details (slideshare)
• Guide to Agile Practices: Continuous Deployment
• Sitecore Continuous Deployment: Video from SVUG

Essentially, you want to achieve the ability for deploying to production all the time using automation.  This eliminates the time lost moving from one staging environment to another.  Of prime importance, however, is to make sure features are not opened up to the users until they are ready to be used.  You still need to test, you just do your manual testing in the production environment itself.

If your risk-management head just exploded, you probably want to ask yourself: how much manual testing are you doing? How much manual testing SHOULD you be doing? If you have built solid automated unit tests and integration tests, your application is already being tested every time a check-in is made, and the build is rejected if the tests fail. If you would like to move to a continuous deployment model, but don’t have automated testing as part of your process, then that will have to be one of your first steps.

I’ll try to cover the automated testing portion of continuous deployment in another post, but for today I will assume that you are already ready for continuous deployment, but need to know how to do that with Sitecore content items.

Hiding with Security

If your templates or sublayouts are ready for manual testing in the production environment, the simplest way to hide them from use is through the use of security. By creating a ‘test’ role and assigning it to the sublayouts and templates that are not ready for use, only your test team will be able to create content using those new templates, or add those new sublayouts to a page.

This will also translate to the end-user experience in that end users will not have the ability to view content created with these templates, or view these sublayouts on the page.

When the test team gives the go-ahead for roll-out of the feature, it can be immediately enabled in production by simply removing the security. Note that the development team also needs to update their own source control of the item to match so that future deployments do not add the security back.  You may just want to make the change in source control and push the change out through your deployment pipeline, just to be sure.

Excluding from Deployment

While security is handy for the situations where a template is ready for testing, there may be situations where you don’t want the template or the sublayout to exist at all yet, even for the test team.  If you are using a tool like Team Development for Sitecore, you can choose to exclude items from deployments so that they are not pushed out.

This method should only be used in extreme cases, as the principles of continuous deployment should be followed and you should push the changes to production.  However, there are cases where something could be such a breaking change that it needs to be source controlled, or needs to be deployed along with other items that haven’t been built yet.

Handling changes to existing templates

While the above methods work well for new items that are not related to existing items, these approaches do not work as well when you are introducing changes to an existing template.

With templates, field level security can be used to hide new fields from the authoring interface, but a change to an existing field cannot be handled in this way.  Similarly, there is only a single presentation details field for the template, so you cannot secure one field over another for that particular change. So how to deploy the change while still supporting the previous model?

Field renames (and other minor changes)

If the change is minor, like a field rename or updating the default value for a field, the easiest approach is to just deploy it. Renaming a field rarely causes an issue if you are loading data using field IDs instead of field names.    However, if your code is dependent on the field name, the first thing to do is refactor the code to reference the field ID instead, so that the rename can be done safely in the future.

You should also ensure you have some unit tests and automated UI regression tests set up that will be able to catch any issues with this rename during the deployment.

Changing field data types

If you are changing data types on the field, it may be better to introduce a new field with the new data type.  Using the security approach mentioned earlier, this field can be hidden from the authors so that it can be tested.  The downside here is that any code that uses the field needs to be updated to toggle which field to bind to, based on the current user’s field access. When the test team is satisfied that the change is working, the change can be made to the original field and the new field can be removed.  Remember to remove that field-toggling code!

This can be a costly solution to avoid risk. If you are looking for a lighter-weight solution, you may wish to go with a ‘change it and unit test’ approach.  This will likely mean a little bit more work on the automated test side to really be comfortable that your data type change didn’t break something, but it does mean you won’t have to create two fields and introduce field-switching code.

Changing Presentation Details

The default presentation details are stored on the template standard values item, so with only a single field and single item to work with, a different approach is needed.  In general, re-arranging existing sublayouts should have little impact and can be safely done.  The difficulty begins when we start adding references to new sublayouts or new placeholders that need to be tested.

As mentioned previously, security can be used on a sublayout so that it does not appear to the authors or end-users, which will allow for adding most content sublayouts to presentation details without any issues.  However, some sublayouts are used for layout purposes, and not displaying field data, and changes involving these types of sublayouts usually involve re-architecting the layout of components on the page. Automatically deploying this kind of change could affect all created items made from the template.

For this reason, I propose using new templates when re-architecting the presentation.  By saying the layout needs to change significantly, we are essentially changing what type of template the author should use.  If not already doing so, ensure you are architecting your templates as Data templates versus Presentation templates.  This means that you have base templates that define the fields used for a template and another template that inherits these fields but defines the presentation details.

Not only does this allow you to share fields across multiple presentation options, this also allows you to now support introducing new layout changes without losing any field data on a content item.  The test team can test the new template, and when it is deemed ready, content authors can begin updating existing items to use the new template where appropriate by using the Change Template feature.  Since both the previous template and the new template share the same base Data template, there will be no loss of data when changing between presentation templates.

What else should I worry about?

In other posts, I will cover other areas needed for supporting continuous deployment with Sitecore:

• Deploying content changes that are required for transactional features (such as a shopping cart or login form).
• Writing sublayout code with conditional business logic
• Automated testing in the deployment pipeline
• Supporting toggling of features within a Sitecore solution.