[No_name]

NetUP, ACP IDECO.

Это решения разных "весовых категорий".

А вот здесь, если можно, поподробнее ;)

[Tau]

А вот здесь, если можно, поподробнее ;)

Ланбиллинг vs {NetUP UTM и IDECO}. Куда подробней.

[Domingo]

К вопросу о тестировании и все остальном.

 

mysql -uroot -p billing < /usr/local/billing/mysql/update.sql

ERROR 1318 (42000) at line 9378: Incorrect number of arguments for PROCEDURE backup_table; expected 2, got 1

 

 

 

У нас эта ошибка тоже была, и тоже решилось новой сборкой.

Научены опытом, по этому ставили на тесте.

Наверно как то не так работаем с системой ;-)

 

 

как мы понимаем Вы работаете у основного клиента использующего этот продукт – МТС.

Если не секрет, скажите Вы получаете те же сборки что лежат на сайте или какие то другие?

[s.lobanov]

Сейчас на Вашем сайте лежит 20 сборка, которую менеджеры рекомендуют к установке, которая прошла все тестирования, т.е финальный релиз.

Устанавливаем ее на тестовый сервис, и в ходе установки получаем такую ситуацию

 

mysql -uroot -p billing < /usr/local/billing/mysql/update.sql

ERROR 1318 (42000) at line 9378: Incorrect number of arguments for PROCEDURE backup_table; expected 2, got 1

 

Данная ошибка возникает на шаге проверки консистентности данных эталонной структуре при попытке исправить обнаруженные неверные значения в полях "дата рождения" и "дата выдачи паспорта". Обработка неверных значений в этих полях происходит через копирование исходной таблицы (вызов процедуры backup_table).

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

Как мы отписали в Тикете, проверка на повторение таких краевых условий добавлена в тесты. Теперь все сборки, проходящие тестирование, проверяются на этот кейс.

 

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

[anichka991]

как мы понимаем Вы работаете у основного клиента использующего этот продукт – МТС.

Если не секрет, скажите Вы получаете те же сборки что лежат на сайте или какие то другие?

Те же самые, только чаще. Для всех лежат только сборки, прошедшие регресс, для нас, в том числе пятничные. Ставятся, как правило, пятничные, но за счет того, что это происходит регулярно (именно регулярно, а не еженедельно), писков мало, а не как некоторые тут пишут, что раз в 10 лет обновились и у них "ничего гладко не прошло, а потому виноваты все кроме них, все что угодно, архитектура, организация процесса, качество разработки, тестирования и т.д. и т.п."

Изменено 29 октября, 2016 пользователем anichka991

[darkdimoss]

Сейчас на Вашем сайте лежит 20 сборка, которую менеджеры рекомендуют к установке, которая прошла все тестирования, т.е финальный релиз.

Устанавливаем ее на тестовый сервис, и в ходе установки получаем такую ситуацию

 

mysql -uroot -p billing < /usr/local/billing/mysql/update.sql

ERROR 1318 (42000) at line 9378: Incorrect number of arguments for PROCEDURE backup_table; expected 2, got 1

 

Данная ошибка возникает на шаге проверки консистентности данных эталонной структуре при попытке исправить обнаруженные неверные значения в полях "дата рождения" и "дата выдачи паспорта". Обработка неверных значений в этих полях происходит через копирование исходной таблицы (вызов процедуры backup_table).

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

Как мы отписали в Тикете, проверка на повторение таких краевых условий добавлена в тесты. Теперь все сборки, проходящие тестирование, проверяются на этот кейс.

 

 

Интересно получается, обновляясь на 18, 19 сборку у нас даты были правильные, а в 20 они стали не правильные. При этом при накате update нет предупреждения, что такие то даты у таких то абонов нужно исправить. К примеру как это показывает для логинов пользователей. А для исправления «кривых дат» даете новую сборку.

Так еще и пишите что у Клиентов при тестировании такой ошибки не было, но после того как ее нашли сами клиенты Вы делаете тест на эту ошибку.

 

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

 

PS Между прочим сборка до сих пор доступна для скачивания.

[s.lobanov]

darkdimoss

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

[SyJet]

Так в каком формате должны быть даты?

[Domingo]

Так в каком формате должны быть даты?

 

Тоже интересно узнать.

 

Про качество продукта и отсутствие тестирования много копий было сломано в теме

http://forum.nag.ru/forum/index.php?showtopic=102449

Время прошло - все осталось по прежнему.

Вообще работая с данным продуктом складывается ощущение что внутри все всех устраивает.

А записи клиентов на форуме это какое то копошение, суета - хавают же.

[Odissey]

Черный пиар тоже пиар

[darkdimoss]

Поделюсь опытом.

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

Нужно лишь проявить настойчивость, и Вы получаете горячую линию со специалистами тп, ответы на запросы в нужный срок и подходящее время. Работу проводят сразу в БД или пишут нужные select/update/insert . Хотя раньше нас уверяли что так делать нельзя, используйте API, а еще лучше оплатите доработку.

Так мы сэкономили на внедрение нужного функционала и платежных системах.

 

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

 

Что касается ошибки в данных абонентов, в которой нас уверяли выше. Проверили обновление старого бекапа 014 сборки с новыми сборками 020 и 021. И там эта ошибка не возникает.

Как так?(Отчасти риторический вопрос).

Надеюсь наш опыт поможет людям получать нужные услуги.

[Domingo]

darkdimoss

Любопытные замечания. Попробовали.

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

Но, как оказывается, есть и положительная сторона ...

И время ответов действительно можно под свои нужды подстроить, а не по их расписанию.

[darkdimoss]

Да, это так.

Сейчас опробываю другие методы «общения» . Оказывается от общения с менеджерами может быть большая польза для дела.

Если все получится и кому то это интересно, позже опишу процесс.