CftClub.ru

tmp · Гость

Здравствуйте. Вопрос к банковским разработчикам со штатом разработчиков более 10.
Интересует, как у вас организован процесс разработки.
В частности :
1)Сколько копий используется , каково их назначение и актуальность. К примеру - база разработки квартальной давности, база тестирования, ежедневная искажённая копия реальной базы для оперативного разбора полётов, учебная база, база репозиторий с VSS через которую проходят все разработки. Базы выделенные для конкретных задач – проектов и т.д.
2)Какие права есть у разработчиков на эти базы ? разрабатывают под IBS или под своими пользователями ?
3)Как организован процесс передачи доработок на внедрение, тестирование? ставят сопровожденцы, или выделенные опытные разработчики ? утром , вечером или организованны технологические окна в течение дня ?

vtar · Эксперт Вступление в Клуб: 20.03.2009

Работал в нескольких банчатах разной степени топовости. Примерно так все и происходит, как Вами описано.

Искаженная копия, ежедневная или нет - это обычно для внешних разработчиков или вендора (ЦФТ). На разработческих БД обычно под IBS разработка и ИТ тестирование, когда надо проверить специфичные на права моменты - разработчик накидывает нужные права на свою учетку (IVANOV_II) которой может и не быть (т.е. сначала заводим из под IBS ее).

Andry

Alkov · Профи Вступление в Клуб: 23.09.2010

tmp · Гость

IBSO · Профи Вступление в Клуб: 20.08.2009

Запрос настроек у Сопровождения --- у кого запрос? У нас аналитик пишет ТЗ и сразу описывает какие настройки должны быть. Иначе как разработчик на своей схеме будет делать и тестировать?

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

Alkov · Профи Вступление в Клуб: 23.09.2010

tmp · Гость

Спасибо за ответы. но есть ещё интерес к теме.
Вот я в тех крупных банках которых работал было так - разработчик разрабатывал, тестировал сам, сам ставил на тестовые стенды для пользовательского тестирования - правил там если нужно, далее формировал хранилище и отдавал его на установку c инструкцией. Потом другое подразделение(обычно сопровождение) его по инструкции ставили на бой.
Т.е. разработчик отдавал уже готовую доработку, комулятив так сказать.

А вот сталкивались ли вы чтобы процесс переноса доработок был инкрементальным ?

Я вот столкнулся. причём эта инкрементальность диктуется исключительно структурой ИТ и устаревшими традициями. Разработчик работает на одной базе, далее для тестирования он передаёт специально обозначенным людям(которые только этим и занимаются) накат для установки и указывает на какую базу его необходимо установить. Далее если в ходе тестирования пользователь выкатит замечания или новые требования, то разработчик должен в следующем накате подготовить только изменённые объекты(обозначенные люди жестко контролируют это вплоть до кода). В дальнейшем именно оба релиза будут установлены на бой, в той же очередности.
в итоге если доработка-внедрение с привлечением ЦФТ или подрядчика длится месяцами, то в рамках этой работы возникает куча релизов. при этом чтобы не запутаться эти релизы постепенно ставят на бой.
Интересовался почему так - как то неубедительно ответили . что мол такой подход исключает пересечение разработчиков\подрядчиков по доработкам, хотя я раньше работал с нормальной организацией разработки и никогда таких рисков не возникало - сторонние доработки перед установкой проходили адаптацию и в путь. Пересечения между разработчиками исключалось 1) VSS 2) обычными коммуникациями. 3) сравнение со слепком ночной копии.

как то так.