[decuplet]

Да боже мой, вам же говорят — раскатал виртуалку, забил туда 15к абонентов, работаешь. Через год надоело — раскатал другую виртуалку, вбил туда 17к абонентов, работаешь дальше. Какие проблемы? Установка — основные временные расходы.

[SyJet]

Реально пофиг что под капотом.

[vop]

"....

Вам не повезло. Специалист, который лечит, в отъезде, но есть второй – не хуже.

....

Лечение стоит дорого, но можно и не платить.

Нянечкам, сестрам обычно платят, но они ухаживают и так.

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

Но можно этого и не делать. Если вас не интересует результат.

...." (с)

 

:)

[s.lobanov]

Под капотом почти у всех биллингов блобы, которые чем-то там занимаются внутри себя(самая открытая часть биллингов это структура БД). Какой мне смысл вручную устанавливать кучу зависимостей, создавать вручную БД, что-то вливать в неё и т.д. и т.п.? Всё это вообще никак не относится к основному функционалу, а к администрированию ОС и вспомогательного ПО.

 

Вот например в случае сабжа(Ланбиллинг) - устанавливаешь его, добавляешь агента, пытаешься запустить, но нет! не всё так просто. ID агента в БД должен совпадать с ID агента в конфиге. и по дефолту ID агента в конфиге что-то типа 9. первый раз я пару часов убил на такую "неприятность"

 

Ну а когда речь идёт о свопе/выборе биллинга, то разбираться с инсталляцией каждого из них вообще нет никакого желания. Тем более, что у разных биллингов разные требования к ОС/БД/прочему софту, всё равно, скорее всего, придётся плодить кучу хостов под каждый.

[vop]

Небольшое отступление.

Некоторое количество лет назад, когда я еще предлагал свой биллинг на "рекламных площадках" и в форумах, примерно, на вскидку, процентов 75 интересующихся задавали вопросы, типа "а ваш биллинг настроит мне сервер доступа|микротик|почтовую систему|NS... и т.д." Пришлось объяснять, что биллинг - это не "робот-админ", который проделает за вас всю работу. :)

 

И по существу.

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

 

Но биллинг должен как-то "общаться" с услугами/сервисами, которые он учитывает, и которыми он управляет. А должен ли админ понимать, как работают его сервисы, и каким образом биллинг с этими сервисами контактирует? Должен админ знать, как работает шейпер? И как биллинг передает шейперу информацию? Мне кажется, что да, должен. Для этого и делается в биллинге service-API. Например, плагинчик, управляющий радиусом, не должен быть всемирной базой знаний для всех типов серверов доступа. Вот тут и проявляется роль админа, который, либо из примеров, либо из доков и накормит плагин нужными настройками.

 

Ну а с инсталляцией то чего разбираться. Запустил бинарничек, он все развернул, разложил, и готов уже работать. Ну, может, еще придется пароль админу придумать, да еще пару движений сделать из инструкции 1-2-3 в одну страничку длиной. :)

Изменено 6 апреля, 2015 пользователем vop

[~AsmodeuS~]

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

[vop]

Ну это решается вообще просто. Сервис-плагин сам "рассказывает" в автоматическом режиме все, что он умеет и что знает. Администратору биллинга надо всего-лишь указать, где находится сервис-агент. Для разного рода услуг есть разные сервис-плагины. Некоторые не требуют дополнительных настроек, некоторые просят указать дополнительные данные. Все зависит от сервиса. Например, плагин управления доменами через EPP протокол требует указания адреса сервера и параметров доступа (логин/пароль). А плагин почтового сервера на основе, например, того же dovecot, просит указать путь к каталогу с почтовыми ящиками. Ну и так далее. И если путь к почтовым ящикам можно предложить по умолчанию, то адрес epp-сервера по умолчанию не придумать.

[~AsmodeuS~]

только нужно чтобы эти плагины были реально, а не виртуально.

[alibek]

У меня используется Билл-Мастер.

И к нему тоже куча претензий была.

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

Более приятное впечатление разве что Гидра оставила.

[jp1111]

Сейчас используем Lanbilling 2. Около 2к абонентов ПД, немного телефонии, 15к абонов кабельного ТВ.

 

 

Уважаемый Александр, поскольку я не в первый раз сталкиваюсь с тем, что клиенты предлагают мне обсудить интересующие их вопросы в двух местах: приватно в почте и публично на форуме, я позволю себе, все же, процитировав свой ответ Вам здесь, расширить его комментарием относительно разработки той самой "незначительной фичи" как списание по дополнительным услугам. Но обо все по порядку.

 

Я внимательно ознакомился с Вашими вопросами, а также изучил содержание запросов Helpdesk №43593 и №44061. Постараюсь ответить на каждый из поднятых Вами вопросов в порядке их следования в оригинальном письме от Вас к Ирине.

 

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

Тем не менее, не хочу Вам отвечать "любезностью на любезность" и "проводить экскурсы". Хочу лишь заметить, что приведенный Вами пример разработки opensource софта, в т.ч. открытой ОС Debian не очень удачный в обсуждаемом контексте. Дело в том, что, такие важные аспекты как контроль качества, при разработке коммерческого ПО, в особенности, такого специфичного как биллинг, реализуются совершенно по разному, начиная с того, что в случае с opensource продуктом, разработчики - community, тестировщики - community, пользователи - также comunity и заканчивая тем, что в opensource разработке не существует обязательств в т.ч. и по срокам. Debian может себе позволить неограниченную по времени стабилизацию веток. Коммерческий продукт не может. Ключевое слово в этом предложении "неограниченную по времени".

Вы не правы, говоря, что в процессе разработки, который реализован в ООО "Сетевые решения" нет стабилизированных веток в которых исправляются только ошибки и веток с усовершенствованиями. Я не делаю секретов из наших внутренних регламентов и готов показать Вам выдержки из документа с номером РП0015 внесений изменений в код, который внедрен в нашей компании и из которого следует, что в зафиксированную сборку, путем применения merge request, инициированного разработчиком по отношению к руководителю соответствующего департамента, изменение может быть внесено только по факту исправления критической ошибки, степень критичности которой определяется в каждом конкретном случае индивидуально. Часто, в зафиксированную сборку запрещаетcя вносить даже те исправления, степень влияния на бизнес которых признается некритичной. В таких случаях, по инцидентам среднего и низкого приоритета изменения вносятся только в следующую не зафиксированную сборку.

Выдержка из РП0015:

 

«В случае необходимости внесения изменений в зафиксированную сборку как на этапе прохождения сборкой любого из 3 этапов тестирования так и в процессе ее продуктивной эксплуатации действует следующий порядок:

• Решение о внесении изменения принимается координатором изменений

• Допускается внесение изменений (временное открытие сборки для изменений), которые влияют только на инциденты категории №1 в терминологии договора технической поддержки (Не предоставление сервиса (Доступ в Интернет, Телефония, КТВ) более чем для 10% абонентов от абонентской базы Объекта (далее – «абонентская база»), вызванное некорректной настройкой и/или функционированием компонентов АСР LANBilling, вопросы приема платежей (менеджером или через интеграцию с платежной системой).»

 

В контексте я применяю слово "зафиксированную сборку", упрощенно этот термин можно читать как "размещенную в helpdesk и прошедшую ПМИ или программу-методику испытаний". Частью этой программы-методики является автоматизированная процедура юнит-тестирования, которая в силу биллинговой специфики просто физически не может быть выполнена менее чем за несколько часов. Кроме того, степень "покрытия" юнит-тестами кода не 100%, несмотря на то, что мы постоянно расширяем покрытие юнит-тестами кода и в составе компании существует выделенный департамент тестирования, в задачи которого входит исключительно эта задача. Хочу сказать, что с момента выпуска версии 2.0 до текущего момента степень покрытия выросла на порядок. Мы продолжим эту деятельность и, в любом случае, доведем степень покрытия кода до состояния, когда она будет гарантировать выявление того количества ошибок, которое удовлетворит большинство пользователей продукта.

Исходя из вышесказанного Вы справедливо можете задать вопрос «от чего же тогда Вы столкнулись с описанной ситуацией?». Выскажу свое мнение. В нем два аспекта.

 

Во-первых, чем дольше не обновляться, тем выше вероятность ошибки обновления. Этот тезис, надеюсь, не нужно пояснять. Большое количество изменений в коде, в СУБД, в обвязке помноженное на, выразим эту переменную как «вариативность пользовательских (операторских) данных/специфики применения» порождает существенную вероятность ошибки как в автоматизации этой процедуры, так и в ее применении (человеческий фактор тоже никто не отменял). Поясню примером. Я уже много лет являюсь приверженцем дистрибутива OpenSuse. Я его хорошо знаю и имею опыт эксплуатации различных версий с различными ядрами и пакетными менеджерами, НО ответственно заявляю, что даже при условии если Вы используете репозитарий Tumbleweed (как известно последнего стабильного софта для Suse) Вы не обновитесь гладко с версии OpenSuse 12.1 на текущую 13.2. И хорошо если Вы не налетите на более серьезные вилы, чем те, на которые Вы налетели при обновлении с 10 на 13 сборки LANBilling. А это «всего лишь» операционка с данными одного пользователя на диске. Можно спорить о вариативности применения ОС по сравнению с распределенной системой, такой как биллинг, но предлагаю оставить этот спор за скобками этого письма.

 

Во-вторых, обратите внимание по какой процедуре Вы устанавливали обновления с попытками исправить ошибки. Именно по той, что приведена в процитированном фрагменте регламента РП0015. Суть его в том, что при условии возникновения инцидента первого порядка у нас как у разработчика, который в отличие от Opensource разработчиков, обременен не только сроками по исправлению инцидента, но и штрафами за их несоблюдение по контрактам ТП, остается только одна возможность выполнить эти обязательства – отгрузить HotFix, который не проходит весь цикл тестирования и стабилизации, и естественно несет риски внесения ошибок при исправлении и диагностике критического дефекта.

 

Возникает справедливый вопрос «почему дефект в принципе оказался в стабилизированном и зафиксированном коде?». По нескольким причинам:

- ни одна из самых совершенных методик не гарантирует отсутствие ошибки даже в случае 100% покрытия кода тестами, это ясно, иначе бы ошибок в софте всего мира не было

- та самая вариативность применений. Даже предположив, что работа по покрытию кода юнит-тестами завершена сегодня, а не ближе к концу этого года, как мы планируем, мы при всем своем желании и стремлении не сможем отловить те ошибки, которые возникают в реальной эксплуатации на реальных потоках данных. Большинство юнит-тестов работают с «синтетическими» данными. Это означает их, в определенной степени, равномерность распределения в т.ч. и имитацию потока отказов. Мы не являемся оператором, к счастью или сожалению, мы не эксплуатируем продукт на реальной сети и, соответственно, не можем отловить те ошибки, которые отлавливаете Вы – операторы. Это не означает, что любой оператор это бета-тестер. Есть операторы, которые внедряют на определенных сегментах сети сборки первыми. Это не бета тестеры – это опытные зоны. И с такими операторами у нас есть специальные договоренности и финансовые в т.ч.

Причем в случае с описанным дефектом в запросе №43593 речь шла не о банальном дефекте, который весьма легко можно повторить, а об ошибке, которую лично я называю «плавающей» - сложно выявляемой ввиду неочевидных условий ее повторения. Поскольку я имею опыт работы в качестве инженера технической поддержки могу сказать ответственно, что ошибки такого рода диагностируются наиболее трудоемко и требуют такой конструктивной работы, которую Вы и продемонстрировали с нашим персоналом в указанном тикете. Больше того скажу – не с каждым клиентом это возможно ввиду мягко скажем «различной подготовки кадров». Я наблюдаю тенденцию в форумах в соответствии которой клиент хочет, что бы система работала вовсе без квалифицированного администратора. Искренне считаю, что в случае даже малого по нынешним меркам оператора это утопия. Также хочу отметить, что диалог, который я наблюдал в тикете между Вами и специалистами нашей компании не имел цели убедить Вас в том, что Ваша сеть или оборудование работает не по стандартам, а выявить реальную причину и дефект в т.ч. возможно, и в коде системы. Могу отметить, что в данном конкретном случае персонал действовал профессионально и просрочка по времени реакции была не существенной.

 

Завершая ответ на Ваш вопрос №1 хочу сказать следующее. Системе уже 14 лет. В будущем году исполняется 15. По меркам софта это серьезный возраст. Система, которая не развивается хотя бы пол года на рынке умирает, ибо не может соответствовать операторским потребностям. К сожалению, это так. Мы не можем позволить себе остановить разработку, на продолжительный период ввиду вышесказанного, однако стратегическим интересом нашей компании уже продолжительное время является повышение качества в условиях повышения сложности системы.

Вы спрашиваете «Будет ли ситуация изменяться в лучшую сторону?». Я отвечу так. Я не только верю в то, что мы решим поставленную задачу контроля качества, но и предпринимаю самые существенные усилия для этого. Включая минимизацию коммерческих разработок в угоду собственным интересам нашей компании – качество продуктов и, во вторую очередь, функционал для оператора. В частности, дополнительные меры, которые мы предприняли уже – внедрение анализаторов кода, которые уже существенно сократили количество ошибок «выходящих» за пределы департаментов разработки и продолжение их внедрения позволяет надеяться на еще более существенные результаты.

Резюмируя: причина возникновении описанной в Вашем письме ситуации не в отсутствии стабилизированной версии, которая по факту существует как на бумаге, так и в процессе нашей работы, а в существенной «глубине» обновления 10->13 и, пока еще, несовершенстве механизма тестирования кода. Первая причина может быть минимизирована с Вашей стороны, вторая может и, несомненно, будет минимизирована на нашей.

 

На вопрос №2 из Вашего письма, как мне кажется я ответил более чем развернуто выше.

Вопрос №3 касательно системы отчетности и документирования API.

Отвечая по принципу от простого к сложному скажу, что лично я не считаю существенным дефектом web интерфейса невозможность использования кнопки «назад». Почему-то почти все привыкли использовать только те элементы управления, которые нам предоставляют разработчики мобильных приложений для телефонов и планшетов, но почему-то привычка не распространяется на работу по сути в web2.0 приложениях в браузерах. Я считал и считаю, что нужно пользоваться теми возможностями, которые разработчик заложил в приложение. И если возможность использования кнопки «назад» не предусмотрена, то надо либо разработчика убедить в ее жизненной необходимости, либо использовать то, что есть. Но это лишь небольшая заметка на полях. Переделка всего административного интерфейса пользователя ведется уже больше года. Это очень существенный объем, причем на 80% выполненный. С 15 сборки мы предполагаем выложить в доступ beta интерфейс к системе отдельным пакетом (пока еще в этой сборке не покрывающий всего административного функционала), который будет функционировать через альтернативный JAPI. Это гарантирует его более высокую «степень отзывчивости» и «легкость», если хотите. При внесении таких существенных удобств, например, как «тянущийся» дизайн и новые элементы управления на существенно обновленном фрэймворке.

Что касается документирования API и существования API как такого. SOAP – относительно «тяжелый» протокол с кучей часто «ненужных» XML оберток. В особенности для работы web интерфейса. Но хотим мы того или нет – это доминирующий до недавнего времени протокол интеграции с большими системами. И цель этого протокола вовсе не в реализации отчетности или web интерфейса, а именно в интеграции со сторонними системами. Почему он не в достаточной степени документирован - потому что он объемен и, в первую очередь, документированию подвергались наиболее актуальные функции для целей интеграции. В то же время, работа текущей версии web интерфейса в действительности очень существенно может помочь в понимании работы отдельных функций API. Так же как и в вопросе покрытия юнит-тестами могу констатировать, что работа по документированию внешнего SOAP API будет доведена до конца.

 

По вопросу №4 касательно роста сети и опасений относительно стабильности продукта.

 

Я очень надеюсь, что вышесказанным я дал понять, что наша компания серьезно озабочена вопросом качества продукта и прилагает существенные усилия к его повышению, тем не менее я бы покривил душой сказав, что вот-вот и мы будем самой дешевой и стабильной в мире системой биллинга. Ошибки, к сожалению, будут, но я наблюдаю в повседневной работе как продвинутые операторы, которые эксплуатируют систему и на существенно более высоких объемах, чем у Вас минимизируют собственные риски «сидения на пороховой бочке». Минимизируют сегментацией, горячим резервом и пр. не менее эффективными способами. Полагаю, что любой администратор, который не хочет зависеть от качества продукта поставщика (нашего или нет, не важно) может и должен внедрить «систему страховки» на случай отказов ключевых компонентов. Я думаю не стоит убеждать Вас, что в сети не должно быть единой точки отказа в т.ч. даже если предположить, что у Вас есть RADIUS сервер с бесконечной нагрузочной способностью, я бы на Вашем месте не стал бы нагружать его всей сетью без средств его горячего резерва.

 

Что же касается реализации так названной "незначительной фичи" списания средств за дополнительные услуги без привязки к учетной записи, ситуация следующая: есть вещи (читать как "функционал"), который с пользовательсткой точки зрения может казаться незначительным. Однако любая система, в том числе и весьма сложная, реализуется в соответствии с выбранной архитектурой. Архитектура LANBilling была определена в 2001 году. То, что большая часть этой архитектуры работоспособна в 2015 году я считаю следствием удачного выбора. Однако, работа алгоритма списаний исторически была тесно завязана на ту объектную модель, реализация которой проходит через значительный объем кода, и в т.ч. достаточно низкого уровня. Я не говорю хорошо это или плохо. Это так. И мы, понимая, что операторам гораздо удобнее проводить списания дополнительных услуг без привязки к агентам и учетным записям, пошли на серьезную переделку и дестабилизацию системы в угоду операторского удобства. Делали, действительно, долго. Но сделали, получив по сути кучу негатива в угоду "небольшой фичи", как Вы выразились. Не думаю, что нас стоит за это упрекать.

 

В заключение хочу сказать, что, без сомнений, отказ системы раз в неделю – не норма, больше того, у нас достаточное количество клиентов, у которых не происходит подобного потока отказов. Частично и надеюсь полно ответил на Ваши вопросы, а также высказал свое личное мнение о возможных причинах возникновения сложностей. Замечу, что далеко не каждому клиенту возникает желание ответить столь полно и обстоятельно ввиду часто не конструктивности со стороны заказчика. В Вашем случае выражаю признательность за конструктив и имею желание ответить в том числе на вопрос, поднятый Вами на профильных форумах: на какую систему съехать с ланбиллинга?

В бытность мою работы на одну западную копанию я имел частое общение с ее владельцем, руководителем, идеологом, и по совместительству архитектором программного продукта для финансового сектора. Этот человек ныне миллиардер, очень известен и успешен в своей стране. В 2000 г. он сказал так «покупая программный продукт Владислав, ты покупаешь не набор бит и байтов, а ты покупаешь, фактически, подрядчика, от успешности и адекватности которого будет зависеть как работа его продукта, так и твой успех в той части, которая зависит от его ПО».

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

Наша организация с 2008 года по текущий момент снизила количество одновременно открытых тикетов ровно в 10 раз с 200 до 20 с небольшим. Обеспечивает круглосуточную работу департамента ТП, что делает мягко говоря не каждый вендор-производитель биллинга. Считаю, что это результат успешной и кропотливой работы по формализации и систематизации бизнес процессов внутри компании, которую мы и продолжаем.

[krot.androt]

Обеспечивает круглосуточную работу департамента ТП,

 

Я сомневаюсь, что у вас будет реально круглосуточный саппорт, а не спящий измученный инженер на телефоне после того как самый крупный заказчик в лице МТС откажется от вашего ПО, что произойдёт уже в 2016 году. Да и вообще, я думаю, вы можете развалится после ухода МТС от вас. Кстати, в чём причина того, что они от вас сваливают? Больше не могут терпеть биллинг, который даже в названии намекает, на то что его уровень это небольшие локалочки

[jp1111]

Обеспечивает круглосуточную работу департамента ТП,

 

Я сомневаюсь, что у вас будет реально круглосуточный саппорт, а не спящий измученный инженер на телефоне после того как самый крупный заказчик в лице МТС откажется от вашего ПО, что произойдёт уже в 2016 году. Да и вообще, я думаю, вы можете развалится после ухода МТС от вас. Кстати, в чём причина того, что они от вас сваливают? Больше не могут терпеть биллинг, который даже в названии намекает, на то что его уровень это небольшие локалочки

А в чем, простите, message то ? Буквы есть, а смысл от меня ускользает :) Смысл ветки, как мне казалось, обсуждение того "на что слезть". Хотите общения до такой степени, что аж на форуме не лень было зарегистрироваться, так я всгда готов - пишите. Если есть что посоветовать топикстартеру, так этот вовсе будет бесценно в контексте. Мне кажется не по теме написали. А что в 16 году будет, посмотрим в 16 году :), а то уже оскомину набила эта история с отказом с 11 года :), уж простите, привыкли как-то к ней. Вроде не заказчиков обсуждаем здесь, а альтернативы, что большинству реально полезно, как мне кажется.

 

Если же Вы хотите предложить тему "А что будет в 2016 году в условиях скукоживающегося рынка биллинга, скупаемых мелких и средних операторов связи, консолидации крупных, а не пойдем лм мы по пути многих стран мира где есть 5-10 операторов из большой десятки, а какой вектор движения телекома в нашей стране, заместим ли мы иностранный софт как того хочет г-н Никифоров, с каким качеством, сможем ли мы реализовать планы регуляторов о независимости рунета от "отцов основателей" так давайте создадим отдельную ветку не в форуме о биллинговом ПО, а где-то в профильном форуме, я приму в ней активное участие к слову сказать.

 

p.s.: Вас, Вы - обращение, с заглавной принято

Изменено 14 апреля, 2015 пользователем jp1111

[wed]

Тут не сколько на что слезть, как то - почему слезть.

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

Я тоже являюсь гм, тестером биллинга, с версии 1.8

и Вы знаете - с одной стороны Вы декларируете обновляйтесь - не тяните, больше разница между обновлениями больше багов.

а с другой - каждое обновление это боль.

Каждое обновление это "Мы это сломали, теперь как было раньше не будет, хотите сделаем под Вас коммерческую доработку" и это не считая того что при обновлении я работаю тестером и к каждым обновлениям выпускают фиксы.

Такое ощущение что клиентов вынуждают использовать не "доступ к обновлениям" а более дорогие пакеты обслуживания с их гарантированным решением проблем.

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

[SyJet]

и Вы знаете - с одной стороны Вы декларируете обновляйтесь - не тяните, больше разница между обновлениями больше багов.

а с другой - каждое обновление это боль.

Вообще LB надо брать за жопу, и в суд на них подавать, если есть баг в биллинге, и его исправили в след релизе - они ОБЯЗАНЫ давать обновления бесплатно, так как исправили работу ЗАЯВЛЕННОГО функционала при покупки. Кстати, наверно так в след раз и сделаю.

Изменено 15 апреля, 2015 пользователем SyJet

[wed]

Ну к этому в общем-то претензий особо нет.

Хотя с другой стороны да. Баги бывают разные и оценить какой баг критичный а какой нет - достаточно субьективно.

[s.lobanov]

и Вы знаете - с одной стороны Вы декларируете обновляйтесь - не тяните, больше разница между обновлениями больше багов.

а с другой - каждое обновление это боль.

Вообще LB надо браз за жопу, и в суд на них подавать, если есть баг в биллинге, и его исправили в след релизе - они ОБЯЗАНЫ давать обновления бесплатно, так как исправили работу ЗАЯВЛЕННОГО функционала при покупки. Кстати, наверно так в след раз и сделаю.

 

Судится со своим вендором ПО. И смысл? дальше конструктива не будет с ними, придётся искать другой. тогда уж проще сразу искать другой, ну или найти общий язык

[Andrei]

Использую ЛБ уже лет 5. Так, чтобы "вставал колом" вплоть до прекращения предоставления сервисов - такого не было (тьфу*3).

 

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

А вот под этим подпишусь. Это фактически "устранение брака по гарантии".

 

И еще жаль, что на их форуме совсем не появляется никто из представителей "Сетевых технологий" за исключением admin-а, который только постит сообщения о выходе новых сборок, но никогда никаких ответов не дает. Там пользователи ЛБ "варятся в собственном соку", делясь друг с другом опытом, наработками и проблемами. Жаль, что так. :(

[s.lobanov]

Andrei

Есть понятия комьюнити саппорт и есть пейд саппорт. каждый вправе выбирать сам - платить или аскать по форумам

[jp1111]

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

Некоторое время назад сборки публиковались редко (с периодом несколько месяцев) как с большим количеством изменений (исправлений), так и с большим количеством нововведений (читать как "фич"). Минусы такой системы - долгое время стабилизации, трудомкий процесс отладки, существование критических ошибок, исправление которых также дестабилизирует пакет. С 12 сборки было принято решение о существенном уменьшении периода публикации сборок существенно же сокращая при этом объем вносимых изменений. Плюсы - относительно небольшое время стабилизации, меньшая вероятность внесения ошибок, клиент получает большую "отзывчивость" на change request'ы. Сейчас этот период равен 6 неделям. 3 недели разработка - 3 тестирование и стабилизация. При этом же существуют аварийные сборки по инцидентам первого порядка и также LTS (Long Term Support) сборки в которые вносятся только исправления ошибок. В данный момент LTS сборка - 11. В соответствии с этой системой если клиент не хочет рисковать - он ставить LTS сборки, при этом не являясь никаким тестером, ни бета ни альфа. Если клиент заинтересован в новых функциях - ставит промежуточные сборки. Если случается критическая ошибка - ставит night build или аварийные сборки не прошедшие всего цикла тестирования с соответствующими рисками. В результате и по мотивам общения в частности с Александром, мы с большой долей вероятности увеличим период выпуска промежуточных сборок таким образом, что бы они проходили 2 цикла тестирования на опытных зонах до момента публикации, именно в целях повышения их качества. В связи с чем у меня возникает ощущение, что с описанной системой не все клиенты, банально, знакомы и, как следствие, вкупе с теми дефектами, что я описал выше Александру в ответе, влекут обоснованный негатив. Тему коммерческих или не коммерческих пакетов ТП я сейчас не затрагиваю, оставим это коммерсантам, меня больше интересует конструктивная критика изложенного выше.

[Andrei]

Andrei

Есть понятия комьюнити саппорт и есть пейд саппорт. каждый вправе выбирать сам - платить или аскать по форумам

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

[bos9]

При этом же существуют аварийные сборки по инцидентам первого порядка и также LTS (Long Term Support) сборки в которые вносятся только исправления ошибок. В данный момент LTS сборка - 11. В соответствии с этой системой если клиент не хочет рисковать - он ставить LTS сборки, при этом не являясь никаким тестером, ни бета ни альфа.

Новость для меня.. А как это согласуется с:

причина возникновении описанной в Вашем письме ситуации не в отсутствии стабилизированной версии, которая по факту существует как на бумаге, так и в процессе нашей работы, а в существенной «глубине» обновления 10->13

ведь логичное обновление с предыдущей LTS сборки до текущей будет слишком "глубоким".

[Andrei]

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

Это объяснение про периодичность выпуска сборок я где-то уже читал, возможно на этом форуме. Народ-то пишет о другом. Вот я сейчас на версии 2.0, а сборка аж 006. В ней были (и у меня пока остались) мелкие баги, но сервисный пакет кончился, баги исправлены в сборке 007, ее я разумеется скачать не могу - тут к вам претензий нет. Но и пофиксенной 006й сборки так и не вышло. В результате остались с официально купленным продуктом, недостатки (не доработки новых фич!) которого можно устранить только заплатив еще денег. Вот это имеющийся тут народ напрягает.

[s.lobanov]

> В данный момент LTS сборка - 11. В соответствии с этой системой если клиент не хочет рисковать - он ставить LTS сборки, при этом не являясь никаким тестером, ни бета ни альфа. Если клиент заинтересован в новых функциях - ставит промежуточные сборки. Если случается критическая ошибка - ставит night build или аварийные сборки не прошедшие всего цикла тестирования с соответствующими рисками.

 

Вы точно понимаете смысл обозначения LTS? Вот поставил я 11ую версию, прошло 2 года, случилась беда и тут вы говорите что надо ставить night build, где много чего переделано и внесены новые баги.

 

Смысл LTS в том, что в нём правятся все известные критические и важные ошибки вне зависимости от того в какой версии их нашли

 

Сколько время жизни будет у 11ой версии?

[GrandPr1de]

если клиент не хочет рисковать - он ставить LTS сборки, при этом не являясь никаким тестером, ни бета ни альфа.

Если клиент заинтересован в новых функциях - ставит промежуточные сборки. Если случается критическая ошибка - ставит night build или аварийные сборки не прошедшие всего цикла тестирования с соответствующими рисками.

у вас где-то связь потерялась, человек говорит - в LTS вносят правки по ошибкам и багам, всё что не в лтс - починка через ночные билды.

Вы точно понимаете смысл обозначения LTS? Вот поставил я 11ую версию, прошло 2 года, случилась беда и тут вы говорите что надо ставить night build, где много чего переделано и внесены новые баги.

[No_name]

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

Это объяснение про периодичность выпуска сборок я где-то уже читал, возможно на этом форуме.

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

Посмотрел в ЛК, там нету в доступе 11 сборки и из тех сборок , что представлены, ни фига не понять какая LTS, а какая нет.