[devel] ACL in branches

[Evgeny Sinelnikov]

4 марта 2009 г. 9:43 пользователь Денис Смирнов <mithraen at altlinux.ru> написал:
> On Tue, Mar 03, 2009 at 09:47:52PM +0300, Алексей Турбин wrote:
>
> AT> Он сегодня у них заработал, а завтра они сделали dist-upgrade и у них
> AT> всё отвалилось.  При том, что вроде бы ничего специфического у них не
> AT> обновилось.  Вы всё ещё не понимаете, что в момент сборки пакета
> AT> существовала специфическая build-time комбинация потенциально влияющих
> AT> компонентов; а в момент запуска существует уже иная специфическая
> AT> runtime комбинация влияющих компонентов?
> AT> Вам кажется что если админы протестировали то это уже стопудово
> AT> как минимум на месяц или два?
> AT> Мне тогда не понятно, что именно Вы хотите протестировать.
>
> Это ортогональные тесты.
>
> Я могу сейчас сделать пакет который будет идеален с точки зрения упаковки,
> обновления, и т.д. Только вот он будет 1 раз из 100 запусков делать dd
> if=/dev/zero of=/dev/sda.
>
> Пожалуйста, изобрети такую систему тестирования которая позволит ловить
> такие пакеты.
>
> Могу рассказать другой, уже реальный пример из жизни. Обновлял я как-то
> клиенту Asterisk. Все делали правильно -- работа в четверг вечером,
> планово все погасили, обновили, протестировали -- полет нормальный.
>
> Пятница -- полет нормальный.
>
> В понедельник подъем по тревоге -- зафиксировано больше 20-и падений
> сервиса за несколько минут. Я в шоке, ничего не понимаю, тестирование же
> прошло успешно! Делаю откат. Клиент смотрит злобным взглядом и дает понять
> что если я не объясню что произошло -- они меня прямо в серверной повесят.
>
> Разбор полетов показал что в этой сборке была ошибка вендора. Которая
> проявлялась один день в месяц с лишним. Связанная с обработкой даты. И в
> этот конкретный день попадали мнооооого серверов с астериском :)
>
> Если бы эта сборка была кем-то протестирована в течении полутора месяцев
> -- ошибка была бы выявлена.
>
>>> момент проверки в girar-builder. И мне глубоко наплевать насколько это
>>> мнение формально правильнее. Думаю, что не только мне. Возможно в вашу
>>> модель вкралась ошибка?
> AT> В нашу модель вкралась ужасная ошибка!  Ужас прямо, всё какой-то загон
> AT> и ужасные ошибки, только людям голову морочу.  Что мол то да сё, втираю
> AT> какую-то несусветную муть, а людям-то православным всего лишь надо, чтобы
> AT> пакеты у них работали.
> AT>     И нет исхода мне!
> AT>     Ох, тяжко, тяжко мне!
> AT>     Тяжко сознанье бессилья моего...
>
> :)
>
> Да, людям нужно чтобы работало. Системы автоматизированного тестирования
> которые ты пишешь решают целый пласт задач (причем, что характерно, таких
> которые _человеку_ поймать куда сложнее чем роботу).
>
> Есть еще целый пласт задач которые роботу поймать сложнее чем человеку.
>
> Создание инфраструктуры для полностью автоматического тестирования не
> только по формальным признакам, но и работоспособности -- это тоже
> интересная и полезная задача. Но _полностью_ нерешаемая принципиально.
>
> Да, я был бы рад если бы мог написать ряд скриптов описывающих логику
> тестирования, и чтобы после сборки в Сизифе пакет проходил ряд таких
> тестов. Это было бы хорошо и полезно. Но, увы, это тоже решит далеко не
> все проблемы.
>
> Скажем сейчас я не могу обеспечивть полноценное даже ручное тестирование
> Asterisk элементарно из-за отсутствие необходимого стенда. А стенд сделать
> который позволит его _более-менее_ полноценно протестировать стоит десятки
> килобаксов. _Полноценно_ -- несколько миллионов баксов. Хотя бы из-за того
> что тестировать надо совместимость по протоколам с целым списком
> оборудования, у которого очень страшные ценники. И что теперь мне делать,
> удавиться?
>
> С другой стороны есть люди, которые владеют какой-то частю этого
> оборудования. Они ставят и говорят "работает! ура!" "не работает!
> кошмар!", и это позволяет решать проблемы.
>
+1

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


-- 
Sin (Sinelnikov Evgeny)