Покопался в САПе ...

Такой возможности нет, но ... есть вариант ведения накопительного транспорта, содержащего все измененные ранее объекты. В этом случае после деблокирования каждого транспорта надо будет создавать новый в который переносить все ссылки из деблокированного. После копирования ссылок на объекты, надо наложить блокировки в транспорте. Этот транспорт будет использоваться для новых изменений, а после его деблокирования создаеться следующий накопительный и т.д. циклично. Недостатки: после успешного тестирования надо будет или удалять последний транспорт в котором не будет новых изменений, или именно его отправлять на продуктив. Еще одним недостатком являеться то что не все объекты могут быть блокированы, например: настройки в таблицах. Значит риск одновременной правки настройки в разных транспортах остаеться.
Еще один из способов это выполнять проверку до деблокирования, в расширении CTS_*REQUEST_CHECK. На мой взгляд самое эффективное решение, но запоздалое, так как объект будет уже изменен.


Конкретного места хранения этих данных не нашел, но есть расширение CTS_IMPORT_FEEDBACK (FEEDBACK_AFTER_IMPORT) которое согласно документации вызываеться после импорта транспорта в целевую систему, значит можно реализовать отметку через пользовательскую таблицу


В настройках можно добавить пользовательские атрибуты для транспорта. Тогда в каждом транспорте указывать напримр номер заявки на изменения, группируя несколько транспортов.
Еще одним способом группирования можно считать использование функциональности Проектов, но я не уверен что ее можно применять для небольших разработок объемом в несколько транспортов

Cлучайно наткнулся на эту тему.
На мой взгляд единственное достаточно надежное решение проблемы с зависимостью между запросами - это четырехсистемный ландшафт, который предложила Svetlana. Остальное - это хорошие меры для снижения проблем, но не для их устранения.
Ситуация достаточно жизненная и я регулярно с ней сталкивался, но вот только никогда не видел четырехсистемного ландшафта.
Соответственно вопрос к коллегам - использует ли кто-нибудь в жизни (а не теоретически) такой подход?

4-х системный ландшафт есть у нас: DEV-QAS-PRE-PRD
Схема начала себя оправдывать с момента начала использования ChaRM и запуска нескольких проектов.
Т.к. ChaRM генерит Generated test requests, которые фактически являются Transport of copies недеблокированных запросов,
и все это автоматически импортируется в QAS в порядке отправки Normal Change разработчиками в тест, т.е. почти рандомно.
После перевода NC в статус Successfully tested запрос фактически деблокируется и автоматом импортируется в PRE (pre-production).
Если при импорте в PRE возникают ошибки, лог отправляется автору и все ждут корректирующего запроса.
Если ошибок импорта нет, ежедневно проводится мини тест на отсутствие ошибок в основных процессах.
После успешного теста вся пачка запросов массово импортируется в PRD. Ошибок при импорте в продуктив не было ни разу.
Если есть вопросы, задавайте.

Ludens, спасибо за детальный рассказ!
То есть ChaRM себя полностью оправдал? Проекты не жалуются?

Transport of copies в QAS выполняется чтобы объекты оставались заблокированными в запросах в DEV?
А после transport of copies в QAS объекты в DEV могут меняться самим разработчиком?
То есть как обеспечивается, что в QAS тестируется ровно то, что потом уедет в PRE и PRD?

Или я не до конца понял схему?

От чарма в восторге только change manager и PM, все остальные на него матерятся.
Но свою задачу он выполняет, хотя интерфейс ужасен, настройки не гибкие, если что надо поменять, обязательно что нибудь завалится и нужно подключать саппорт.

> Transport of copies в QAS выполняется чтобы объекты оставались заблокированными в запросах в DEV?
> А после transport of copies в QAS объекты в DEV могут меняться самим разработчиком?
> То есть как обеспечивается, что в QAS тестируется ровно то, что потом уедет в PRE и PRD?

По этим вопросам рекомендую прослушать EGI-семинары по чарму, если есть Enterprise Support, то они бесплатные.

Вкратце один эпизодов использования:
- инициатор изменения создает Change Request
- менеджер по изменениям согласует CR, аппрувит его, назначает разработчика/тестера, создает Normal Change
- разработчик заходит в NC, переводит его в статус In development, создает из NC запрос
- как только разработчик сохранил свою работу в запрос, он деблокирует задачу, затем переводит NC в статус To be tested
- из запроса создается ToC и деблокируется, затем автоматически импортируется в QAS
- тестер тестит в тесте, если все ок, заходит в NC и ставит статус Tested successfully, тогда система автоматически деблокирует оригинальный запрос и импортирует его в QAS и дальше в PRE.
- если тест не прошел, тестер заходит в NC и выполняет Return to development, теперь NC снова в состоянии In development
- разработчик из NC создает к запросу новую задачу и продолжает работу

Эта схема приводит к тому, что в QAS'е находится куча изменений, как по завершенным разработкам, так и по продолжающимся.
Логично возникает необходимость в препродуктивной системе, где будет тестироваться ровно тот комплект запросов, который потом переедет в продуктив.

Ludens, спасибо!
То есть, имхо, судя по вашему описанию, просто четырехсистемный ландшафт и получше будет, чем ChaRM
По ChaRMу доки почитаю.
И вот всё таки вот этот момент не раскрыт -

Вот как тут гарантируется, что в момент деблокирования оригинального запроса из DEVа,
в нем разработчик что-нибудь не поправил, по простоте душевной, например, уже после того, как сделал ToC ?
Но я думаю, что как-нибудь гарантируется, вряд ли здесь дыра...

Гарантируется так:
напрямую в системе у разработчика нет прав на создание запросов и задач, только через веб-интерфейс чарма.

Чтобы отправить NC на тестирование, нужно деблокировать все задачи, иначе не даст.
Чтобы создать еще одну задачу в запросе, нужно вернуть NC в разработку.

ИМХО.
Вопрос не технический а организационный.
Вам надо не у базисников помощи искать, а у своего руководителя проекта.

А как эту проблему можно решить организационно? Не прибегая при этом к массовым переносам?

Я соглашусь, что частично проблема может решиться организационными мерами, но никакой гарантии они не дадут.
И даже 90 процентов, имхо, не дадут. А это уже достаточно существенный риск...

Проблема в том, что заказчик очень медленно тестирует и транспортные запросы (иногда по 100 штук) зависают в системе проверки качества и в следствии чего, возникают проблемы зависимости транспортных запросов друг от друга при переносе изменений в продуктив.

По моему мнению, самая что ни есть организационная проблема.

да, соглашусь, в случае топикстартера вы правы.
Но если говорить про общий случай, то не всегда возможно решить проблемы с переносом в продуктив только оргмерами.

* Мрачным голосом и с соответствующей ухмылкой.
А если переносить транспорты из середины очереди и/или в произвольном порядке, то проблемы будут всегда.

[quote="avlag"][/quote]
и чего только не придумают, чтоб как-нибудь без базиса обойтись

Не согласен.
Должен быть документ, регламентирующий работу на уровне управления изменениями/версиями/конфигурациями. (я не особо сильный ITIL-щик).
И если требования этого документа будут выполняться - то это и будет решение всех проблем с переносом организационными мерами.

Можно согласиться. Например, оргмерами, можно вообще запретить переносы. Делать их раз в год после тестирования двухмесячного.
Можно сделать такую процедуру, что десять раз подумаешь до создания запроса.
Но если идет несколько параллельных разработок в сжатые сроки, то в рамках трехсистемного ландшафта я не знаю, как помогут оргмеры.
Риски останутся. Если кому-то известен обратный практический пример - будет интересно послушать.

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

На мой взгляд, идеальная схема - тестирование в Q, потом подтверждение, что тестирование окончено, потом перенос разработки в препродуктивную систему, формирование корректной очереди переноса (корректирующие транспорты), потом перенос в PRD. Это схема ChaRM, которую описал Ludens.
Ее можно оргмерами сделать и безо всякого ChaRMа.