В разы ускорить выход обновлений продуктов. Исправление критичных ошибок.

Рейтинг: 9.0893  
На голосовании
Предложил Зайцев Артемий 15.01.2014 15:17:19

В разы ускорить выход обновлений продуктов. Исправление критичных ошибок.

Есть продукт - 1С-Битрикс. Время от времени в нем возникают критичные ошибки.

Одна из неприятных - это когда сайт вернул в 1С статус "перенос строки success", а 1С написала клиенту, что обмен завершился с ошибкой.

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

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

Зачем держать цикл разработки 2-3 недели, чтобы потом выпустить дополнение? Давайте выпускать обновление в тот же день, когда обнаружена и описана ошибка.
Рейтинг: 0  
Ответил 01.04.2014 11:23:04
Критические баги получившие статус аварии, по регламенту исправляется в течение 5 дней.

Это работает и сейчас, если какой та баг не исправляется достаточно долго, значит баг не получил распространение и имеет место на конкретной установке.

В любом случае обращение в ТП желательно сделать, ведь от ваших обращений меняется регламент исправления багов.

Рейтинг: 1.5541  
Korban Michael 16.01.2014 08:54:38
Кстати, да! Согласен с тем, что changelog для обновлений должен быть максимально детальным. Сейчас - "Исправлены некоторые ошибки" - совершенно не говорит о том, что именно исправлено.
Рейтинг: 0.9757  
Малков Евгений 16.01.2014 12:24:49
Вообще, исправление ошибок должно идти отдельной линейкой обновлений. Новый функционал - да, хорошо, но исправление ошибок должно быть в приоритете.
Зачастую, некоторые ошибки исправляются через полгода-год. Для клиентов не работающий функционал, особенно если он ранее работал, ох, как критичен.
Да и выпуск нового "сырого"  функционала - не хорошо. Анонсировали новые фишки, клиент повелся. И убеждай потом клиента, чтоб подождал годик, пока его доведут до ума или пока он хотя бы как-то начнет работать.
Рейтинг: 0.5266  
Куклин Евгений 20.01.2014 09:46:18
Зачем держать цикл разработки 2-3 недели, чтобы потом выпустить дополнение? Давайте выпускать обновление в тот же день, когда обнаружена и описана ошибка.
Видимо не хотят усложнять себе жизнь, держа две ветки в разработке - новый функционал и фиксы "стабильного".

Ошибки должны быть описаны в описании к обновлению.
да это вообще... уже сколько раз просили и говорили, что информация в обновлениях - это песец, что-то там исправлено, а что - х его з
Рейтинг: 0  
Денисюк Александр 30.01.2014 16:13:12
В тот же самый день везде поправить практически нереально.  Т.к. если бага в УТ ред 10.3, то как правило, нужно пересобирать модули 9 конфигураций (УТ, УПП, КА для России, Украины, Казахстана и Беларуси), а если бага в 11 ред., то в 4.. Это совсем не быстрый процесс
.
А по поводу багов.. Невозможно проверить все возможные варианты.
Рейтинг: 0  
Шипулин Артем 30.01.2014 16:20:30
В тот же самый день везде поправить практически нереально. Т.к. если бага в УТ ред 10.3, то как правило, нужно пересобирать модули 9 конфигураций (УТ, УПП, КА для России, Украины, Казахстана и Беларуси), а если бага в 11 ред., то в 4.. Это совсем не быстрый процесс
.
А по поводу багов.. Невозможно проверить все возможные варианты.
Так ведь фраза "Давайте выпускать обновление в тот же день, когда обнаружена и описана ошибка." - утрированна. Суть сводится к тому, чтобы критические баги исправлялись настолько быстро, насколько это возможно.