Я уже говорил. Нет?
Единственный надежный (и более-менее быстрый) способ, который я знаю, это примерно так:
1. Остановка на время настроек/разработок
2. Копирование продуктива в DEV (можно с данными, можно без данных),
3. Создание в DEV новой структуры мандантов, взяв за исходный продуктивный мандант (потом надо будет его удалить)
4. Копируем DEV в Q&A, опять создаем новую структуру мандантов
5. Пересоздаем/проверяем транспортную систему
6. Начинаем жизнь с выровненными системами.

Если хочется сократить время, то можно сначала копировать PRD в Q&A, причесать получившееся, переделать ландшафт на двухсистемный.
Потом, когда дадут время на второй шаг, скопировать Q&A -> DEV, опять же причесать, и восстановить трехсистемный ландшафт.

P.S. ну а в общем - Склеротик абсолютно прав

а у меня возник только один вопрос - а при чем тут базис? Если РП как бы помягче выразиться.
С точки зрения базиса - да по барабану - подпись под бумажкой получил от РП - перенес - дальше его головная боль...

По существу вопроса - НЕ ТРОГАЙТЕ продуктив (в смысле загнать туда очередь запросов) - завалите. Вероятность черезчур велика. Полное функциональное тестирование вам проводить никто не будет. В принципе тащить попроектно из теста в прод - это довольно обычная практика. Особенно если несколько команд работает независимо. Проект оттестили - перенесли в прод - и начинается тест на проде - потому как разумеется ВСЕ! что запустили до этого никто опять не тестил.. Тут все от кооперации зависит и вопросы на уровне а какая сволочь пофигачила мою таблицу - показываем имя этой редиски - и посылаем в пеший эротический путь - ну то есть к РП. Надеюсь логирование в системах включено?

Если уж совсем полная задница - то как и советует avlag - выравнивание ландшафта.... Ну предупредив конечно что все, что не в проде - покинет мир живых....

Ну в общем достаточно обычная практика в долгоиграющих проектах с конгломератом кучки внедряющих команд.

Но еще раз - при чем тут базис

Ну как это причем? А кому все это расхлебывать?
Ну не РП же будет системы из небытия доставать?

avlag - а что конкретно базис будет расхлебывать? Неработающий функционал? С чего бы это...

Ну и так далее. В общем-то во всех транспортных проблемах всегда виноват базис, как я помню
И даже под подписку РП непрерывные переносы в произвольном порядке с подбором работающего варианта - тоже все ложится на базис.
А когда всё становится совсем грустно и принимается решение загрузить всю очередь в несколько тысяч транспортов? И чтобы к утру все поднялось?
А разгребание этого безобразия с объяснением, что вот здесь пришло с восьмеркой, но вот там этот отчет приехал нормально с показыванием версий?
А после всего этого бардака очередное решение о подъеме системы из бэкапа?
Смех-смехом, но РП себя крайним никогда не признает. И статус у него всегда будет выше статуса руководителя группы базиса.
Поэтому базису придется сидеть на работе. Когда все функционалы уже будут дома.

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

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

А когда всё становится совсем грустно и принимается решение загрузить всю очередь в несколько тысяч транспортов? И чтобы поднялось к утру все ?
нет комментарий - у меня такого не было:)

А разгребание этого безобразия с объяснением, что вот здесь пришло с восьмеркой, но вот там этот отчет приехал нормально с показыванием версий?

видим восьмерку - копипаст лога - и автору.

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

Итак дамы и господа о чем спич собсна... ИЗНАЧАЛЬНО не берите на себя ответственность за то как лягут запросы в систему. Базис не отвечает за последствия функцинальных переносов. И вот это самое главное что необходимо вбить в голову РП - пусть дрессирует своих функциональщиков и разработчиков. В данном конкретном случае - перенос запросов - базис выступает тупо попкой - кнопочку нажать. Ну по крайней мере в моей практике это всегда работало и минимум головной боли:) Помочь разработчикам почитать лог запроса - можем - найти где переносятся конкретные объекты можем - указать редиску - можем... ну как бы это наша работа... А вот отвечать за то, что спецы наваяли - вот это увольте - особенно если у них нет правил взаимодействия по разработкам....

2 Svetlana
Не будем ссориться
Я тоже всегда хочу жить правильно...
А во всех названных случаях ответственность базис не несет, да. Если, конечно правильно выстроена административная часть проекта. Но речь о другом - не важно чья вина в таких проектах, но чем больше бардака, тем больше работы базису. Вот, собственно, и вся проблема.

to avlag
а кто ссорится? тем более в пятницу утром

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

Кто бы возражал
Правда сейчас, особенно судя по вопросам в базисном разделе, немало проектов стартует вообще без собственного базисника. Причем не только со стороны клиента, но и со стороны консалта. О каких орг решениях может идти речь в таких случаях? (Оговорюсь, что речь, чаще всего, идет о не слишком больших проектах. Но все равно грустно становится).
Ладно, проехали... К топику уже явно никакого отношения. Да и к вечеру пятницы готовиться надо.

Alice86, столкнулся с одной интересной методикой выявления конфликтов между проектами разработки. Суть в следующем, начинаются проекты, в разработке создаются запросы Проект 1 и Проект 2. Когда нужно первый раз что-то перенести по Проекту 1, мы деблокируем соотвествующие задачи, но не делокируем сам запрос! Вместо этого содержимое деблокированных задач копируем в овывй запрос Проект 1 001 и его уже деблокируем и переносим.

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

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

Спасибо. Вообщем что-то подобное и планируем сделать до конца марта, сейчас пишем план работ, утверждаем его и вперед. Надеюсь все пройдет гладко.


Спасибо за совет. Мы давно думаем начать использовать ChaRM, и так и эдак крутим-вертим эту идею, читаем документацию, думаем как лучше применить у нас, пока все на что-то натыкаемся, что не дает в полной мере это внедрить. Но надо будет что -то делать, после того, как выровняем системы, иначе их постоянно придется выравнивать.

2 Svetlana У нас никто базис и не обвиняет, мы все работаем одной командой и функционал и базис, просто изначально было сделано много ошибок, сумбурно велся проект, не было такого вот опытного базисника, который бы настоял на том, что и как изначально должно быть сделано правильно, который бы предупредил РП о том, что будут проблемы и т.д. А теперь уже смысла нет искать виноватых, надо как-то решать проблему и решать ее на данном этапе должен уже базисник, а не функциональщик, как ни крути.

так и делаем, переносим только утвержденные запросы, предоставленные функциональщиком, а толку то? все равно ошибки в продуктиве возникают постоянные после переносов...уже слишком все запущено.

Попробую предложить еще 1 дополнение ко всем вышеперечисленным мерам. Только дополнение и только потому, что

Предлагается создать Z-отчет, на вход которому будет подаваться номер(а) транспортного запроса(ов). Отчет необходимо запускать перед переносом запроса в систему Q&A, он будет проверять для всех объектов запроса, есть ли эти объекты в запросах, перенесенных в Q&A, но не перенесенных в PRD.
Далее вывод отчета пересылается заказчику со стандартной текстовкой "бла-бла-бла могут возникнуть проблемы бла-бла-бла желательная последовательность действий бла-бла-бла ВЫ УВЕРЕНЫ ?!?"

Ну и сразу дисклаймер. Все равно с таким подходом, как описано у вас, это не избавит вас от дампов в продуктиве. Но должно немного сократить их количество (и, возможно, немного дисциплинирует ответственных со стороны заказчика).

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

В общем синтакс еррор - это наименьшее зло из всех возможных.

ЗЫ есть еще одно предложение - ввести четырехсистемный ландшафт - то есть дополнительное звено в тестировании - между Q и продуктивом.... и вот оттуда - только строго в том порядке как туда. Сделать сценарии комплексного тестирования и их полностью прогонять. Если заказчик деньгами бьет по каждому дампу - это действо может иметь большой смысл.

Очень интересная тема. Сейчас также ищу решение проблемы с непоследовательным переносом транспортов...

Подскажите пожалуйста, есть ли какая-либо возможность "вклиниться" в процесс добавления объекта в транспорт, например: user-exit или др, с целью запретить добавление объекта который на мой взгляд не может быть изменен (включен в запрос) потому что он не достиг продуктива.

Второй вопрос: можно ли узнать достиг транспорт целевой системы без визуального просмотра лога переносов ? если ли такая информация в каких-то таблицах ?

Третий вопрос: можно ли использовать атрибуты запроса/задачи для привязки нескольких транспортов к определенной заявке (запросу бизнеса на добавление/изменение некой функциональности) ?

Еси на поставленные вопросы будут ответы, тогда можно реализовать проверку, перед добавлением объекта в транспорт. Если добавляемый объект находиться в транспортах которые не достигли продуктива, то запретить его изменение. А также "пакетный" перенос всех транспортов по определнной заявке.