Собственно, не в первой системе наблюдается одна и таже беда - когда sap постепенно превращается в z-sap, появляются сложные взаимосвязи между компонентами абап-разработок (ФМы, инклуды, экситы и т.п) и объектами словаря данных. Например, ведётся ряд активных доработок смежными группами абаперов по несмежным вродебы проектам. Всё копится в тестовой системе (либо в квалити, если тестовая кривая настолько что протестировать адекватно не на чем). Потом одна группа "поехали в продуктив" - приехали, оказалось что структурка которую потащили с ФМом, содержит z-поля с z-типом, который придумала другая команда, и в наши запросы оно не вошло. Результат понятный - счастливые лица пользователей в продуктиве.

Вопрос: а из штатных инструментов коробки возможен ли глубокий анализ зависимостей между компонентами, входящими в запрос, и компонентами этих компонентов. Т.е. в общем случае - какойто рекурсивный обход всех Z-объектов словаря (особенно структурых), и всех инклудов в программмном блоке, который хотябы одним кусочком вошёл в наш запрос (а в идеале, если это класс или ФМ, то анализ ещё и на точки их вызова должен распространятся), и анализ "перенесён ли уже этот компонент в целевую систему" ? Т.е. чтобы не получить по приезду в пункт Б не получить рассыпавшиеся словарные структуры или группы функций.

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

Первым позывом было сказать про аббревиатуру CVS. А потом какая-то NWDI еще обозначилась.

Вы хотите еще одной Z-программкой решить организационный бардак?

У меня есть давнишняя мечта...
Хоть на одном проекте сделать так, чтобы ни у кого из консультантов/разработчиков не было полномочий на создание/удаление/деблокирование/перенос транспортов.
И чтобы этим занимался отдельный человек.
И чтобы каждый транспорт был объяснен зачем.
И чтобы - одна настроечная задача - один запрос на перенос.
И чтобы ни один запрос не был удален по дороге.
И чтобы в каком порядке они легли в очередь на импорт, в таком и импортировались. И никаких импортов из середины очереди.

Поверьте, такой ландшафт будет жить десятилетиями без необходимости выравнивания. И без описанного геморроя.

Но... Мечты, мечты...

желательно в Solution Documentation с помощью

Ну мы же не рассматриваем сферический сап в вакууме.

Просто под каждый из таких "проектов" держать отдельную тестовую систему - нереально. А как не имея "чистой" копии продуктива промоделировать 100%-надёжно перенос одного отдельного проекта на продуктив так, чтобы не трогать остальные?

организационно запретить перенос в продуктив без тестов в тестовой системе

мы пользуемся тулзой Transport Express

она написана на базе STMS (плюс еще фенечки), но думает немного когда переносит запросы - говорит где конфликты, если обьект где более старшей версии и так далее. довольно неплохо ведет логирование, от всех бед не спасает (от криворуких индусов попробуй спастись;) и очень нервная - орет иногда без причны, но и помогает тоже

написана одной фирмой, я думаю такое можно сотворить и самим при желании, но купить проще конечно

дев->тест у нас настроен автоматический импорт, в тесте все аккумулируется месяц где-то и тестируется ручками, тест->препродакшн - переносится контролируемо целым релизом и тестируется автоматическим пакетом, в продакш - оттестированным релизом

К автоимпорту ещё бы и автоsend лога на email прикрутить....- может завалялось у кого решеньице?
автопроброс из внешнего TMS нашёл - RSTMSTIQ зафонить

Попробуйте воспользоваться моей прогой
http://sapboard.ru/forum/viewtopic.php?f=13&t=90603
"Глубокий анализ" она делать не позволяет, но отследить цепочку версий и изменений в них по всем объектам из запроса она помогает, может оказаться полезным инструментом