No_name Опубликовано 27 октября, 2016 · Жалоба NetUP, ACP IDECO. Это решения разных "весовых категорий". А вот здесь, если можно, поподробнее ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tau Опубликовано 27 октября, 2016 · Жалоба А вот здесь, если можно, поподробнее ;) Ланбиллинг vs {NetUP UTM и IDECO}. Куда подробней. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Domingo Опубликовано 27 октября, 2016 · Жалоба К вопросу о тестировании и все остальном. 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 У нас эта ошибка тоже была, и тоже решилось новой сборкой. Научены опытом, по этому ставили на тесте. Наверно как то не так работаем с системой ;-) как мы понимаем Вы работаете у основного клиента использующего этот продукт – МТС. Если не секрет, скажите Вы получаете те же сборки что лежат на сайте или какие то другие? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 28 октября, 2016 · Жалоба Сейчас на Вашем сайте лежит 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 не проходит гладко. Каждый раз при апгрейде возникают какие-то косяки. Баги есть у всех, но в вашем продукте они проявляются слишком часто и судя по всему они это проблема архитектуры или организации процесса разработки и тестирования Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
anichka991 Опубликовано 29 октября, 2016 (изменено) · Жалоба как мы понимаем Вы работаете у основного клиента использующего этот продукт – МТС. Если не секрет, скажите Вы получаете те же сборки что лежат на сайте или какие то другие? Те же самые, только чаще. Для всех лежат только сборки, прошедшие регресс, для нас, в том числе пятничные. Ставятся, как правило, пятничные, но за счет того, что это происходит регулярно (именно регулярно, а не еженедельно), писков мало, а не как некоторые тут пишут, что раз в 10 лет обновились и у них "ничего гладко не прошло, а потому виноваты все кроме них, все что угодно, архитектура, организация процесса, качество разработки, тестирования и т.д. и т.п." Изменено 29 октября, 2016 пользователем anichka991 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
darkdimoss Опубликовано 10 ноября, 2016 · Жалоба Сейчас на Вашем сайте лежит 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 Между прочим сборка до сих пор доступна для скачивания. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 10 ноября, 2016 · Жалоба darkdimoss да я думаю можно не продолжать эту тему, с качеством разработки и тестированием(точнее, его отсутствием) и так уже всем понятно Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SyJet Опубликовано 12 ноября, 2016 · Жалоба Так в каком формате должны быть даты? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Domingo Опубликовано 30 ноября, 2016 · Жалоба Так в каком формате должны быть даты? Тоже интересно узнать. Про качество продукта и отсутствие тестирования много копий было сломано в теме http://forum.nag.ru/forum/index.php?showtopic=102449 Время прошло - все осталось по прежнему. Вообще работая с данным продуктом складывается ощущение что внутри все всех устраивает. А записи клиентов на форуме это какое то копошение, суета - хавают же. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Odissey Опубликовано 1 декабря, 2016 · Жалоба Черный пиар тоже пиар Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
darkdimoss Опубликовано 1 марта, 2017 · Жалоба Поделюсь опытом. Несколько месяцев назад, в связи с ухудшением качества оказанных услуг, было решено перейти на минимальный контракт поддержки. Так вот, по прошествию этих месяцев - на минимуме можно получать те же услуги, что и платя больше. Нужно лишь проявить настойчивость, и Вы получаете горячую линию со специалистами тп, ответы на запросы в нужный срок и подходящее время. Работу проводят сразу в БД или пишут нужные select/update/insert . Хотя раньше нас уверяли что так делать нельзя, используйте API, а еще лучше оплатите доработку. Так мы сэкономили на внедрение нужного функционала и платежных системах. Отмечу интересный момент, описанный в первом сообщении этой темы - регистрация как Тестовый клиента. Так вот, оказывается, ответы на свои запросы и настройку системы можно получать на таком пакете и в выходные дни. Которые не включены в платный пакет. Спасибо за подсказки. Что касается ошибки в данных абонентов, в которой нас уверяли выше. Проверили обновление старого бекапа 014 сборки с новыми сборками 020 и 021. И там эта ошибка не возникает. Как так?(Отчасти риторический вопрос). Надеюсь наш опыт поможет людям получать нужные услуги. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Domingo Опубликовано 3 апреля, 2017 · Жалоба darkdimoss Любопытные замечания. Попробовали. С тестированием интересно получается. Классическая модель развития наркозависимости - при тестировании ТП делается бесплатно(первая доза). Купили лицензию завали абонентов - все ТП платная, как тут слезешь. Но, как оказывается, есть и положительная сторона ... И время ответов действительно можно под свои нужды подстроить, а не по их расписанию. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
darkdimoss Опубликовано 7 апреля, 2017 · Жалоба Да, это так. Сейчас опробываю другие методы «общения» . Оказывается от общения с менеджерами может быть большая польза для дела. Если все получится и кому то это интересно, позже опишу процесс. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...