Отладка на рабочей базе

[Zabr]

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

[mifi]

Цитата:

Сообщение от Logger

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

P.S.
Аксапта это, к сожалению, не iPhone 4
Её с руками не отрывают. И кризис в IT никуда пока не делся.
Надо думать как предоставить клиенту лучший сервис.

Если люди на ваши слова нервно реагируют, то это не логотип виноват, а наболело у них. А вы просто под руку подвернулись

Так в том-то и суть. Лучший сервис - профессиональный сервис. Клиент (обычно) не является экспертом в области внедрения ERP. Если ему рассказать как все надо правильно делать, то он сам запретит доступ разработчикам на рабочее приложение и проблема решиться сама собой Это, кстати, не теоретические измышления, а вполне реальные факты из моей практики
То, что следует сесть вместе с пользователем и посмотреть, что у него происходит - вроде как с этим никто не спорил. А вот дебагить разноску инвойса на терабайтной базе с парой сотен работающих пользователей.. хм.

[AlGol]

Цитата:

Сообщение от mifi

Фед, почему минимальное использование best practices внедрения и поддержки (такое, как использование тестового приложения) вызывает такое отторжение?
Честное слово - я бы таким внедренцам, дебажащим на рабочем приложении, что-нибудь бы поотрывал

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

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

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

[BOAL]

А меня вот парят эти вот пол-часа - час, там где их раньше не было вообще (1-5 мин или 60 мин -это все же х12-60 разницы, при этом эти 5 мин еще и на тесте тратить). Да и выгружать по-живому куски таблиц тоже работа. То есть в ущерб чему-то или спец чел. И кто сказал, что в Тб базе эти нужные куски тоже не маленькие - вдруг там контрольный пример как раз неверная сумма на кучи данных?

В общем, выжить будет можно, станет сложнее на пустом месте, дольше в суппорте, а значит выше цена владения. И сложности (отпугивание) при продажах.

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

Электрорубанком при определенном усердии (таком же, как ты, Миша, предлагаешь) и с выключенном электричеством можно строгать

Цитата:

Все верно - но не следует уж прям так с ходу наезжать на МС. Там же тоже люди

Да не, все ясно, все помнят, как было и пугаются, как стало (станет).
Тут скорее "мне за державу обидно"(С) В смысле систему.

[SolNik]

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

[sukhanchik]

Цитата:

Сообщение от SolNik

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

Вот! Отличный пример! Не протестируешь такое на тестовой базе, ну никак!
А если баг проявляется только в многопользовательском варианте? Всех загонять в тестовую? Утопия это.

Просто скорее всего все это кончится тем, что отладку будут включать на рабочей БД, клиенты будут мучаться с производительностью, а в МС гадать - а чем же производительность АХ их не устраивает.

[belugin]

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

[mifi]

Цитата:

Сообщение от belugin

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

А это же вроде с самого начала было понятно, об ее отсутствии заявил Фед, а не Питер С Густаво Я-то просто удивился, что это такая сверхнужная фича

[EVGL]

Цитата:

Сообщение от mifi

А это же вроде с самого начала было понятно, об ее отсутствии заявил Фед, а не Питер С Густаво Я-то просто удивился, что это такая сверхнужная фича

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

[sukhanchik]

Цитата:

Сообщение от BOAL

Пусть это нужно 1 раз в год на 10мин, но это экономит эти 3.65 дня дауна системы.

Цитата:

Сообщение от EVGL

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

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

[macklakov]

Цитата:

Сообщение от mifi

Я-то просто удивился, что это такая сверхнужная фича

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

[greench]

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

И организация процесса разработки на клиенте немного другая. Очень часто ТЗ никто не пишет, документации как таковой в природе не существует или осталась устаревшая от внедренца и тд...

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

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

[mifi]

Цитата:

Сообщение от greench

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

И организация процесса разработки на клиенте немного другая. Очень часто ТЗ никто не пишет, документации как таковой в природе не существует или осталась устаревшая от внедренца и тд...

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

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

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

[belugin]

Отлаживаться можно без APPDomain насколько я знаю.

Горячую замену нужно проводить через APPDomain.

Цитата:

Сообщение от belugin

Отлаживаться можно без APPDomain насколько я знаю.

Горячую замену нужно проводить через APPDomain.

Зачем рассказали!
Такую дискуссию на корню зарубили