What is a workflow for SDL Tridion Component and page templates?

Question

I noticed in both SDL Tridion 2009 and 2011 that there is a field on the workflow tab of the publish dialog box for the process of related page templates and the process of related components.

Does this mean that template / code changes can be made in production and released during the workflow? Is this a good practice? If so, why are they unrelated to the process pooling process for template blocks?

Answer 1

The purpose of this is not used in Production, but you can use it at the development stage. I see that this feature is useful for the code / template design verification process, when a developer develops templates and a workflow, and then Team Lead reviews it and approves / rejects the changes.

For production / UAT / QA, NO.NO.NO. (just want to emphasize this is quite difficult :)), this is not a good practice IMHO. You must go through the change management process by exporting / importing the portter port package, typical of DTAP.

Why is there no workflow on TBB? TBBs will be part of CT / PT anyway, so when you view CT / PT, they are explicitly included in the review. However, I see that there may be times when you are just updating TBB and the workflow does not start.

Hope this helps.

Answer 2

This is legacy functionality that could be used with non-composite VB templates before compound templates were included in Tridion version 5.3. However, today this will not be very useful, since TBBs will not be included in the workflow, so all you can control through the workflow is the page / component template, but not the TBB inside.

Answer 3

As far as I know, workflow processes for templates work as you suggest. However, the last time I checked (in the 2009 version), the status of the Minimal Level of Approval not respected when publishing the elements. Unfortunately, this means that your template changes will always be available to all targets when someone publishes. Because of this, I would always recommend making template changes in the development environment, rather than in the production environment, and controlling the release of templates using Content Porter.

Your point of view on TBB is good - since R5.3, modular templates made extensive use of TBB, and therefore I think this feature may have been missed. If the TBB problem and the Minimal Level of Approval problem were fixed, you could create very interesting release scripts to launch new sites.

Answer 4

Like others, your template release approach should use a development-testing-adoption (DTAP) environment. The complexity of this setting will depend on your specific requirements.

Using a workflow for development is more than likely. Much depends on where different developers integrate their work. If you have multiple DEV environments, each individual developer is unlikely to want to work on their own system. Assuming that you are integrating on one of the DEV machines or, possibly, in TEST, you also do not need a workflow, because when a developer makes a change, it will consist mainly of several assets, each of which will have to go through the workflow separately , with some parts of the change visible to others while this happened, while others did not. If all your developers work on the same server, then these aspects of the workflow will be even more painful.

The workflow is mainly useful for managing the release of individual unrelated assets one at a time. Typical development work is not like that, and frankly, the number of extra steps would be just overhead and would not eliminate the need for normal development disciplines. As Kiridzh notes, people do not. I have not seen this either, and I am very happy to say that.