Что такое рабочий процесс для шаблонов компонентов и шаблонов SDL Tridion?

Question

Я заметил в обоих SDL Tridion 2009 и 2011, что на вкладке рабочего процесса диалогового окна публикации есть поле для процесса связанных шаблонов страниц и процесса связанных компонентов.

Означает ли это, что изменения шаблона/кода могут быть сделаны на производстве и выпущены через процесс документооборота? Это хорошая практика? Если это так, почему они не связаны с процессом процесса создания шаблонов для блоков шаблонов?

Answer 1

Целью этого не является использование в Production, но вы можете использовать его на этапе разработки. Я вижу, что эта функция полезна для процесса проверки дизайна кода/шаблона, когда разработчик разрабатывает шаблоны и рабочий процесс, а затем руководитель группы просматривает его и одобряет/отклоняет изменения.

Для производства/UAT/QA, NO.NO.NO. (просто хочу подчеркнуть это достаточно сложно :)), это не хорошая практика ИМХО. Вы должны пройти процесс управления изменениями с помощью экспорта/импорта пакета portter port, типичного DTAP.

Почему нет рабочих процессов на TBB? TBBs будут частью CT/PT в любом случае, поэтому, когда вы просматриваете CT/PT, они явно включены в обзор. Тем не менее, я вижу, что могут быть случаи, когда вы просто обновляете TBB, а рабочий процесс не запускается.

Надеюсь, это поможет.

Answer 2

Это устаревшая функциональность, которая могла использоваться с не-составными шаблонами VB до того, как составные шаблоны вошли в Tridion версии 5.3. Однако сегодня это будет не очень полезно, поскольку TBB не будут включены в рабочий процесс, поэтому все, что вы можете контролировать через рабочий процесс, это шаблон страницы/компонента, но не TBB внутри.

Answer 3

Насколько я знаю, процессы рабочего процесса для шаблонов работают так, как вы предлагаете. Однако в прошлый раз, когда я проверил (в версии 2009 года), статус Minimal Level of Approval не соблюдался при публикации элементов. К сожалению, это означает, что ваши изменения шаблона всегда будут доступны всем целям, когда кто-то издает. Из-за этого я всегда рекомендовал бы делать изменения шаблонов в среде разработки, а не в производственной среде, и управлять выпуском шаблонов с помощью Content Porter.

Ваша точка зрения на TBB является хорошей - поскольку R5.3, модульные шаблоны широко использовали TBB, и поэтому я думаю, что эта функция, возможно, была упущена. Если проблема TBB и проблема Minimal Level of Approval были исправлены, вы могли бы создать несколько очень интересных сценариев выпуска для запуска новых сайтов.

Answer 4

Как и другие, ваш подход к выпуску шаблонов должен использовать среды разработки-тестирования-принятия (DTAP). Сложность этой настройки будет зависеть от ваших конкретных требований.

Использование рабочего процесса для работы над разработкой более чем вероятно бесполезно. Многое зависит от того, где разные разработчики интегрируют свою работу. Если у вас несколько сред DEV, каждый отдельный разработчик вряд ли захочет работать в своей собственной системе. Предполагая, что вы интегрируетесь на одном из DEV-машин или, возможно, в TEST, вам также не нужен рабочий процесс, поскольку, когда разработчик совершает изменение, он будет состоять в основном из нескольких активов, каждый из которых должен будет проходить рабочий процесс отдельно , с некоторыми частями изменения, видимыми для других, пока это произошло, а другие нет. Если все ваши разработчики работают на одном сервере, то эти аспекты рабочего процесса будут еще больнее.

Рабочий процесс в основном полезен для управления выпуском отдельных несвязанных активов по одному.Типичная работа по разработке не такая, и, честно говоря, количество дополнительных шагов было бы просто накладными расходами и не устраняло бы необходимости в нормальных дисциплинах развития. Как отмечает Кириджн, люди этого не делают. Я тоже этого не видел, и я очень счастлив это сказать.