30.03.2017, 05:31 | #1 |
Участник
|
Как жить без средств разработки и отладки в продуктиве
Не, идеология там другая - "надо все изначально делать правильно". мы ее обсуждали с одним из разработчиков МС применительно к закрытию возможности отладки на продакшн. т.е. у него были аргументы что отладка на продакшн нафиг не нужна, т.е. все либо изначально сделано правильно, и тогда она не нужна по определению или допущена какая-то ошибка - но это надо менять процесс который привел к ошибке, а не пытаться это исправить отлаживая что-то. т.е. тут очевидно из той же серии, поля "надо изначально называть правильно".
|
|
30.03.2017, 07:12 | #2 |
Участник
|
Цитата:
В их понимании, похоже, что для себя. А тут еще клиенты с внедренцами мешаются под ногами. Какие еще нафиг продажи ? Хотя есть надежда на облака. Что их поддержка спустит наших проектировщиков на землю. |
|
30.03.2017, 07:17 | #3 |
Microsoft Dynamics
|
|
|
30.03.2017, 08:11 | #4 |
Участник
|
ну так то да , т.е. большинство разработчиков и менеджеров(те кто делают платформу) в реальных внедрениях очевидно не участвовала. и на X++ не пишут. т.е. внедряют партнеры, а Микрософт особо активно у партнеров сотрудников не переманивает.
|
|
30.03.2017, 09:14 | #5 |
Участник
|
Цитата:
Я как чукча, о чем вижу - о том пою. Понимаю, что вам как сотруднику майкрософт, наверно, неприятно читать такое мнение, но оно оправдано. Мнение ОДНОГО разработчика, которое привел trud в данном случае полностью соответствует тому, что они нам предоставили как потребителю их продукта. А по поводу экстраполяции, ну вот вдумайтесь сами, как должен мыслить проектировщик платформы, который запрещает разработку в рабочей инсталляции? Это же очень узкое мышление программиста. Он не понимает, что есть куча задач по диагностике проблем, которые можно повторить только на рабочей базе, что нет времени переносить ее на тест, что фактор скорости и времени реакции играет важнейшую роль, что... Да много еще чего. А еще хуже если он этого не не понимает, а ему просто наплевать. Так для кого он проектирует систему ? И какая у него мотивация при этом ? Последний раз редактировалось Logger; 30.03.2017 в 09:20. |
|
30.03.2017, 10:10 | #6 |
Участник
|
|
|
|
За это сообщение автора поблагодарили: Logger (1). |
30.03.2017, 15:11 | #7 |
Модератор
|
Цитата:
Как по мне, если в рабочей инсталлляции регулярно работают не пользователи, а программисты и тестировщики, значит программисты и тестировщики недоработали где-то раньше и надо разбираться почему это происходит P.S. И поверьте, без отладки в рабочем приложении жить немного страшно и непривычно, но можно
__________________
-ТСЯ или -ТЬСЯ ? |
|
|
За это сообщение автора поблагодарили: Link (0). |
30.03.2017, 15:51 | #8 |
Moderator
|
Цитата:
Все остальные клиенты (по крайней мере мои) предпочитали и предпочитают тратить на тестирование меньше ресурсов (экономя деньги), но беря при этом на себя риски того что у них живом приложении что-то сломается и это что-то надо будет чинить на лету. То есть - раньше клиент мог найти некий баланс между системой качества и тщательным тестированием с одной стороны и экономией бюджета и взятием рисков с другой. Но в новой версии, Микрософт традиционно решил все за наших клиентов, попутно отсеяв всех тех, у кого больших бюджетов на правильную организацию процесса нету. [если тема про отладку на боевом приложении получит продолжение, вырежите ее пожалуйста в отдельную тему] Последний раз редактировалось fed; 30.03.2017 в 15:57. |
|
30.03.2017, 16:30 | #9 |
Участник
|
|
|
30.03.2017, 16:37 | #10 |
Модератор
|
Полная копия из продуктива в тест (database refresh), и пусть только попробуют не воспроизвестись
__________________
-ТСЯ или -ТЬСЯ ? |
|
30.03.2017, 16:43 | #11 |
Moderator
|
Цитата:
Я просто думал над этой схемой. Ничего кроме transaction log transport в голову не приходит. Но это достаточно геморойное решение по быстрому обновлению БД... |
|
30.03.2017, 16:50 | #12 |
Участник
|
Цитата:
Встречался баг, который зависел от того как физически данные были в табличке расположены - результат расчета себестоимости был разный. Оказывается по одной номенклатуре внутри одной даты было несколько одинаковых проводок и результат зависел от того в каком порядке записи из SQL придут. На рабочей легли в одном порядке. В тесте в другом. Пришлось в сортировку recid добавлять. Да чего я говорю - можно много ситуаций придумать когда баг воспроизводится в рабочей а в тесте - нет. А самое главное зачем это все ? Затраты на поддержание такого сервака. Стоимость от простоя рабочей базы пока база скопируется, пока все воспроизведут, пока... выполнят все безумные хотелки и запреты. Vadik, вы просто троллингом уже занимаетесь. Я рад, что у вас на проекте все так хорошо. Но мы обсуждаем нужды усредненного заказчика. Там все по-другому. По-моему, это очевидно. Последний раз редактировалось Logger; 30.03.2017 в 16:55. |
|
30.03.2017, 16:52 | #13 |
Участник
|
|
|
30.03.2017, 17:27 | #14 |
Модератор
|
Цитата:
Цитата:
Vadik, вы просто троллингом уже занимаетесь
Цитата:
Я рад, что у вас на проекте все так хорошо. Но мы обсуждаем нужды усредненного заказчика. Там все по-другому. По-моему, это очевидно
__________________
-ТСЯ или -ТЬСЯ ? |
|
30.03.2017, 18:00 | #15 |
Участник
|
Да действительно куча причин, по которым вариант с копией продуктивка не прокатит. Толстая продуктивная БД будет копироваться кучу времени. Должна быть инфраструктура под содержание толстой тестовой БД. Кроме того, на тестовой БД могут работать другие сотрудники - тестить доработки, прогонять сценарии и пр. Эти процессы могут занимать длительное время, и им может не понравиться, что все их преднастройки будут снесены обновлением с прода, и надо делать их заново. Значит нужно выделить отдельную инсталляцию чтобы поотлаживать копию прода, значит опять нужна инфраструктура под это дело. Это порочный круг.
Бывают проекты, где по описанным выше причинам полгода не обновляется тестовая среда, а бывает, что еженочно на тест выкатывается свежак. Последний раз редактировалось Dactil; 30.03.2017 в 18:03. |
|
30.03.2017, 18:18 | #16 |
северный Будда
|
Присоединяюсь к хору несогласных)))))) Давайте говорить прямо - любая ERP-система, в силу объёма и сложности написанного кода, будет содержать непреднамеренные ошибки. И одной такой ошибки, подхваченной в критический момент (например, при подготовке срочного фискального отчёта) без возможности онлайн-исправления, может быть достаточно, чтобы похоронить внедрение в целом. Руководство не будет читать пресс-релизы МС, у него будет логика простая - один раз система подвела, значит и ещё раз подвести может. А раз так, то нужна другая система.
__________________
С уважением, Вячеслав |
|
30.03.2017, 22:28 | #17 |
Участник
|
Какой-то "крот" из конкурирующей конторы наверняка в MS завёлся и хочет добиться именно этого результата. Как пить дать.
__________________
Дмитрий |
|
31.03.2017, 00:19 | #18 |
Microsoft Dynamics
|
Цитата:
Было высказано мнение одного программиста из компании, в которой работают более ста тысяч сотрудников. Как говорится, «у нас все люди сложные, и к каждому свой подход нужен». В компанию приходят работать много разных людей. И программистов, и их начальников. У всех свои взгляды, свой груз, свой опыт. Ну не может быть мнения, с которым были бы все согласны. А на мой взгляд, чаще те, кто приходит в Microsoft принимать решения, до Аксапты разрабатывали другие системы. Это как один из источников свежих идей (мое личное мнение). Если вы, например, придете работать в какой-нибудь «САП» начальником, вы же тоже начнете с того, что будете реализовывать передовые идеи и любимые фишки из Аксапты, при этом не обращая внимание и ломая исторические «САПовские» застои. По крайней мере, я бы так и поступил. Работая уже три года на партнерах, я пока не встречал проектов, где была бы разрешена разработка на проде. Копируем время от времени прод на тест. Или просто копируем, если нужно что-то срочно починить. Как правило, такие случаи достаточно редки. Еще одна мысль, что для того, что бы принимать решения, нужно обладать более полной картиной и статистикой. Сколько кустомеров включили разработку на проде? А сколько – не включали и копируют данные на тест? Какие простои и потери у тех, кто дебажит на проде, а какие у тех, кто раскошелился на тест? ЗЫ. Я ничегошеньки не знаю про САП. Последний раз редактировалось AlexSD; 31.03.2017 в 02:04. |
|
31.03.2017, 00:40 | #19 |
Участник
|
Цитата:
а еще кстати добавил что нормальные программисты пишут логи, которые позволяют выявить ошибки без отладки Последний раз редактировалось trud; 31.03.2017 в 00:50. |
|
31.03.2017, 01:18 | #20 |
Участник
|
В Dyn365 for Operations уже активно используется саппорт через DRI, когда на проблему в облачном сервисе сразу "набрасываются" "специалисты", и в "короткие" сроки ее устраняют.
Это, конечно, медленнее чем самому в продакшне фиксить, но может и понадежнее будет.. Посмотрим, как это приживется когда заблокируют уже оверлейеринг |
|