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

[Logger]

Цитата:

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

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

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

[mifi]

Цитата:

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

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

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

[sukhanchik]

Цитата:

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

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

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

[mifi]

Цитата:

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

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

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

[BOAL]

Цитата:

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

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

Клиент сам решит - если есть выбор!

Иногда повтор ситуации займет 2-4ч реала или бакап Террабайтной базы ( это тоже не 1 час) + останов системы на Х часов.
Речь о том, что система отладки нужна на любой версии, а вот как ее применять (запрещать) - это осознанная методология внедрения\эксплуатации.
Но инструмент должен быть!
Это как шуроповерт или простая отвертка дома - она нужна не всегда, но бывает момент... и опа, она есть, а не нужно идти к соседу, а потом ее нести обратно.

Вот и тут так же - это все (отладка на рабочей) не нужно и нештатно - но это должно быть в ассортименте.

Просто в проекте есть моменты, когда это уж очень нужно и становится штатным (опытная эксплуатация на 1-3 недели).

Но и да, кто сам на клиенте не просидел и в глаза пользователям не смотрел (не абстрактным сотрудникам Заказчика, а конкретной Марье Ивановне), тот это все через себе не пропустит и другую точку зрения просто не поймет, а только проанализирует, смоделирует, прикинет и сделает выводы (надеюсь не "а и так сойдет", как обычно).
Че уж говорить о "теоретиках", которые даже глаз внедренца не видят

[sukhanchik]

Цитата:

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

Но и да, кто сам на клиенте не просидел и в глаза пользователям не смотрел (не абстрактным сотрудникам Заказчика, а конкретной Марье Ивановне), тот это все через себе не пропустит и другую точку зрения просто не поймет, а только проанализирует, смоделирует, прикинет и сделает выводы (надеюсь не "а и так сойдет", как обычно).
Че уж говорить о "теоретиках", которые даже глаз внедренца не видят

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

Цитата:

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

Давайте все-таки разделять две вещи - максимально быстро фиксить баги и дебагить на рабочей версии.
Клиенту нужно первое. А второе - это только один из способов.

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

Цитата:

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

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

Конечно можно все организовать. Но, повторюсь, - не все может вылезти на тестовой базе. Ярким примером могут быть ситуации, которые завязаны на интеграцию АХ с чем-либо.
Опять-таки:
- на тестовой базе нельзя (сложно = дольше) выявить ошибки пользователя
- на тестовой базе нельзя (сложно = дольше) выявить изменение настроек, выполненных ответственными за это сотрудниками, которые отнеслись безответственно к смене настроек

[mifi]

Цитата:

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

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


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



Конечно можно все организовать. Но, повторюсь, - не все может вылезти на тестовой базе. Ярким примером могут быть ситуации, которые завязаны на интеграцию АХ с чем-либо.
Опять-таки:
- на тестовой базе нельзя (сложно = дольше) выявить ошибки пользователя
- на тестовой базе нельзя (сложно = дольше) выявить изменение настроек, выполненных ответственными за это сотрудниками, которые отнеслись безответственно к смене настроек

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