Вот такой вопросец возник, кто что думает.

Скажем пишет разработчик какойто серъёзный отчет. Отчет явно состоит не из одного модуля - в нём куча инклудов(скажем описание переменных, описание ALV, какихто классов и так далее). В процессе разработки ясное дело отчет меняется, правится, чтото добавляется - и все это в промежутках между переносами до тестовой системы. Проще говоря - написали и перенесли в тест, нашли ошибку, исправили, перенесли в тест, и так далее до 100%но нужного результата.

Вопрос вот в чем - не будет ли "криминалом", если разработчик, в последствии, не будет предлагать админу перенести кучу запросов, а откроет один запрос и включит в него все объекты этого отчета, и в продуктив полетит этот вот один запрос ?

Спасибо.

ИМХО - все зависит от политики компании
у меня на предыдущей - тянули всю цепочку
на нынешней - один

Думаю ничего криминального нет.
Все определяется вашей спецификой.

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

На моём бы месте врятли бы ктото понял больше чем я.
А я ничего не понял.

Про "политику" и "специфику" - это все ясно.

Вопрос чисто наверное технический - впринципе, на кой черт тащить все 27 (или 96 - всякое ведь бывает ) запросов ?

Что касается - а если потом ктото будет чтото править - ну тогда будем решать проблемы по мере их поступления.

Вопрос и был каким боком это может вылезти потом.

Ладно. Пойдем длинным путем... Привези мне, батюшка, цвето... Тьфу.

1. При неполном переносе транспортов (когда "ненужные" транспорты не переносятся или в тест или в продуктив) часто возникает ситуация с разбежавшимися в системах репозитариями. Что сильно мешает, например, при копировании мандантов между системами.
2. Транспортная система придумана для того, чтобы через нее проходили все транспортные запросы. При этом, если путем сложных настроек и переделок, в тестовой системе получена работоспособная конфигурация, при переносе всех этих же транспортов в продуктив - там все тоже скорее всего заработает.
В случае выкидывания "ненужных" транспортов легко получить ситуацию, когда в разработке и в тесте все отлично - а вот с продуктивом бяда.
3. А если нет 100% гарантии, что в неперенесенные транспорты не попали сторонние объекты, что у разработчиков бывает сплошь и рядом, - то вообще все интересно может приключиться.

Чет действительно очень длинно. Да и очевидно вобщемто.

Никто ничего и никуда не выкидывает.

1. В тесте - отчет работает.
2. В деве открыли транспорт - и 1000 и 1 раз всё проверив - включили в него все объекты отчета. Программы, инклуды, домены, таблицы, структуры, вью и так далее. По-простому - дабл-клик по всем объектам и ctrl+s. Всё. Получили куммулятивный запрос.
Это назвали релизом. Дальше - как обычно. Все измнения-дополнения отдельными транспортами.

Вот и все.

Вобщемто ответ получен - никакого особо "криминала" не случится.

Криминал случится если в продуктиве этот отчет не заработает или заработает не так.

Вот не надо "ля-ля". Таким вопросом может озадачиваься только слабый базис.
Тут уже как-то обсуждали, что разработка 90% творчества и 10% ответственности, а у базиса наоборот. Здесь вопрос только в правильной организации, доверии и ответственности разработчика за свою работу.

Вообще сваливать работу всю в итоговый запрос, уплотнить его и задокументировать это - считаю хорошим тоном.

Но...
Бывает такая ситуация, что въезжает "красный" запрос, потом его правит другой запрос. И эти запросы сливать нельзя. И эти "танцы с бубнами" повторяются при каждом переносе в новую систему. И ситуация не разруливается. Вот тут уже начинается творчество. И административно такие вопросы не решаются.

2 ManOwaR - у вас до сих пор действует эта глюпая бюрократическая система работы с запросами?

Аргумент, извините, совершенно бестолковый.

Ибо отчет может не заработать в продуктиве и при переносе по-запросно, без создания куммулятивного - ну например из этой кучи из 20 запросов "забыли" 17ый. Или вообще, скажем домены или структуры, или классы, да малоли что еще, были определены другим разработчиком, а он еще ничего не переносил.

Коллеги - вы не на тот вопрос отвечаете. Я не спрашивал что будет, если я не донесу какието объекты разработки(отчета) - а это можешь случиться и в случае "паровоза" и в случае одного запроса - очевидно, что отчет работать не будет, или будет работать неверно.

Вопрос был скорее на тему "реально удобно это или нет" - создавать куммулятивный запрос. Впринципе этот запрос будет жить во всех системах. Все промежуточные только в деве и тесте. В продуктиве - релиз.

C точки зрения админа - "удобнее" кумулятивный запрос, поскольку при этом "парится" абапер, собирая запрос,
а с точки зрения абапера - "удобнее" нести очередь из запросов, так как в этом случае "парится" админ, собирая ее...
Вот такая вот диалектика! А по затратам времени - выигрыша нет.

ребята это все здорово конечно - до одного момента.
Обычная ситуация - в процессе работы переносим прод в тест - догнать разницу запросов между тестом и продом на текущий момент времени - поскольку они естественным образом расходятся. И что несчастному базису в этом случае делать?????????? Как выравнивать????

Форварднуть недонесенные в продуктив запросы, обратно в тестовую - всего-то делов. И пачкой импортировать

а какие? Я должна разбирацца какие из них коммулятивные???????? на фик мне это все нужно? А недонесенных ты представляешь сколько? все между прочим отдельные - и что в итоге получицца?:)

короче - я лично категорически против коммулятивныв запросов - это дополнительная головная боль базиснику при этих операциях. А практического смысла в этом действе нет.

2Egal - процент ошибки админа по поводу "забыли" перенести вообще-то ничтожно мал - по сравнению с тем, что очередную сборку - без дополнительного тестирования - нести в продуктив.

Бывают конечно моменты когда нужно сделать сборку - и от этого всем легче дышать становится - но как обычную практику использовать...