В разы ускорить выход обновлений продуктов. Исправление критичных ошибок.
Есть продукт - 1С-Битрикс. Время от времени в нем возникают критичные ошибки.
Одна из неприятных - это когда сайт вернул в 1С статус "перенос строки success", а 1С написала клиенту, что обмен завершился с ошибкой.
Мы считаем себя способными разобраться в проблеме клиента и прежде чем писать в техподдержку пробуем сами исследовать.
Такие мелкие, но очень досадные ошибки должны исправляться в тот же день, как были обнаружены. Эти ошибки отбирют наше время и сокращают жизнь. Ошибки должны быть описаны в описании к обновлению.
Зачем держать цикл разработки 2-3 недели, чтобы потом выпустить дополнение? Давайте выпускать обновление в тот же день, когда обнаружена и описана ошибка.
Одна из неприятных - это когда сайт вернул в 1С статус "перенос строки success", а 1С написала клиенту, что обмен завершился с ошибкой.
Мы считаем себя способными разобраться в проблеме клиента и прежде чем писать в техподдержку пробуем сами исследовать.
Такие мелкие, но очень досадные ошибки должны исправляться в тот же день, как были обнаружены. Эти ошибки отбирют наше время и сокращают жизнь. Ошибки должны быть описаны в описании к обновлению.
Зачем держать цикл разработки 2-3 недели, чтобы потом выпустить дополнение? Давайте выпускать обновление в тот же день, когда обнаружена и описана ошибка.
Кстати, да! Согласен с тем, что changelog для обновлений должен быть максимально детальным. Сейчас - "Исправлены некоторые ошибки" - совершенно не говорит о том, что именно исправлено.
Вообще, исправление ошибок должно идти отдельной линейкой обновлений. Новый функционал - да, хорошо, но исправление ошибок должно быть в приоритете.
Зачастую, некоторые ошибки исправляются через полгода-год. Для клиентов не работающий функционал, особенно если он ранее работал, ох, как критичен.
Да и выпуск нового "сырого" функционала - не хорошо. Анонсировали новые фишки, клиент повелся. И убеждай потом клиента, чтоб подождал годик, пока его доведут до ума или пока он хотя бы как-то начнет работать.
Зачастую, некоторые ошибки исправляются через полгода-год. Для клиентов не работающий функционал, особенно если он ранее работал, ох, как критичен.
Да и выпуск нового "сырого" функционала - не хорошо. Анонсировали новые фишки, клиент повелся. И убеждай потом клиента, чтоб подождал годик, пока его доведут до ума или пока он хотя бы как-то начнет работать.
| Зачем держать цикл разработки 2-3 недели, чтобы потом выпустить дополнение? Давайте выпускать обновление в тот же день, когда обнаружена и описана ошибка. |
| Ошибки должны быть описаны в описании к обновлению. |
В тот же самый день везде поправить практически нереально. Т.к. если бага в УТ ред 10.3, то как правило, нужно пересобирать модули 9 конфигураций (УТ, УПП, КА для России, Украины, Казахстана и Беларуси), а если бага в 11 ред., то в 4.. Это совсем не быстрый процесс
.
А по поводу багов.. Невозможно проверить все возможные варианты.
.
А по поводу багов.. Невозможно проверить все возможные варианты.
| В тот же самый день везде поправить практически нереально. Т.к. если бага в УТ ред 10.3, то как правило, нужно пересобирать модули 9 конфигураций (УТ, УПП, КА для России, Украины, Казахстана и Беларуси), а если бага в 11 ред., то в 4.. Это совсем не быстрый процесс . А по поводу багов.. Невозможно проверить все возможные варианты. |
© 2001-2023 «Битрикс», «1С-Битрикс». Работает на 1С-Битрикс: Управление сайтом.
Соглашение об использовании сайта
Соглашение об использовании сайта
Это работает и сейчас, если какой та баг не исправляется достаточно долго, значит баг не получил распространение и имеет место на конкретной установке.
В любом случае обращение в ТП желательно сделать, ведь от ваших обращений меняется регламент исправления багов.