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

Мне интересно, это только у нас такая проблема, или у других тоже самое? Как в других компаниях все это контролируется? А есть у САП какие-то рекоммендации по этому поводу?

Поделитесь опытом, пожалуйста!

Вы что, всю очередь каждый раз по новой катите?

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

Вот мне интересно, как в других компаниях базисники контролируют перенос транспортов из quality в продуктив? Возникают ли такие же проблемы и если да, то как решаются?

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

Могу ответить с точки зрения консультанта - стараюсь все свои запросы систиматезировать. Осоенно удобно, когда уже идет поддержка: есть задача, которая была поставлена - на нее есть некий "первичный документ". Все запросы, закрывающие эту задачу - привязываются к ней. Запросов без задач быть не должно. Когда бизнес говорит, что все ок - то переносятся все запросы этой задачи. Понятно, что 100% гарантии это не даст - и, возможно, неявно что-то было еще изменено чужим запросом, о котором я не знал - т.к. например его делал другой консультант, и это не перенеслось. Это уже ИМХО только на уровне "знаний в ширь" можно решить.
Ну и естественно, когда кто-то что-то делает, и ему система предлагает добавить свою задачу в чужой запрос - надо быть очень внимательным и разобраться.

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

Рекомендации? Да все просто.
1. Доводим систему до продуктива, чтобы работала и не требовала больших изменений
2. Делаем из продуктивной системы две других (разработка и тест)
3. Начинаем жизнь ландшафта заново, с идентичными по настройкам системами.
4. Запрещаем консультантам создавать и деблокировать запросы
5. Назначаем администратора транспортной системы, который и будет этим заниматься
6. [s]Закапываем стюар[/s] Перестаем работать по Вашему сценарию и переносим транспорты из очереди только в нужном порядке. И никаких претензий не принимаем.

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

Например:

Есть проекты А и Б.
В рамках проекта А изменяются
- таблицы Т1, Т2 (добавляются поля)
- стандартные программы П1, П2 (взлом)

В рамках проекта Б изменяются
- таблицы Т2, Т3 (добавляются поля)
- стандартные программы П2, П3 (взлом)

Проект А срок сдачи март, проект Б - июнь.

По проекту А все сделали, в QAS все проверили, работает.
Пока проверяли проект А, по проекту Б начали работы, перенесли в QAS, сделали тест, пока не работает.

Нужно переносить работы по проекту А в продуктив. По проекту Б - нельзя.
Как быть с объектами Т2, П2 ?

2 Ludens,
Давайте не будем обсуждать проблемы ведения бизнеса в идиотских условиях?

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

В конкретном примере - один, простите, хрен, придется заставлять все это безобразие работать в продуктиве. Ну так и надо добиваться работоспособности с самого начала. Или Вы думаете, что сумеете в продуктиве использовать потом разные версии таблиц и отчетов?
Более, того, Вы не сумеете провести тест системы в кволити, если не согласуете окончательную версию таблиц

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

А Вы не пробовали в SPRO создать проекты и запросы привязывать к проектам? При таком подходе если цепляется объект из другой задачи STMS вас предупредит об этом.
Жесткий контроль, запрет на деблокирование консами всеми подряд задач, работа только в рамках задачи, есть 1 ответственный, который дает одобрямс (крайне желательно письменный) иначе вас очень быстро сделают крайним в нерабочем продуктиве и срывах проектов.
По другому просто анрил, сам хлебнул в свое время с выравниваниями систем по продуктиву.

avlag, а почему бы и да? =)

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


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

а тут запросы по проекту А уже деблокированы и тестируются в QAS'е
в это время эти же объекты модифицируются по проекту Б
покажет ли система что этот объект уже ушел по другому проекту?

если это так, то пойду перечитывать хэлп и настраивать проекты

2 avlag
эх...если бы было все так просто...

Дело в том, что у нас ситуация в точности , как описал ниже Ludens, только еще сложнее - проекты А и В уже запущены в эксплуатацию в продуктив и там уже работают пользователи, еще есть проект С, который частично еще в разработке, частично в тесте и частично в продуктиве. Вот такой вот "изврат" получился. Но надо как-то с этим жить и исправлять ситуацию.

Сейчас есть идея хотя бы выровнять системы QAS и PRD (все три выровнять пока совсем невозможно), думаем сделать это следующим образом:
1. сделать своего рода заморозку переноса изменений - разработку совсем не можем заморозить, будем просто деблокировать запросы, но без переноса в QAS.
2. попросить бизнес дотестировать все, что накопилось в QAS
3. перенести все запросы одной очередью из QAS в PRD
4. сравнить QAS с PRD при помощи SCU0 и проанализировать результаты
5. при наличии различий по объектам разработок и настроек найти в каких транспортах эти объекты и повторно донести эти запросы из QAS в PRD.
5. опять запустить SCU0 и посмотреть что получилось.

Уже запретили,назначили, сразу, как первый проект в продуткив ушел, это было более чем полгода назад. правила и процедуры написали, следуем. Улучшения есть, но проблемы остались, основная причина сейчас в том, как мы думаем, что транспорты застревают в QAS.
6. Повторюсь - если бы было все так просто... Как заставить бизнес а) тестировать быстрее б) тестировать и утверждать перенос в той последовательности в которой транспорты в очереди стоят? Им то дела вообще нет до транспортов. А что делать с проблемами с высоким приоритетом, которые решить и перенести срочно надо 9таких тоже не мало)? неужели это только у нас такие проблемы?

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

2 ZeUsM Да, верно, думаю это бы помогло в чем-то, но тут тоже очень много недостататков (например то, что Ludens описал). Да и сразу надо было начинать с этого, а мы начали рассматривать этот вариант, когда уже было около тысячи запросов создано, проект в самом разгаре и т.д... Сейчас мы ввели правила наименования транспортов, с версионностью, с номером проблемы...Стало немного легче разбираться, что от чего зависит, но проблемы с некорректным переносом в продуктив все равно остались.

Ludens, подскажите, пожалуйста, как у Вас налажен процес переносов в продуктив?

<Много skip...>
Проблемы такого рода возникают в том случае, если базисник жестко подчинен PM'у и не может возразить ни ему, ни консультантам, которые "на прошлых проектах делали так, и все работает".
Поймите, то, что протестировал бизнес в Q&A, работоспособно только в условиях Q&A, со всеми импортированными туда транспортами. Причем не только предыдущими, но и последующими.
Поэтому, если Вы потом переносите пару-тройку-десяток транспортов в продуктив (но не всю очередь), то имеете неслабые шансы получить нерабочую систему.

Конечно, если по условиям проекта, ответственность за все это дерьмо лежит на ком-то другом, причем все транспорты переносятся под подпись этого ответственного товарища, а сверхурочная работа базисника хорошо оплачивается (другими словами нам хорошо платят за исправление чужих ошибок), то можно жить и так. Только грустно. Примерно как собирать мебель не закручивая шурупы, а забивая. На момент сдачи держится? Держится. А дальше буду разгребать уже не я.

Так вот мы и есть те, кому разгребать досталось... Система уже в поддержке, хотя еще "хвосты" проектные доделываются....Мы и есть бизнес, которому досталась система после внедрения, так сказать, а в моих описаниях - под бизнесом я подразумеваю пользователей системы, которую мы теперь поддерживаем и пытаемся теперь со всем этим разобраться.

Поможет ли в нашем случае просто снова перенести всю очередь запросов начиная с самого первого по самый последний из QAS в PRD? получим ли мы тогда рабочую продуктивную систему? Дело в том, что мы в этом не уверены. Что бы Вы посоветовали? как надежнее было бы выровнять системы теперь?

На этот вопрос можно ответить только практикой. Создать новую отдельную копию PRD и выполнить туда перенос и тестировать. Теоретические рассуждения не помогут.