Was ist der Workflow für SDL Tridion-Komponenten und Seitenvorlagen?

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

Für Produktion / UAT / QA, NO.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 für 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 startet.

Hoffe, das hilft.

Dies ist eine Legacy-Funktionalität, die mit nicht zusammengesetzten VB-Vorlagen verwendet werden konnte, bevor zusammengesetzte Vorlagen in Tridion Version 5.3 auf den Markt kamen. 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 per Workflow steuern.

Soweit ich weiß, funktionieren die Workflow-Prozesse für Vorlagen wie Sie vorschlagen. Bei der letzten Überprüfung (in der Version 2009) wurde der Status Minimal Level of Approval bei der Veröffentlichung von Elementen nicht berücksichtigt. 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, haben modulare Vorlagen TBBs ausgiebig genutzt, und als solche denke ich, dass diese Funktion übersehen wurde. Wenn das TBB-Problem und das Minimal Level of Approval -Problem behoben wurden, könnten Sie einige sehr interessante Freigabeszenarien für das Starten von neu gestalteten Websites erstellen.

Wie von anderen vorgeschlagen, sollten Sie bei der Freigabe von Vorlagen auf DTAP-Umgebungen (Development-Test-Acceptance-Production) zurückgreifen. Die Komplexität dieser Einrichtung hängt von Ihren spezifischen Anforderungen ab.

Die Verwendung von Arbeitsabläufen für Entwicklungsarbeiten ist höchstwahrscheinlich 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 eine Änderung festlegt, besteht er meistens aus mehreren Assets, von denen jeder einzeln 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 Workflow 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 zusätzlicher Schritte 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.