1. Обзор

Это план управления качеством относительно SQLite.

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

Вдохновение для этого документа: DO-178B. Среди стандартов качества у DO-178B, кажется, есть самая высокая полноценность среди документов. Несмотря на это, сумма документации, необходимой для полного внедрения DO-178B, обширна. SQLite стремится быть ловким, и с этой целью, большая часть необходимой документации DO-178B опущена. Мы сохраняем только те части, которые действительно улучшают качество для проекта программного обеспечения с открытым исходным кодом, такого как SQLite.

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

1.1. Об этом документе

План управления качеством был первоначально составлен, пройдя описание продукции в разделе 11 DO-178B (страницы 48 - 56) и записав те элементы, которые казались относящимися к SQLite. Текст будет позже пересмотрен, чтобы отследить улучшения до качественного процесса SQLite.

2. План разработки программного обеспечения

Эта секция это комбинация плана сертификации аспектов программного обеспечения и частей плана разработки программного обеспечения DO-178B.

См. О SQLite для обзора программного обеспечения SQLite, что это делает и чем это отличается.

2.1. Жизненный цикл программного обеспечения

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

Нет никакого предопределенного цикла выпуска. Выпуски происходят, когда есть критическая масса дополнительных функций и/или исправлений ошибок. Исторически выпуски происходили приблизительно 5 или 6 раз в год. Пользователи SQLite получают новые выпуски с веб-сайта по мере необходимости.

2.1.1. Корректировочные версии

Выпуски регламентного техобслуживания SQLite содержат дополнительные функции, исполнительные улучшения и/или заплатки для некритических проблем. Номер версии для главных версий имеет форму "3.N.0" для некоторого целого числа N. Посмотрите здесь для деталей.

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

2.1.2. Выпуски патчей

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

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

2.2. История версий

Система документации автоматически поддерживает историю прошлых выпусков, а также полный список выпусков SQLite с резюме изменений.

2.3. График

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

3. Среда разработки программного обеспечения

SQLite написан на портативном коде C. Техническая разработка происходит на соединении Linux, Mac и рабочих станций Windows. Разработчики используют инструменты командной строки и сторонятся интегрированных сред разработки (IDE), когда это возможно. Все разработчики, как ожидают, будут быстры с командной строкой Unix.

Минимальная установка для компилирования и тестирования SQLite из канонических источников следующая:

• Компьютер с 32-битным или 64-битным адресным пространством. OS может быть Linux, Mac, Windows, *BSD, Солярис или иной.
• Компилятор C99, такой как GCC (включая варианты MinGW для Windows), Clang или MSVC.
• Текстовый редактор по выбору пользователя, поддерживающий текст UTF-8.
• Tcl version 8.6 или позже.
• Утилита "make" или "nmake" в Windows.

Язык скриптов Tcl используется, чтобы помочь перевести канонический исходный код на объединение и справиться с тестированием. Tcl не используется непосредственно самим SQLite (если не требуется выбором времени компиляции). Конечным пользователям источников объединения SQLite не нужен Tcl.

Собирая CLI, полезно, но необязательно иметь следующие сторонние библиотеки под рукой:

• zLib
• readline, editline или linenoise для редактирования командной строки.

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

• valgrind
• gcov

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

4. План проверки программного обеспечения

Процесс тестирования для SQLite описан здесь. Проверяющие цели включают:

• 100% MC/DC в готовой конфигурации
• Тестирование исходного и объектного кода
• Тестирование на многих платформах и с многочисленными компиляторами
• Тестирование Fuzz
• Кодовый контроль изменения
• Динамический и статический анализ кода

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

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

5. Управление конфигурированием ПО

5.1. Управление версиями

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

5.2. Жизнеспособность

Весь код заархивирован на трех отдельных машинах: https://www.sqlite.org, https://www2.sqlite.org, https://www3.sqlite.org. Эти машины располагаются в различных городах (Dallas, Newark и San Francisco, соответственно) и управляются двумя различными хостинговыми компаниями (Linode для первых двух и Digital Ocean для третьего). Это разнообразие предназначается, чтобы избежать единственного пункта неудачи.

Главная машина в Далласе https://www.sqlite.org/ является основным сервером и тем, который использует большинство людей. Другие две считают резервными копиями.

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

5.3. Хранилища

Источник SQLite разделен на многократные хранилища, каждое описано в отдельной секции ниже.

5.3.1. Исходный код SQLite

Исходный код SQLite и набор тестов TCL сохранены вместе в едином репозитории. Это хранилище это все, что требуется, чтобы строить SQLite. Исходное хранилище общественное и удобочитаемое анонимными пользователями в Интернете.

• Основное местоположение: https://www.sqlite.org/src
• Backup A: https://www2.sqlite.org/src
• Backup B: https://www3.sqlite.org/cgi/src
• GitHub mirror: https://github.com/sqlite/sqlite/

5.3.2. Источники документации SQLite

Источники документации включают текст документации и изображения со скриптами, make-файл должен был построить документацию веб-сайта SQLite. Этот документ содержится в источниках документации. Источники документа сохранены в отдельном хранилище, отличном от исходного кода. Исходное хранилище документации публично удобочитаемое.

makefiles и скрипты, используемые, чтобы произвести документацию, собирают текст из документов основания в исходном хранилище документации. Дополнительный текст извлечен из комментариев в исходном коде SQLite. Информация об освещении требований извлечена из специальных комментариев в наборе тестов TCL, который является частью исходного хранилища, и из комментариев в наборе тестов TH3, который находится в отдельном частном хранилище.

• Primary location: https://www.sqlite.org/docsrc
• Backup A: https://www2.sqlite.org/docsrc
• Backup B: https://www3.sqlite.org/cgi/docsrc

5.3.3. Тест логики SQL

Тест логики SQL это ряд тестовых скриптов, разработанных, чтобы показать, что SQLite ведет себя, как другие движки базы данных SQL. Эти тесты приняты в отдельном кодовом общественном хранилище.

• Primary location: https://www.sqlite.org/sqllogictest
• Резервные копии на частных серверах

5.3.4. Испытательный ремень безопасности #3

Test Harness #3 или TH3 это частный набор тестовых сценариев, используемых, чтобы проверить SQLite на 100% MC/DC в поставленной конфигурацию. Источники TH3 есть на тех же самых серверах, где другие хранилища SQLite, но отличаются от других доступностью. Код TH3 доступен только для разработчиков SQLite.

• Primary location: https://www.sqlite.org/th3
• Backup A: https://www3.sqlite.org/cgi/th3
• Дополнительные резервные копии на частных серверах

5.3.5. Dbsqlfuzz

Модуль dbsqlfuzz module это libFuzzer-fuzzer для SQLite. Dbsqlfuzz это SQL и файл базы данных в то же время. Dbsqlfuzz использует настроенный мутатор.

Dbsqlfuzz работает лучше при нахождении проблем, чем какой-либо другой доступный fuzzer. По этой причине это сохранено частным. Мы не хотим хакера, получающего доступ к этой технологии.

• Primary location: https://www.sqlite.org/dbsqlfuzz
• Backup A: https://www3.sqlite.org/cgi/dbsqlfuzz
• Дополнительные резервные копии на частных серверах

5.4. Результаты проверки программного обеспечения

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

Исходный код к программному обеспечению, которое управляет контрольными списками, сохранен в его собственном хранилище Fossil на https://www.sqlite.org/checklistapp.

6. Стандарты требований к программному обеспечению и данным

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

Текст документации (и следовательно текст требования) взяты от исходного хранилища SQLite Documentation, описанного выше, а также из комментариев во внедрении. makefiles, чтобы построить документацию находятся в исходном хранилище документации.

Когда документация собирается, требования определены и маркированы. Процесс сборки документации также просматривает тестовые скрипты, которые проверяют каждое требование, и строит матрицу, показывающую, какие требования проверяли, и определяет тестовые сценарии, которые проверяют те требования.

7. Проектирование программного обеспечения и кодирующие стандарты

Объективные кодирующие стандарты для SQLite минимальны:

• Отступ в 2 пробела.
• Максимальная длина строки в 80 символов.
• Без табуляций, только пробелы.

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

8. Проблемные отчеты

Все проблемы решены быстро. В программном обеспечении SQLite нет никаких постоянных проблем.

Система управления версиями Fossil, используемая SQLite, содержит встроенную поддержку отслеживания заявок на устранение неисправностей. Эта встроенная система используется, чтобы отследить и зарегистрировать много исторических проблем.

SQLite Community Forum это место, куда кто-либо в Интернете может пойти, чтобы задать вопросы или сообщить об ошибках SQLite. Об ошибках, найденных третьими лицами, часто сообщают первоначально на форуме. Сообщаемые форумом ошибки будут иногда передаваться в заявки, хотя часто проще иметь дело с ошибками на форуме. Форум имеет превосходную полнотекстовую функцию поиска, отражен на много машин, доступен для поиска и способен к выживанию как система, таким образом, кажется ненужным дублировать порожденные форумом отчеты об ошибках в систему заявок. Общественные местоположения форума:

• Primary location: https://www.sqlite.org/forum
• Backup A: https://www2.sqlite.org/forum
• Backup B: https://www3.sqlite.org/cgi/forum

Как с исходными хранилищами, форум также синхронизируется к различным частным машинам. Обратите внимание на то, что из-за логики работы Fossil "резервные копии" это больше, чем просто резервные копии только для чтения. Они могут также функционировать как вводы данных. Все введенное содержание синхронизируется ко всем хранилищам, независимо от того, которое хранилище используется для вставки.