Как жить без средств разработки и отладки в продуктиве

[trud]

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

[Logger]

Цитата:

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

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

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

Хотя есть надежда на облака. Что их поддержка спустит наших проектировщиков на землю.

[AlexSD]

Цитата:

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

Т.е. они достигли полного отрыва от реальности

Мощно вы экстраполируете из "обсуждали с ОДНИМ разработчиком", до "ОНИ достигли"

[Logger]

Цитата:

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

Мощно вы экстраполируете из "обсуждали с ОДНИМ разработчиком", до "ОНИ достигли"

Да какая тут экстраполяция...
Я как чукча, о чем вижу - о том пою.

Понимаю, что вам как сотруднику майкрософт, наверно, неприятно читать такое мнение, но оно оправдано. Мнение ОДНОГО разработчика, которое привел trud в данном случае полностью соответствует тому, что они нам предоставили как потребителю их продукта.

А по поводу экстраполяции, ну вот вдумайтесь сами, как должен мыслить проектировщик платформы, который запрещает разработку в рабочей инсталляции? Это же очень узкое мышление программиста.
Он не понимает, что есть куча задач по диагностике проблем, которые можно повторить только на рабочей базе, что нет времени переносить ее на тест, что фактор скорости и времени реакции играет важнейшую роль, что...
Да много еще чего.

А еще хуже если он этого не не понимает, а ему просто наплевать. Так для кого он проектирует систему ? И какая у него мотивация при этом ?

[Ace of Database]

Цитата:

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

фактор скорости и времени реакции играет важнейшую роль

Золотые слова, Юрий Венедиктович! (С)

[Vadik]

Цитата:

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

А по поводу экстраполяции, ну вот вдумайтесь сами, как должен мыслить проектировщик платформы, который запрещает разработку в рабочей инсталляции?

Как мыслит проектировщик нам знать не дано и гадать об этом бесполезно. Он может вообще не мыслить, а может проектировать аналог карьерного самосвала работающего 24x7 с перерывами на техобслуживание на замену десятилетнего ведра с болтами, в котором постоянно нужно приматывать синей изолентой отваливающиеся механизмы.
Как по мне, если в рабочей инсталлляции регулярно работают не пользователи, а программисты и тестировщики, значит программисты и тестировщики недоработали где-то раньше и надо разбираться почему это происходит
P.S. И поверьте, без отладки в рабочем приложении жить немного страшно и непривычно, но можно

[fed]

Цитата:

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

P.S. И поверьте, без отладки в рабочем приложении жить немного страшно и непривычно, но можно

Я тоже видел одного (и только одного) немецкого клиента у которого отладка в рабочем приложении запрещена. Этот клиент - фармацевтическая компания и у них в силу отраслевой специфики очень тяжелая система качества. Так что бюджет на длительное тестирование у них по умолчанию включен во все айти-проекты. (И в конечном счете - приводит к повышению цен на лекарства для конечных потребителей).
Все остальные клиенты (по крайней мере мои) предпочитали и предпочитают тратить на тестирование меньше ресурсов (экономя деньги), но беря при этом на себя риски того что у них живом приложении что-то сломается и это что-то надо будет чинить на лету.
То есть - раньше клиент мог найти некий баланс между системой качества и тщательным тестированием с одной стороны и экономией бюджета и взятием рисков с другой. Но в новой версии, Микрософт традиционно решил все за наших клиентов, попутно отсеяв всех тех, у кого больших бюджетов на правильную организацию процесса нету.
[если тема про отладку на боевом приложении получит продолжение, вырежите ее пожалуйста в отдельную тему]

[Logger]

Цитата:

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

P.S. И поверьте, без отладки в рабочем приложении жить немного страшно и непривычно, но можно

Разве я где-то сказал, что нельзя ?
Можно. Но крайне затратно.

А как вы, например, ловите хитровоспроизводимые баги? Которые на рабочей есть, а в тесте не воспроизводятся ?

[AlexSD]

Цитата:

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

Да какая тут экстраполяция...

Понимаю, что вам как сотруднику майкрософт, наверно, неприятно читать такое мнение, но оно оправдано.

Ну, я - уже больше трех лет как бывший сотрудник (хотя, бывают ли бывшие сотрудники ). Зато у меня теперь есть время писать на форумы.
Было высказано мнение одного программиста из компании, в которой работают более ста тысяч сотрудников. Как говорится, «у нас все люди сложные, и к каждому свой подход нужен».

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

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

Еще одна мысль, что для того, что бы принимать решения, нужно обладать более полной картиной и статистикой. Сколько кустомеров включили разработку на проде? А сколько – не включали и копируют данные на тест? Какие простои и потери у тех, кто дебажит на проде, а какие у тех, кто раскошелился на тест?

ЗЫ. Я ничегошеньки не знаю про САП.

[trud]

Цитата:

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

В их понимании, похоже, что для себя. А тут еще клиенты с внедренцами мешаются под ногами.

ну так то да , т.е. большинство разработчиков и менеджеров(те кто делают платформу) в реальных внедрениях очевидно не участвовала. и на X++ не пишут. т.е. внедряют партнеры, а Микрософт особо активно у партнеров сотрудников не переманивает.

[Dactil]

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

[pitersky]

Присоединяюсь к хору несогласных)))))) Давайте говорить прямо - любая ERP-система, в силу объёма и сложности написанного кода, будет содержать непреднамеренные ошибки. И одной такой ошибки, подхваченной в критический момент (например, при подготовке срочного фискального отчёта) без возможности онлайн-исправления, может быть достаточно, чтобы похоронить внедрение в целом. Руководство не будет читать пресс-релизы МС, у него будет логика простая - один раз система подвела, значит и ещё раз подвести может. А раз так, то нужна другая система.

[Damn]

Цитата:

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

один раз система подвела, значит и ещё раз подвести может. А раз так, то нужна другая система.

Какой-то "крот" из конкурирующей конторы наверняка в MS завёлся и хочет добиться именно этого результата. Как пить дать.

[trud]

Цитата:

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

Присоединяюсь к хору несогласных)))))) Давайте говорить прямо - любая ERP-система, в силу объёма и сложности написанного кода, будет содержать непреднамеренные ошибки. И одной такой ошибки, подхваченной в критический момент

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

[Logger]

Цитата:

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

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

Интересно, он о макросах на Visual basic for applications слышал что-нить? Их вообще то можно отлаживать. Неужели не нашлось никого, кто бы его на этом подколол?

По поводу логов - хорошо что не сказал, что у нормальных программистов программы не глючат

[kashperuk]

В Dyn365 for Operations уже активно используется саппорт через DRI, когда на проблему в облачном сервисе сразу "набрасываются" "специалисты", и в "короткие" сроки ее устраняют.
Это, конечно, медленнее чем самому в продакшне фиксить, но может и понадежнее будет..

Посмотрим, как это приживется когда заблокируют уже оверлейеринг

[trud]

Цитата:

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

В Dyn365 for Operations уже активно используется саппорт через DRI, когда на проблему в облачном сервисе сразу "набрасываются" "специалисты", и в "короткие" сроки ее устраняют.

А как в целом выглядит процесс(т.е. по прежнему же надо будет воспроизводить на стандартной системе ошибку)? и что такое DRI?
т.е. вот буквально из недавнего - завели нового клиента, пытаются разнести заказ. система выдает ошибку 'Account not specified' - без подробностей. проверили все счета, все вроде везде заполнено. т.е. путем отладки нашли что применялся какой то миск чарж или че-то типа того, и в нем не было счета,
но тут сразу подумалось, как такие ошибки находить без отладки

[EVGL]

По факту от сообщения до исправления ошибки уходит в среднем 2 месяца. Потому что никакой transaction log shipping невозможен. По запросу получаем бэкап, его потом можно в тестовой системе восстановить. До определенного момента в прошлом году невозможно было получить даже бэкап со следующим обоснованием: "наши SLA не позволяют переносить данные за пределы Microsoft production tenant". Т.е. данные клиентов взяли в заложники по примеру кибермошенников. После того, как клиенты и партнеры, очевидно, дали ответственным людям прямо в самое чувствительное место, SLA волшебным образом поменялись, и все стало возможно.

[Damn]

А в чём коммерческая выгода для MS запрета отладки в продуктиве ?
Есть какая-то официальная легенда от них ? Они же всё делают только для того чтобы заработать побольше денег. В чём тут выигрыш ?

[fed]

Цитата:

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

А в чём коммерческая выгода для MS запрета отладки в продуктиве ?
Есть какая-то официальная легенда от них ? Они же всё делают только для того чтобы заработать побольше денег. В чём тут выигрыш ?

Насколько я понимаю (сам пока не пробовал - повода не было), отладка в ax7 интрузивная. То есть - breakpoint останавливает не мою сессию, а весь сервер.
Чтобы в таком режиме разрешить отладку на продуктиве, надо какой-то режим с несколькими AOS на одной БД делать. Возможно у них есть планы поддержать такой режим для повышения масштабируемости, но сейчас его, по моему, нету...
P.S. То есть - логика в том чтобы сэкономить на поддержке множественности AOS на одной базе данных...