¿Para qué se utiliza el flujo de trabajo en SDL Tridion Component and Page Templates?

Question

He notado tanto en SDL Tridion 2009 como en 2011 que en la pestaña de flujo de trabajo del Diálogo de publicación hay un campo para Proceso de plantilla de página asociada y Proceso de plantilla de componente asociado.

¿Esto implica que los cambios de plantilla/código pueden realizarse en producción y liberarse a través de un proceso de flujo de trabajo? ¿Es esta una buena practica? Si ese es el caso, ¿por qué su asociación al proceso de flujo de trabajo no es para los Building Blocks de la plantilla?

Answer 1

La intención de esto no se usa en producción, pero puede usarlo durante su fase de desarrollo. Veo que esta característica es beneficiosa para el proceso de revisión del diseño del Código/Plantilla donde el desarrollador desarrolla las plantillas y el inicio del flujo de trabajo, luego Team Lead lo revisa y aprueba/rechaza los cambios.

Para producción/UAT/QA, NO.NO.NO. (Sólo quiero enfatizar esto lo suficientemente fuerte :)) no es una buena práctica en mi humilde opinión. Debería pasar por el proceso de administración de cambios utilizando exportar/importar el paquete portador de contenido, DTAP típico.

¿Por qué no hay flujo de trabajo en los TBB? Los TBB formarán parte de CT/PT de todos modos, de modo que cuando revisa CT/PT se incluyen explícitamente en la revisión. Sin embargo, veo su punto de que podría haber casos en los que simplemente actualice el TBB y no se inicie ningún flujo de trabajo.

Espero que esto ayude.

Answer 2

Esta es una funcionalidad heredada que podría haberse utilizado con plantillas VB no compuestas antes de que aparecieran las plantillas compuestas en la versión 5.3 de Tridion. Sin embargo, hoy esto no será de mucha utilidad ya que los TBB no se incluirán en el flujo de trabajo, por lo que todo lo que puede controlar a través del flujo de trabajo es la pieza de plantilla de página/componente, pero no los TBB dentro.

Answer 3

Hasta donde yo sé, los procesos de flujo de trabajo para las plantillas funcionan como usted sugiere. Sin embargo, la última vez que revisé (en la versión de 2009), el estado Minimal Level of Approval no se respetó al publicar elementos. Lamentablemente, esto significa que los cambios de plantilla siempre estarán disponibles de inmediato para todos los objetivos cuando alguien publique. Debido a esto, siempre recomendaría hacer cambios de plantilla en un entorno de Desarrollo en lugar de un entorno de Producción, y administrar el lanzamiento de plantillas usando Content Porter.

Su punto en TBB es bueno: desde R5.3, las plantillas modulares han utilizado ampliamente TBB, y como tal, creo que esta característica puede haber sido pasada por alto. Si se corrigieron el problema TBB y el problema Minimal Level of Approval, podría crear algunos escenarios de lanzamiento muy interesantes para lanzar sitios recientemente diseñados.

Answer 4

Como otros han sugerido, su enfoque para liberar plantillas debería hacer uso de entornos de Desarrollo-Prueba-Aceptación-Producción (DTAP). La complejidad de esta configuración dependerá de sus requisitos específicos.

Usar el flujo de trabajo para el trabajo de desarrollo es más que probable que no sea útil. Mucho depende de donde los diferentes desarrolladores integren su trabajo. Si tiene múltiples entornos DEV, entonces es poco probable que cada desarrollador individual desee un flujo de trabajo en su propio sistema. Suponiendo que se integre en una de las máquinas DEV, o tal vez en TEST, tampoco querrá flujo de trabajo allí, ya que cuando un desarrollador realiza un cambio, consistirá principalmente en varios activos, cada uno de los cuales debería pasar por flujo de trabajo por separado. , con algunas partes del cambio visibles para otros mientras esto sucedía, y otras no. Si todos sus desarrolladores trabajan en el mismo servidor, estos aspectos del flujo de trabajo afectarán aún más.

El flujo de trabajo es principalmente útil para gestionar las liberaciones de activos individuales no relacionados de a uno por vez.El típico trabajo de desarrollo no es así, y francamente la cantidad de pasos adicionales sería solo por encima, y ​​no eliminaría la necesidad de las disciplinas normales de desarrollo. Como señala Quirijn, las personas no hacen esto. Yo tampoco lo he visto nunca, y estoy muy feliz de poder decir eso.