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

[trud]

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

[Logger]

Цитата:

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

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

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

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

[AlexSD]

Цитата:

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

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

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

[trud]

Цитата:

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

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

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

[Logger]

Цитата:

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

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

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

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

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

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

[Ace of Database]

Цитата:

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

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

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

[Vadik]

Цитата:

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

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

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

[fed]

Цитата:

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

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

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

[Logger]

Цитата:

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

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

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

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

[Vadik]

Цитата:

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

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

Полная копия из продуктива в тест (database refresh), и пусть только попробуют не воспроизвестись

[fed]

Цитата:

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

Полная копия из продуктива в тест (database refresh), и пусть только попробуют не воспроизвестись

А сколько времени это занимает для БД размером, например, в террабайт ?
Я просто думал над этой схемой. Ничего кроме transaction log transport в голову не приходит. Но это достаточно геморойное решение по быстрому обновлению БД...

[Logger]

Цитата:

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

Полная копия из продуктива в тест (database refresh), и пусть только попробуют не воспроизвестись

Такие случаи тоже возможны.
Встречался баг, который зависел от того как физически данные были в табличке расположены - результат расчета себестоимости был разный. Оказывается по одной номенклатуре внутри одной даты было несколько одинаковых проводок и результат зависел от того в каком порядке записи из SQL придут. На рабочей легли в одном порядке. В тесте в другом. Пришлось в сортировку recid добавлять.

Да чего я говорю - можно много ситуаций придумать когда баг воспроизводится в рабочей а в тесте - нет.

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

Vadik, вы просто троллингом уже занимаетесь.
Я рад, что у вас на проекте все так хорошо. Но мы обсуждаем нужды усредненного заказчика. Там все по-другому. По-моему, это очевидно.

[Logger]

Цитата:

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

А сколько времени это занимает для БД размером, например, в террабайт ?

А если 10 террабайт ?
Не всякий тестовый сервак долетит до середины Днепра такую базу в принципе проглотит.

[Vadik]

Цитата:

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

А сколько времени это занимает для БД размером, например, в террабайт ?
Я просто думал над этой схемой. Ничего кроме transaction log transport в голову не приходит. Но это достаточно геморойное решение по быстрому обновлению БД...

Терабайт не получится, потому что продуктив и тест на одной подписке и она ограничена (по крайней мере пока) терабайтом. Сейчас, с нашими детскими объемами, делают за час где-то. Правда надо делать заявку заранее

Цитата:

Vadik, вы просто троллингом уже занимаетесь

Где именно ?

Цитата:

Я рад, что у вас на проекте все так хорошо. Но мы обсуждаем нужды усредненного заказчика. Там все по-другому. По-моему, это очевидно

Я в общем несколькими проектами занимаюсь, из них только один на D365O и остальные на 2012, так что могу сравнивать. Потребности и проблемы, вне зависимости от "жирности" клиента и версии системы по большому счету - одинаковые. И то что мы 10 лет решали их одним способом не означает что не существует других. Именно эту мысль я и пытаюсь донести, только и всего

[Dactil]

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

[pitersky]

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

[Damn]

Цитата:

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

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

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

[AlexSD]

Цитата:

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

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

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

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

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

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

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

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

[trud]

Цитата:

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

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

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

[kashperuk]

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

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