Wofür wird der Workflow für SDL Tridion-Komponenten und Seitenvorlagen verwendet?

Question

Ich habe in SDL Tridion 2009 und 2011 festgestellt, dass auf der Registerkarte Workflow des Dialogfelds Publikation ein Feld für Associated Page Template Process und Associated Component Template Process vorhanden ist.

Bedeutet dies, dass Vorlagen-/Codeänderungen in der Produktion vorgenommen und über einen Workflowprozess freigegeben werden können? Ist das eine gute Übung? Wenn das der Fall ist, warum ist ihre keine Workflow-Prozess-Zuordnung für Template-Building-Blocks?

Answer 1

Die Absicht davon ist nicht in der Produktion zu verwenden, aber Sie könnten es während Ihrer Entwicklungsphase verwenden. Ich sehe diese Funktion als vorteilhaft für den Code-/Template-Design-Review-Prozess, bei dem der Entwickler die Templates entwickelt und der Workflow startet, dann überprüft Team Lead ihn und genehmigt/lehnt die Änderungen ab.

Für Produktion/UAT/QA, NO.NO. (will nur das hart genug betonen :)) es ist keine gute Praxis IMHO. Sie sollten den Änderungsverwaltungsprozess mit dem Inhaltsporterpaket-Export/-Import (typisches DTAP) durchlaufen.

Warum gibt es keinen Workflow auf TBBs? TBBs werden sowieso Teil von CT/PT sein, wenn Sie also CT/PT überprüfen, werden sie explizit in die Überprüfung einbezogen. Ich sehe jedoch, dass es Fälle geben kann, in denen Sie nur die TBB aktualisieren und kein Workflow beginnt.

Hoffe, das hilft.

Answer 2

Dies ist eine Legacy-Funktionalität, die mit nicht zusammengesetzten VB-Vorlagen verwendet werden konnte, bevor zusammengesetzte Vorlagen in Tridion Version 5.3 bereitgestellt wurden. Dies wird jedoch heute nicht viel nutzen, da TBBs nicht in den Workflow einbezogen werden. Sie können also nur den Seiten-/Komponentenschablonenabschnitt, nicht aber die darin enthaltenen TBBs über den Workflow steuern.

Answer 3

Soweit ich weiß, funktionieren die Workflow-Prozesse für Vorlagen wie Sie vorschlagen. Beim letzten Mal, als ich nachgesehen habe (in der Version von 2009), wurde der Minimal Level of Approval Status beim Veröffentlichen von Artikeln nicht beachtet. Leider bedeutet dies, dass Ihre Vorlagenänderungen für alle Ziele immer sofort verfügbar sind, wenn jemand veröffentlicht. Aus diesem Grund würde ich immer empfehlen, Vorlagenänderungen in einer Entwicklungsumgebung anstelle einer Produktionsumgebung vorzunehmen und die Veröffentlichung von Vorlagen mithilfe des Inhaltsporters zu verwalten.

Ihr Punkt auf TBBs ist ein guter - seit R5.3, modulare Vorlagen haben umfangreiche TBBs verwendet, und als solche denke ich, dass diese Funktion möglicherweise übersehen wurde. Wenn das TBB-Problem und das Problem Minimal Level of Approval behoben wurden, könnten Sie einige sehr interessante Freigabeszenarien für das Starten von neu gestalteten Websites erstellen.

Answer 4

Wie von anderen vorgeschlagen, sollte Ihr Ansatz zur Veröffentlichung von Vorlagen DTAP-Umgebungen (Development-Test-Acceptance-Production) verwenden. Die Komplexität dieser Einrichtung hängt von Ihren spezifischen Anforderungen ab.

Die Verwendung von Arbeitsabläufen für Entwicklungsarbeiten ist mehr als wahrscheinlich nicht hilfreich. Viel hängt davon ab, wo die verschiedenen Entwickler ihre Arbeit integrieren. Wenn Sie mehrere DEV-Umgebungen haben, ist es unwahrscheinlich, dass jeder einzelne Entwickler einen Workflow auf seinem eigenen System benötigt. Angenommen, Sie integrieren sich auf einer der DEV-Maschinen oder vielleicht auf TEST, dann werden Sie auch keinen Workflow benötigen. Wenn ein Entwickler Änderungen vornimmt, besteht er meist aus mehreren Assets, von denen jeder separat durch den Workflow gehen muss , während einige Teile der Veränderung für andere sichtbar waren und andere nicht. Wenn alle Ihre Entwickler auf demselben Server arbeiten, werden diese Aspekte des Workflows noch mehr schmerzen.

Der Arbeitsablauf ist hauptsächlich nützlich, um Releases einzelner nicht verwandter Assets einzeln zu verwalten.Die typische Entwicklungsarbeit ist nicht so, und ehrlich gesagt wäre die Menge an zusätzlichen Schritten nur ein Overhead und würde die Notwendigkeit für normale Entwicklungsdisziplinen nicht beseitigen. Wie Quirijn bemerkt, machen die Leute das nicht. Ich habe es auch nie gesehen, und ich bin sehr froh, das zu sagen.