Обеспечение качества в проекте OpenBSD

Так как я давно слежу за проектом OpenBSD и даже немного участвую в нём, то мне стало интересно: чем обеспечивается качество в этом проекте?

Я попробовал проанализировать процессы и собрать воедино все те вещи, которые способствуют повышению качества этой ОС.

Юнит-тесты

В базовой системе есть простой фреймворк для написания тестов bsd.regress.mk(5). Разработчики по возможности пишут тесты в src/regress. Правда в основной своей массе они представляют собой достаточно простые тесты, и, как следствие, не покрывают сложные конфигурации и не требуют настройки сложного окружения для запуска теста. Для Xenocara есть свои небольшие тесты, унаследованные от X.org.

Использование встроенных тестов в портах

Для 3rd party ПО в OpenBSD существуют так называемые порты. Если приложение, для которого делается порт, содержит тесты, то эти тесты используются при создании порта для нового приложения, при обновлениях порта на новую версию приложения и т.д. Новые порты принимаются только при успешном прохождении тестов. Я посчитал, что в -current OpenBSD около 8700 портов, и только в 2444 из них нет регресионных тестов. Таким образом гарантируется, что прохождение тестов гарантирует успешную работу ПО на новой платформе.

Механизм запуска тестов интегрирован в bsd.port.mk(5).

Call for testing

Добавление нового функционала сопровождается тестированием среди самих разработчиков, а также так называемыми call for testing, целью которых является призвать как можно большее количество пользователей для тестирования. Например keydisk-based softraid crypto volumes или PF internals redesign.

Eating your own dog food

На всех машинах, составляющих инфраструктуру проекта, используется OpenBSD и это само по себе является тестированием ОС. Вот комментарий на эту тему от espie@:

«You guys got to realize that actual builds, on real hardware, find a lot of bugs. In particular, missing dependencies in Makefiles and variations of these. These bugs are often highly timing-dependent. Having fast machines with slow disks, slow machines with fast disks, single processor oldies, multi-processor new things, 32 bit machines, 64 bit machines… every single new combination will exercise the build in a different way, and find new bugs.»

Ревью кода

Сложно переоценить значение ревью кода в открытых проектах. К тому же ревью кода увеличивает «bus factor».

Вот какие доводы приводит Danese Cooper в своей презентации Open Source Development In Practice (pdf):

  • «Massive peer review = more QA staff than you can hire»
  • «Massive peer review also promotes higher quality check-ins»
  • «Massive peer review means feedback is truly random»

Избавление от устаревшего кода

Разработчики стараются избавляться от устаревшего кода. Так, например, случилось с Kerberos, Bluetooth, altq, Apache. Обычно это случается, когда нет активного ментейнера для этого кода или есть альтернатива с более простой реализацией (как c altq или apache).

Обязательное тестирование на нескольких архитектурах

Платформозависимый код обязательно тестируется на нескольких архитектурах. В OpenBSD не используется кросскомпиляция кода вообще, в отличие, например, от NetBSD.

«You should try to test the driver as much as possible. Both Coherent/Incoherent DMA (ie i386/sparc64); Strict Memory Alignment architecture (ie sparc64/alpha); 32/64 bit clean (ie i386/amd64); Big/Little Endian (ie sparc64/i386).» - Driver Architecture and Implementation in OpenBSD:

Ежедневные снапшоты

Для выявления регрессий в процессе разработки собираются снапшоты для каждой архитектуры.

Полезные презентации:

Теги: softwareopensourceopenbsdtestingfeed

Новые

Все посты →