система должна лежать....

мда...
при фразе "нам тут разработочку бы загрузить с другого проекта.." руки както сами тянутся к топору...

Неужели это так сложно сделать?

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

К сожалению загрузить чужую разработку несложно. Очень сложно потом бывает разгрести то, что получилось в результате.
Уточняю: если не заработает эта разработка - фигня. Но может прилечь то, что работало до этого. Откат транспорта - это восстановление системы из бэкапа.

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

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

ЗЫ Иногда мне кажется, что базисники преувеличивают серьезность, важность и последствия простых, можно сказать повседневных, задач, ИМО.

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

Как говорится "достаточно одного раза". Особенно если это произойдёт в неподходящее время, а особенно, если не будет своевременно обнаружен.

В 90% случаев тестирование разработки проходит в системе Q&A. В разработке для этого просто нет данных.

Это зона ответственности не разработчика, а ПМ'а. А если ПМ видит, что по какой-то из причин, идет несколько дней простоя команды, то будет принято решение восстановиться из бэкапа. Что станет зоной ответственности базисника.

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

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

Это ни в коем случае не является повседневной задачей. Да, технически это не сложно. Но это никаким образом не является стандартной задачей.

А не видели, как можно раскорячить систему при одинаковых SID'ах у исходной и у целевой систем при импорте транспортов? А как быть, если в транспорте лежат измененные стандартные объекты? А если при этом еще и версии компонентов были разные?
Поймите, зона ответственности разработчика заканчивается на его разработке. А вот работоспособность всей системы - это ни разу не его зона ответственности. Попробуете догадаться, кто будет крайним, если после импорта транспорта легла вся система? А ведь может быть и более плохой вариант Когда система работает, но что что-то не так выясняется через пару-другую недель интенсивной работы команды. Со словами: "Я это уже месяц назад настроил, и все работало!"
При стандартной настройке параметром rec/client ведутся логи настроек. И можно много чего выяснить, если настройки сменились. При импорте внешнего транспорта - это проблематичнее.
И во всех случаях базисник получает неслабый геморрой и дополнительную работу. Часто ночную. А заканчивается все восстановлением из бэкапа.
Что, все эти работы оплатит разработчик, который притащил злосчастный транспорт?

Я понимаю Вашу точку зрения, но первые три пункта у меня вызывают недоумение.
1. В Вашем ландшафте разработчики "вслепую" пишут? Мало просто скомпилить код, надо его еще и проверить. А делать бессмысленные десятки переносов в QAS для проверки работоспособности - это нормально? У меня не бог весть какой опыт (меньше 10 проектов), но на каждом присутствовал клиент с данными на уровне DEV, в котором также проверялись и настройки перед переносом в QAS.
2. ??? Видимо это конкретные установки Вашей проектной команды.
3. Большое количество незакрытых транспортов бывает, но только не когда система в ПЭ. Если такое происходит после старта - должно возникать массу вопросов, начинающихся на "зачем", ИМО.

Просто еще раз не могу понять зачем Вы продолжаете людей запугивать ужасными последствиями, когда нужно просто дать рекомендации по снижению рисков. Ведь речь изначально шла не об "неизвестном левом" транспорте. Существует разработчик Anton Lyakhov, который знает какие объекты сидят в его собственном транспорте - все это является его зоной ответственности, а не виртуальных ПМ и админов. Ему достаточно проверить в целевой системе наличие "возможно конфликтных" объектов - если оные существуют - сделать подстраховку (путей предостаточно). После установки транспорта - докрутить все руками по месту. После этого - желательно создать все таки новый транспорт для переноса по цепочки DEV->QAS->PRD (возможно что и ручками пробежаться и повключать). Это опять же работа разработчика, а не базисника. А о первичном транспорте и можно и нужно забыть, поскольку он свою функцию выполнил.

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

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

На 90% проектах, в которых я принимал участие, в DEV'е можно было максимум - проверить работоспособность. А более-менее правдоподобные данные живут в Q&A.

Это про что, про ответственность? Мы с Вами друг друга, видимо не понимаем. Разработчик несет ответственность только за работоспособность своей разработки. Не больше. Ответственность за то, что эта разработка появилась в системе он несет только в случае самодеятельности. В противном случае ответственность лежит на человеке, давшем "добро" на данную разработку. Чаще всего это непосредственный руководитель. В небольших командах это, скорее всего, будет руководитель проекта.

В системе, находящейся в ПЭ, не должно возникать потребностей в сторонних транспортах. Ситуация с разработками в другой системе и принесением их в текущий DEV характерна не для ПЭ, а для активной фазы настройки.

Я никого не запугиваю. Просто я представил, как ко мне, как к базиснику на проекте, приходит некий %name% и предлагает перенести пару транспортов из своей системы. На вопрос о версиях компонентов в своей системе внятного ответа не получаю. Или получаю - но версии не совпадают. Потом выясняется, что у него разработка велась в системе ERP, а у меня вовсе даже NW. Да еще я накатил Ehp1 на нее... Да плюс человек не знает транспортную систему и вообще путается в показаниях
Эти транспорты будут перенесены только с письменного разрешения ПМ проекта. И то, я буду категорически возражать.
Это моя точка зрения. И не думаю, что меня с нее можно сдвинуть.

Про зону ответственности - см. выше.

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

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

Так изящно меня еще никто не посылал

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

p.s. а вас с вашими ортодоксальными догмами давно на пензию надо
лозунг дня: дело - ничто, пиар - всё!

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

John Doe


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


- в этом случае - да, конкретный разработчик.... а ведь ещё бывает "мы тут кучу разработок на чужом проекте спёрли, перенеси её нам и у нас весь проект будет готов! нафиг нам самим разрабатывать!? как нельзя? Я НА ФОРУМЕ ЧИТАЛ - МОЖНО! счас мы на тебя нажалуемся что ты нам сроки срываешь!"

ЗЫ: история друга:
авторитетный человек попросил перенести разработку с другого проекта "мы всегда так делаем!".
всё сломалось (подробностей не знаю ).
а самое весёлое, знаете чем кончилось? на планёрке спросили "кто виноват?" и Авторитетный_начальник_абапа сказал "базисник запросы перенёс неправильные!" базисника решили премии и бонусов и т.д... он там пытался както объяснить, но говорит что ответили типа "вечно вы базисники всем работать мешаете, а как чё сломаете - отмазываетесь что не виноваты!"
... конечно он сам виноват, ССЗБ, но мораль думаю ясна

мораль сей истории очень простая - если на вас давят (что встречается достаточно часто, и не принимают всерьез разумные аргументы) - требуйте бумагу, подписанную ПМом - невзирая на "авторитетность" просящего.

Еще весьма удобно вести разработки в копии продуктива.