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

[mifi]

*** sukhanchik Выделено из DeniZone: The future of X++ ***

Цитата:

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

Ооо - как новую систему полюбят все внедренцы ! Ведь теперь нельзя будет отлаживаться на боевом сервере. Придется мучительно допрашивать пользователей о том, что же они такого отмочили и потом пытаться воспроизвести на тестовом приложении. Разумеется с подъемом бэкапа БД.

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

[gl00mie]

Цитата:

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

А еще реальностью стал (по моим источникам) геморрой с перезагрузкой откомпилированных сборок.
1. Отладка на сервере возможна только через VS Debugger
2. Чтобы отлаживаться, придется включать App Domain с тормозами.
3. Если у тебя на сервере работает несколько разработчиков - опять таки только App Domain с hot-swapping.

Вроде Понтоппидан ясно написал, что по умолчанию выполнение приложения в виде IL-кода средствами CLR включено лишь для пакетников, вызовов каких-то сервисов и отдельных кусков приложения, на которые явно указали разработчики посредством RunAs. Я лично сразу вспомнил про "особенности" отладки кода в NAV 2009 (пишешь на одном языке, отлаживаешь на другом) и подумал, что так сделали именно из-за отладки: пакетники отлаживают не так часто (по крайней мере, именно в режиме выполнения на сервере), но при этом на них может приходиться существенная доля нагрузки на систему, поэтому для них и включили по умолчанию новый механизм исполнения кода, а для бизнес-логики, запускаемой пользователями, - выключили, чтобы ее можно было при необходимости отлаживать, как обычно.

Цитата:

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

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

По-моему, best practices не избавляют полностью от необходимости время от времени отлаживаться на рабочем приложении. У всех, видимо, масштаб времени свой: кто-то может себе позволить для теста развернуть бэкап рабочей базы (извиняюсь за нескромный вопрос, на какого размера базе вы тестируете обычно?) и пару дней вдумчиво исследовать произошедшее, а кому-то нужно ответить пользователю, что за фигня, в течение максимум часа.

[mifi]

Цитата:

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

Вроде Понтоппидан ясно написал, что по умолчанию выполнение приложения в виде IL-кода средствами CLR включено лишь для пакетников, вызовов каких-то сервисов и отдельных кусков приложения, на которые явно указали разработчики посредством RunAs. Я лично сразу вспомнил про "особенности" отладки кода в NAV 2009 (пишешь на одном языке, отлаживаешь на другом) и подумал, что так сделали именно из-за отладки: пакетники отлаживают не так часто (по крайней мере, именно в режиме выполнения на сервере), но при этом на них может приходиться существенная доля нагрузки на систему, поэтому для них и включили по умолчанию новый механизм исполнения кода, а для бизнес-логики, запускаемой пользователями, - выключили, чтобы ее можно было при необходимости отлаживать, как обычно.
По-моему, best practices не избавляют полностью от необходимости время от времени отлаживаться на рабочем приложении. У всех, видимо, масштаб времени свой: кто-то может себе позволить для теста развернуть бэкап рабочей базы (извиняюсь за нескромный вопрос, на какого размера базе вы тестируете обычно?) и пару дней вдумчиво исследовать произошедшее, а кому-то нужно ответить пользователю, что за фигня, в течение максимум часа.

В ответ на вопрос пользователя нужно дать правильный ответ.У меня есть подозрение, что достаточно существенный процент ответов (а тем более фиксов), сделанных "в течение максимум часа" приведут, извиняюсь, к еще большей фигне.Которую доблестный внедренец продолжит дебажить на рабочем приложении. На 99% внедрений, с которыми я работаю, разработчик вообще не имеет доступа к рабочей базе, поэтому вопрос о ее размере не имеет особого значения.

[sukhanchik]

Цитата:

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

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

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

Человек с должностью "разработчик" может и не иметь доступ к рабочему приложению. Но опять-таки - кто-то, кто обладает знаниями Х++ кода должен иметь возможность понять проблему пользователя, которая:
а) может быть нечетко сформулирована (ну не помнит пользователь сколько кликов и куда в точной последовательности он сделал)
б) может воспроизводиться только на рабочей БД (в силу отсутствия актуальных данных на копии рабочей БД), а время создание актуальной копии тестовой БД больше требуемого времени на решение проблемы
в) может в принципе не воспроизводиться на любой БД кроме рабочей

Более того, на некрупных внедрениях экономически может быть выгоднее вместо тщательного тестирования перенос кода на рабочее приложение с собиранием "граблей" в рабочем режиме UPD: Конечно это для редких модификаций. Но которые все же могут присутствовать.

[belugin]

вроде в видео была отладка X++ на VS

[mifi]

Цитата:

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

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

Человек с должностью "разработчик" может и не иметь доступ к рабочему приложению. Но опять-таки - кто-то, кто обладает знаниями Х++ кода должен иметь возможность понять проблему пользователя, которая:
а) может быть нечетко сформулирована (ну не помнит пользователь сколько кликов и куда в точной последовательности он сделал)
б) может воспроизводиться только на рабочей БД (в силу отсутствия актуальных данных на копии рабочей БД), а время создание актуальной копии тестовой БД больше требуемого времени на решение проблемы
в) может в принципе не воспроизводиться на любой БД кроме рабочей

Более того, на некрупных внедрениях экономически может быть выгоднее вместо тщательного тестирования перенос кода на рабочее приложение с собиранием "граблей" в рабочем режиме UPD: Конечно это для редких модификаций. Но которые все же могут присутствовать.

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

[BOAL]

Цитата:

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

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

Потому, что разработчки софта (и часто его сотрудники) очень далекие от реальной работы системы люди - они теоретики.
Есть три категории опыта АХ
1. Разработка ядра и его локализации
2. Внедрение этой чудо-системы
3. Работа на клиенте.
Только тот, кто прошел 2 и 3 достоин заниматься 1
А у нас идут в 1 с улицы или в лучшем случае с парой лет 2 на ролях "сидел в трюме, общался с юзерами через консультанта".

Любая фича (хрень), которая коробит самого разраба, делает его тест содеянного им же, неудобным в течении 0.5 минуты и тем более более (5 мин или час!!) будет коробить конечного пользователя по 8ч в день все время!!!
А разараб - "покрасил и забыл"(С) (тут смотрим тему про цвета в гриде и тп)

Так вот - АХ еже версионно теряет свои конкурентные преимущества над другими системами. Внедренцы тоже не дураки и из монобизнеса становятся "ЕРП в ассортименте и, конечно, свежий 1С в наличии".

Перекрестные ссылки, которые перестанут работать на вынос части кода (отчетов и прочего) в ВижуалСтудию, отваливающийся от этого код, который даже компиляцией на найти, токо по факту неработы и падения в (синий экран видимо )
Отказ дебугера, стек4а вызовов и просмотра переменных на рабочей база == увеличению срока простоев системы с 5-10мин нонстоп отладки без выгона юзеров, до 3-24ч на всякие переносы бакапа и повтора ошибки.

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

Мы ж все помним какие тексты ошибок выдвает АХ и что их нужно уметь читать и понимать, что если она пишет ХХХХ, то это вовсе не ХХХХ, а совсем даже УУУ.

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

Ведь 99% надежная система - это значит что в год она 3.65 дня стабильно лежит в дауне.
должно быть 99.999% - а это все из мелочей скалдывается.
Да и в конце концов - возможность, не значит нужно пользоваться. А нет возможности == танцы с бубном. Пусть это нужно 1 раз в год на 10мин, но это экономит эти 3.65 дня дауна системы.

Накипело, сорвался, выговарился, простите, если что не так

[Logger]

Цитата:

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

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

Ну это вы зря.
Некоторые деятели любят писать на рабочей и потом накатывать на дев. А некоторые забывают накатывать. Вот этим я бы руки точно оторвал

[Logger]

Цитата:

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

В ответ на вопрос пользователя нужно дать правильный ответ.

Ваши бы слова да нашим юзерам в уши ! "Дать правильный ответ" - как праивло воспринимается как отмазка. Срабатывает не всегда

Цитата:

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

У меня есть подозрение, что достаточно существенный процент ответов (а тем более фиксов), сделанных "в течение максимум часа" приведут, извиняюсь, к еще большей фигне.Которую доблестный внедренец продолжит дебажить на рабочем приложении. На 99% внедрений, с которыми я работаю, разработчик вообще не имеет доступа к рабочей базе, поэтому вопрос о ее размере не имеет особого значения.

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

[mifi]

Цитата:

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

Ну это вы зря.
Некоторые деятели любят писать на рабочей и потом накатывать на дев. А некоторые забывают накатывать. Вот этим я бы руки точно оторвал

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

[gl00mie]

Цитата:

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

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

Тю!.. вот только не надо "ля-ля" про нетестированный код! Кто-то так хорошо тестировал RCashVoucher (в RU5, по крайней мере), что забыл обрамить обращения к RCashTrans в unchecked(Uncheck::TableSecurityPermission) (хотя Best Practices все знают и Writing Secure X++ Code, наверно, все читали - иначе с чего бы повесили AOSAuthorization на таблицу), из-за чего у пользователей без доступа к ключу RCashTables, но с доступом к самой таблице и всем формам не разносятся кассовые журналы.

[CDR]

Цитата:

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

На 99% внедрений, с которыми я работаю, разработчик вообще не имеет доступа к рабочей базе, поэтому вопрос о ее размере не имеет особого значения.

Наверное именно поэтому "локализованная" функциональность порой поражает своей производительностью.

[mifi]

Цитата:

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

Наверное именно поэтому "локализованная" функциональность порой поражает своей производительностью.

Забавная дискуссия получилась. На утверждение, сопоставимое, на мой взгляд, по тривиальности с "Дети, чистите зубы утром и вечером " в ответ слышно, в основном "Вы там в МС к.. теоретики" В общем, подобная точка зрения тоже имеет право на существование, но зубы все-таки надо чистить/поддерживать рабочую, тестовую и разработческую версию

[Logger]

Цитата:

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

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

Ну, про разработку на рабочей и перенос на дев это шутка была.

[Logger]

Цитата:

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

Наверное именно поэтому "локализованная" функциональность порой поражает своей производительностью.

Вы хотите всего и сразу.
Сначала скажите спасибо, что она вообще появилась.

Производительность, будем надеяться, потом допилят.

Кстати, почитал что нового в RU6 - в отличие от RU5 - нового почти ничего. В основном исправление ошибок и ускорение работы.

[mifi]

Цитата:

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

Ну, про разработку на рабочей и перенос на дев это шутка была.

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

[Logger]

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

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

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

[sukhanchik]

Цитата:

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

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

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

[Zabr]

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

[mifi]

Цитата:

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

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

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

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

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