Сегодня памятная дата — прошло 25 лет с момента начала проекта Firebird.

Напомним как это начиналось. Многие кто работает с СУБД Firebird до 2000 года скорее всего использовали СУБД InterBase, из исходных кодов которого и появился Firebird. В 2000 году компания Borland приняла решение продолжить развитие InterBase как OpenSource продукт и открыла исходные коды своей СУБД, которой на тот момент пользовалось огромное количество программистов. Планировалось, что будет создана отдельная компания InterBase Software Corporation (ISC), которая будет заниматься развитием СУБД InterBase OpenSource отдельно от Borland, но в итоге от этой идеи отказались. Поэтому появился форк InterBase 6.0, а компания ISC переродилась в IBPhoenix. Символично название проекта — Феникс, восставший из пепла InterBase.

С 31 июля 2000 начинается история СУБД Firebird. И первое с чего начался проект это было исправление багов — версия InterBase 6.0.0.627 по количеству багов могла вполне считаться пре‑релизом. Теперь все исправления легли на плечи программистов Firebird. Поэтому первый релиз вышел только в 2001 году, до этого одной из альфа‑версий Firebird 0.95 достаточно активно пользовались.

Firebird был создан как форк InterBase и как это очень часто бывает тоже стал основой для другого форка. В конце 2001 года в результате объединения усилий группы российских разработчиков, использующих InterBase на Windows, на свет появился проект Yaffil.

После выхода Firebird 1.0 к участникам проекта пришло понимание, что дальше развивать проект на языке С будет не очень удобно и возникло решение переписать проект на С++. Firebird был переписан на C++ и под версией 1.5 вышел в 2004 году.

Постепенно в проекте стали преобладать программисты из России — Дмитрий Еманов, Александр Пешков, Николай Самофатов, Роман Симаков, Владислав Хорсун (Украина) и другие.

В 2006 году была создана компания РедСофт, которая своей задачей поставила создание форка Firebird, ориентированного на использование в государственных учреждениях. Форк был назван Ред База Данных и в 2007 году вышел под версией 2.0, основанный на Firebird 2.0. В 2012 году выпущена новая версия СУБД Ред База Данных 2.5 на основе Firebird 2.5, эта версия получила сертификат ФСТЭК. Ред База Данных стала первой СУБД, внесенной в Реестр программного обеспечения.

В 2009 году вышел ещё один форк Firebird — HQbird от компании ООО «Айбэйз» основанный на Firebird 2.5 и 3.0, включающий в себя не только встроенную репликацию, быстрый backup/restore и прочие важные отличия от ванильного Firebird, но и систему мониторинга FBDataGuard.

Более подробно о проекте и о том, как в него попали расскажут сами участники Firebird.

Дмитрий Еманов, архитектор СУБД РЕД База Данных и team-leader Firebird

Началось всё с того, как я закончил институт в 1999 году. На тот момент я уже два года как работал в закрытом «ящике» на Министерство обороны и там собственно познакомился с базами данных вообще, со средой программирования Delphi, благо Object Pascal мы в институте учили, да и в школе собственно тоже. Тогда и окунулся в мир СУБД, ну и с InterBase познакомился. Соответственно, на момент выпуска из института у меня уже был опыт разработки под InterBase на Delphi. Когда я выпустился, я решил поменять место работы, искал на рынке предложения и пошел собеседоваться в коммерческую компанию в моем родном городе, которая занималась в том числе, помимо консалтинга (который был их основным направлением), разработкой коробочного софта. У них уже был один продукт и планировали расширять эту тему, и искали программистов. Так как продукт изначально был ориентирован на малый и средний бизнес, цена решения играла первоочередную роль, поэтому у них возникла мысль использовать InterBase, потому что до этого у них разработки были на FoxPro. Соответственно, они хотели уйти с файл‑серверных на клиент‑серверные технологии, InterBase был просто самым дешевым среди доступных вариантом. PostgreSQL тогда и в помине не был известен в бизнесе, чисто научно‑университетская тема была. MySQL, естественно, был широко известен, но кроме как на веб‑сайтах, тоже нигде особо не встречался. Поэтому выбирали из чего‑то другого и в итоге выбрали InterBase. Я прошел собеседование, устроился на работу и начал писать софт на Delphi под InterBase, и как раз это было конец 1999 — начало 2000.

В 2000 году происходит выпуск InterBase 6 OpenSource, и для нас это было подарком судьбы, потому что можно было обнулить стоимость лицензии для клиента. Для нас это было очень важно и очень позитивным решением. Соответственно, мы тут же разработку с версии 5.6 переводим на InterBase 6 OpenSource Edition, тогда других и не было. По ходу дела, так как приходится почитывать списки рассылок на тему InterBase, я узнаю, что оказывается есть недовольные политикой Borland, что была основана InterBase Development Initiative, которая требовала вывести его из‑под контроля Borland. И заканчивается эта история тем, что был создан в конце 2000 года (в ноябре, если я не ошибаюсь) Firebird Project, вернее, в ноябре это как раз первая версия вышла, сам процесс чуть раньше произошел. В него вошло много разработчиков и технических специалистов из Borland, и вроде выглядело все так, что призывают всех использовать именно Firebird вместо InterBase. Всё это на моих глазах происходило. Нам‑то какая разница: бесплатный InterBase или бесплатный Firebird, но было непонятно, что из них как будет развиваться. По первым выпускам с багфиксами было понятно, что основная разработка уходит в Firebird, поэтому это выглядело более перспективным решением. Мы, так как API абсолютно одинаковый, переводим код на Firebird, не производя никаких изменений в клиентской части, и собственно решаем использовать именно его. Как раз выходила версия 0.9, 1.0, 1.0.2, и поехали.

Так как у меня был С‑ишный бэкграунд после института, то по ходу дела немного захотелось покопаться в сорцах — в первую очередь чтобы не ждать нового релиза после какого‑то багфикса, просто собирать его самому и включать в наш дистрибутив. Изучил схему сборки. Так как после того как собрал, надо убедиться, что код работает, еще и систему тестов пришлось изучать. До сих пор помню, там тестовые наборы назывались «что‑то там 24 часа», в том плане, что он выполнялся действительно почти сутки. Сейчас это тоже выглядит немного смешно, но в те годы это было именно так. И потом происходит финт ушами — Borland закрывает исходники InterBase, тогда уже становится понятно, что в ту сторону дороги обратной нет, ну а мы продолжаем сидеть на Firebird.

Пока суть да дело, разработка уже пошла под полуторку (Firebird 1.5), наш софт начали переводить на неё. Возникает желание что‑то где‑то дописать, где‑то не хватало функциональности, и хотелось это сделать. Специально, кстати, сегодня погуглил, нашел, что мой первый коммит был в 2001 году. Какая‑то мелочевка по сборке, чей‑то патч я там применил. Абсолютно не помню, когда и за что мне дали права доступа, скорее всего, это было автоматически, то есть я добавился на SourceForge проект, кто‑то там рассмотрел и принял. Потому что тогда много народу занималось кодом, спокойно принимали новых желающих и так далее. Из текущей команды, по‑моему, только Алекс Пешков в проект пришел до меня. Но примерно в том же, наверное, году — либо в конце 2000-го, либо в начале 2001-го. Потому что я помню, что когда список рассылки разработчиков читал, то его уже встречал там, он тоже обсуждал свой первый патч. И вот что, кстати, интересно, до сих пор не помню, почему его патч закоммитил я. То есть в 2001 году приземлилось то, что тогда называлось EXECUTE VARCHAR, а теперь известно как EXECUTE STATEMENT. Соответственно, это была разработка Алекса тоже для своих нужд, не хватало ему динамического SQL. Почему его закоммитил я — убей, не помню. То ли я именно право коммита получил первым, то ли мы как‑то с ним списались и review я делал его, в общем не помню, но почему‑то закоммитил я. И собственно в 2001-м наверное особо ничего больше и не было с моей стороны. Хотя попытка таки была и это тоже замечательная байка — мой первый патч, который я в Firebird прислал, не приняли тогда и его нет до сих пор в коде. Это поддержка параметров в событиях, то, о чем все страдают уже 20 с лишним лет. Мы тоже страдали в 2000 году, очень хотелось это получить. Я вроде как разобрался, как это сделать, сделал, и Джим Старки жестким образом меня отшил, сказал, что я ничего не понимаю в архитектуре и что так делать нельзя. Ну, наверное, у кого‑то бы на этот момент сразу бы отпало всякое желание продолжать контрибьютить в Open Source, но наверное я был достаточно «толстокожий», меня это не сильно задело, но при этом как бы поднапрягло немножко — типа, а что я такого не понимаю‑то, что меня тут носом тычут, надо разобраться. Я понимал, что я новичок и наверняка что‑то упускаю. Полез разбираться, но отвлекся. Потом, естественно, как и у большинства тех, кто начинали кодить с Firebird — это добавление каких‑то функций встроенных, или расширение существующих, где‑то в парсер чуть‑чуть добавили, какой‑то новый функционал по мелочам. Начал этим заниматься, потом переключился на какие‑то другие вещи, тоже с SQL языком — надо было расширять его. Одного не хватало, другого, что‑то из стандарта новое притянули, что‑то у конкурентов подсмотрели. И в какой‑то момент я понял, что мне это кайфово, мне нравится, мне этим хочется заниматься. И, собственно, занимался я этим, наверное, часа по четыре в день точно после работы.

Тогда произошли несколько неприятные изменения в проекте. Ну как неприятные, скорее непростые — назовем это так. Firebird 1.0 был выпущен на базе абсолютно того же исходного кода, что Interbase 6.0. Код был абсолютно чисто С‑ишный. А как раз та бригада, которая, уже уйдя из Borland, начала усиленно копать Firebird, они, естественно, решили обновить код и перевести его на C++. Естественно, делалось в отдельной ветке, чтобы ничего не сломать, и много всего перелопатили. Естественно, это не просто так и не потому что это стильно‑модно‑молодежно. Нет, ничего подобного. Просто потому, что любой, кто работал с С‑ишной обработкой исключений, знает как это жесть. Все эти long jump'ы, это просто врагу не пожелаешь разбираться с таким кодом. Это раз. Во‑вторых, нам понадобилась своя библиотека классов. Ну, вернее, для начала вообще библиотека классов. Тогда мы поддерживали и FreeBSD, и NetBSD, и Solaris в разных вариантах (и Spark, и Intel), HP‑UX, AIX. В общем, весь зоопарк Unix‑ов поддерживался, ну и понятно, что Windows тоже. И когда переводили код на C++, решили, что мы же теперь умные, у нас теперь есть богатая библиотека шаблонов STL C++, которая позволит все эти вещи на себя взять. Все было бы замечательно, если бы оно работало. Компиляторы тех времен не отличались, я бы сказал, ни умом, ни сообразительностью. На половине платформ что‑то работало, на половине падало или работало не так. В общем, глюков мы огребли от использования STL немеряно просто. И какие‑то базовые шаблоны оказалось проще написать самим. И тут возникла такая не очень хорошая ситуация — те ребята, которые это все начали пилить, у них запал свой закончился, и они отвалились. Кто‑то перешел на ленивый режим, кто‑то вообще пропал и так далее. И мы остались с кодовой базой полуторки, переписанной на С++, которая на Windows даже не собиралась, на Linux собиралась и проходила там большую часть тестов, но не все. Под экзотику там тоже зачастую либо не компилировалось, а если компилировалось, то не работало. И нет никого все это доводить до ума. Пришлось начинать мне, потом уже подтянулись Алекс, Коля, Влад — и работа пошла. И в принципе мы код из этой ямы вытащили, выпустили в конечном счете полуторку, хотя и очень долго ее стабилизировали. Ну и соответственно дальше уже просто по накатанной пошло, чем дальше, тем веселее, уже глубже закапывались в функционал. Безусловно, что когда хорошая команда под рукой, когда всегда есть кто‑то равный тебе по возможностям или даже круче, то кодить намного легче, чем когда ты ощущаешь себя в брошенном состоянии с непонятно чем.

Уже намного позже я вернулся к вопросу с параметризованными ивентами, понял, почему мне сказали на это забить, выкинуть мой патч и закопать его. Понял, что было сделано не так, понял, как это можно сделать правильно, но это наверняка сломает API‑совместимость, то есть под это нужно писать новый API. Соответственно, в те времена, когда еще не было объектно‑ориентированного API, был только один старый, и он поддерживался всеми библиотеками, никто эти библиотеки расширять даже и не думал, потому что они были одни под InterBase и под Firebird, и никому как бы и не надо было в них лезть. Соответственно, это было просто нереальной задачей, и, собственно, я на этом и забил. Ну, частично потому, что я уже перестал быть клиентом этой фичи. На тот момент я уже втянулся в разработку настолько, что решил уходить из своей компании и заниматься только Firebird. А задач в коде в ядре было достаточно много и без этого. И вот как‑то оказалось так, что эта фича не была принята тогда и не сделана до сих пор. Хотя сейчас уже понятно, как ее можно сделать и вроде как даже есть технические возможности в новом API под это новые интерфейсы реализовать. Возможно, все‑таки дойдем до этого, потому что в трекере она все еще висит. Такая вот интересная история. Были еще, конечно, всякие трудности с кодом, потому что документирован он плохо, только на уровне комментариев, и в них тоже не всегда понятно, что имелось в виду. Соответственно, порог вхождения высокий, копать тяжело, но со временем, естественно, потихонечку все это раскапывалось.

Была еще ситуация — не совсем в начале, а чуть попозже — когда пара российских ребят, Олег Иванов и Алексей Карякин, сделали первый форк Firebird — просто из‑за того, что у них было свое видение, как писать некоторые вещи и оптимизировать. Оно не совпало с мнением команды, в первую очередь из‑за того, что они любили оптимизировать все на ассемблере, а так как у нас была кроссплатформенная инфраструктура, это был очень жесткий геморрой, и писать на Assembler для конкретной платформы не хотелось от слова никак. А у них только под Windows был интерес, они пару патчей предлагали, их не приняли, ну они взяли и форкнули. Код назвали Yafiil — насколько помню, это что‑то типа зеленого дятла, тоже в орнитологическую тему ушли. И какое‑то время развивали этот форк, добавляя туда какие‑то небольшие фичи, оптимизируя какие‑то алгоритмы. Я тогда сильно это не одобрял, просто потому что тема с форками тяжелая — это распыление усилий, которые могли бы быть направлены в единое русло. Но там сразу пошла тема как это монетизировать, давайте мы его будем продавать клиентам и так далее. В какой‑то степени возникла конкуренция, по крайней мере внутри России, потому что в комьюнити эти ребята были известные, форк тоже был на слуху, кто‑то его тестил. Конкуренция в данном случае, наверное, была все‑таки положительной стороной — в том плане, что она меня немножко подстегнула побыстрее какие‑то вещи делать, поактивнее развиваться. В конечном счете история с Yaffil просто закончилась сама собой, потому что Firebird стал активнее конкурировать в других фичах, да и большая команда все равно добавляет больше вещей, чем один‑два человека. А Олег с Алексеем тоже своими делами были заняты, это не было их основной работой. В конечном счете Yaffil как бы самоустранился и код был передан проекту Firebird, за что им большое спасибо, что все спокойно разрулили. Я портировал их доработки в код Firebird, на тот момент почти все фичи по языку мы уравняли и даже обогнали, но у них было много наработок по встроенным функциям, которые мы включили, по‑моему, в версию 2.1 в итоге. Оптимизации тоже попали в код, пусть и не все. Ну, собственно, вот так эта история и закончилась. Потом пошли релизы 2.5 и так далее — там тоже можно много чего рассказать, но это уже совсем не про начало будет.

В проект full‑time я влился примерно в 2005 году. Первый год у меня был просто на изучение кода, на знакомство с community, на чтение список рассылки. Потом я начал втягиваться, первые патчи предлагать. Потом мне предложили со стороны проекта грант на определенную сумму — как компенсацию нескольких часов в месяц, которые я мог тратить не уходя с основной работы. Потом по сути я перешел на part‑time и мне грант увеличили, примерно 20 часов в месяц по‑моему я тогда мог позволить тратить на это все. Ну и в итоге я просто ушел на full‑time в Firebird.

Точно помню что с Николаем Самофатовым пилили вместе полуторку. Он вроде подключился не в самом начале, а уже ближе к бета‑версиям. Какой это был год? Хороший вопрос, это было давно, я уже не все детали помню. Влад подключился в 2003, если я правильно помню. Адриано попозже. Роман Симаков тоже пришел попозже. Мы как‑то с ним списывались, он интересовался кодом, вроде тоже хотел что‑то контрибьютить. Потом пришла очередь их форка, Ред База Данных, который тоже сначала появился в некоторой степени из‑за разногласий между разработчиками, а также желанием продавать кастомную версию СУБД, доработанную под определенные задачи. В отличие от первого форка — Yaffil — Ред База Данных все еще жива и активно развивается, мы вернулись с ними в русло конструктивного диалога в конечном счете. В итоге я присоединился к команде Ред База Данных, чтобы вместе и Ред База Данных развивать, и Firebird соответственно тоже — как базовый «родительский» продукт.

Дмитрий Кузьменко, генеральный директор iBase.ru

Гм. Долгая история, Firebird‑у то 25 лет… Родился я в городе Горьком в 19…

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

И я в основном читал всякую литературу (брал в библиотеках!). В 1986 году мне попалось издание «Тиори и Фрай, Проектирование баз данных» (в двух томах). И я прямо запал на вот эти всякие алгоритмы хранения и доступа.

А потом выходит Turbo Pascal Database Toolbox. И там прямо реализованные алгоритмы работы с индексами, и т. д. И я начал на Pascal с этим всем экспериментировать.

Дальше я попал на СМ1420 с системой ДИАМС. И еще больше подружился с базами данных. Ну и, в 1994 году начал работать консультантом в Epsylon Technologies.

А там как раз подоспел Interbase 4 для Windows. Часть документации про транзакции прочитал раза четыре.

Общался с группой разработчиков InterBase, и в т.ч. InterBase продавал (и знакомился с другими SQL‑серверами).

И тут вдруг, 1999 год. InterBase рассыпается, в том смысле, что уходят ключевые руководители проекта, что дальше делать — непонятно. Но в то время стал популярным OpenSource. И внезапно Inprise (бывший Borland, а потом Embarcadero) выкладывает InterBase 6 в OpenSource.

Вообще в тот момент куча людей думала, что Интербэйзу конец. Подробно про все эти события можно почитать тут — ibase.ru/ibhistory

Ключевой момент еще в том, что в это время были сплошные метания — и группа «Спасем InterBase» (IBDI), и новая компания для разработки InterBase, то исходники открываем, то не открываем, то еще что (потом InterBase исходники закрыл).

Главное, что исходники InterBase вовремя скопировали, и выложили их уже как Firebird. Название понятно почему такое, исходя из всех этих событий.

Разумеется, я во всём этом активно участвовал.

Yaffil. Когда исходники Firebird стали отдельными, сообщество впало в некий ступор, что с этим делать, и главное, как финансировать разработку (Firebird Foundation был создан только в декабре 2002г). Были идеи продавать кружки и майки с логотипами, но тогда это было смешно (по крайней мере мне).

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

Мне тогда идея показалась интересной, но я сразу понял, что например, на 10ти разных клиентах мы просто помрём в разработке — хоть это и будет дорого, но будет нужно разным клиентам, и в конце‑концов всё это пересечется. Поэтому я предложил сделать тиражируемый продаваемый продукт в виде «усовершенствованного Firebird». Олег предложил для форка простое название — Yaffil (зеленый дятел). Со временем к разработке Yaffil подключился и Алексей Карякин (на тот момент автор ODBC‑драйвера).

Идея Yaffil была в следующем — мы делаем его только для Windows, в основном Classic, но и SuperServer, платный, продаем только в РФ. Исходники публично не выкладываем, но если кому надо — отдадим. Но никому, конечно, исходники были не нужны.

Сообщество Firebird в тот момент возбудилось — как так, мы тут без денег, а какой‑то русский продает fork, и в ус не дует. И даже некая Nancy Cohen взяла одновременно интервью по этому поводу как у Анны Харрисон, так и у меня (первое — «War and Pieces», второе — «Commerce and Controversy». Но судя по всему, эти интервью уже сгинули в пучине Интернета (вовремя я копии сохранил)).

Люди подумали, что мы «хотим захватить мир» — в тексты обоих интервью затесалась информация о поддержке наборов символов (character sets) для стран Балтии и Украины, но это относилось не только к ним — Олег в билде 811 добавил плюс к этому чарсеты арабского, иврита и вьетнамского (и все это потом перешло в Firebird). Эти кодировки просили именно в РФ, а не за рубежом.

Конечно, я не собирался открывать никакие валютные счета, и как раз главным позиционированием Yaffil было то, что он только для России — мы не собирались лезть за рубеж и конкурировать с Firebird. Так что Yaffil нигде кроме РФ никогда не продавался.

Одновременно Олег Иванов придумал сделать embedded‑версию, поскольку все предпосылки к этому были еще в InterBase 4. И мы выпустили бесплатный продукт под названием Yaffil Personal, который оказался крайне популярным.

Замечу, что Олег и Алексей всё это время тесно сотрудничали с командой разработки Firebird, и мы передавали код обратно в Firebird, так что ни о какой «закрытости» Yaffil речи не шло.

Что было в Yaffil интересного — оптимизация сетевого трафика, улучшенный оптимизатор запросов, лучше работа с файлами сортировки, ускоренная работа с индексами, индексы по выражению, более быстрый бэкап‑рестор, улучшенная совместимость по ключевым словам с предыдущими версиями, и прочее, прочее. (полностью список улучшений есть в документации по Yaffil). Так что люди, покупая Yaffil, оплачивали крайне полезные разработки.

Но к концу 2003 года стало понятно, что Firebird уже достаточно окреп, а кроме того, там переводили исходный код с C на C++, а весь код Yaffil оставался на C. И мы решили остановить разработку Yaffil, и влить весь полезный код в Firebird 2.0 (см. пресс‑релиз). Это произошло как раз перед выпуском Firebird 1.5 (примерно февраль 2004г). А Embedded‑вариант за время существования Yaffil Personal стал настолько популярным, что появился в Firebird 1.5.1 (июль 2004г). Нынче Firebird Embedded — крайне востребованный продукт (об истории и смысле Embedded здесь).

Надо заметить, что те времена были довольно бурными. Если Олег Иванов и Алексей Карякин добавляли новые фичи в Yaffil по своему усмотрению, то в отношении разработки Firebird туда постоянно влезал Джим Старки (автор InterBase), и по сути мешал разработке, утверждая что «вы всё делаете не так». Он в то время разрабатывал новый вариант InterBase под названием Vulcan, но при всём уважении, это кончилось ничем (кому‑то исходники Vulcan Джим всё‑таки продал). Конечно, часть этих идей была реализована в Firebird 3, но…

Да, еще была забавная вещь — где‑то в районе 2007 года на sql.ru появился человек, который утверждал что вот‑вот, скоро‑скоро появится новый клон Firebird, супер‑крутой, который всех победит, и под названием Nagano. Но так ничего и не случилось, никто ничего не увидел.

Ред База Данных. В 2006 году мы (iBase.ru) встретились с группой людей, у которых идеей была продвигать Firebird для государственных структур. Я относился к этому крайне отрицательно (и до сих пор у нас с госструктурами практически нет контрактов), поэтому решили, что мы не пересекаемся, но всё же нужно обмениваться кодом, в том числе и с Firebird.

HQbird. Вначале в iBase.ru возникла идея создать инструмент, который мог бы автоматизировать рутинные задачи для администратора — бэкап‑рестор, свип, и прочее. К тому же у Алексея Ковязина был инструмент для ремонта БД (FirstAid), и другие инструменты, которые мы включили в комплект. И так HQbird появился в 2009 году. А в 2010 году в комплекте уже появилась модифицированная версия Firebird, с добавками для корпоративных клиентов (ну, можно сказать, как Yaffil).

А потом пошло‑поехало — и репликация для Firebird 2.5/3.0, и дополнительная функциональность, и т. д. С Firebird то же самое сотрудничество — например, репликация, которая была отработана на 2.5 и 3.0 переехала в бесплатный Firebird 4 и 5, пул внешних коннектов, и прочее. И постепенно те возможности, которые появляются в HQbird, переходят и в общедоступный Firebird. Но для появления таких возможностей всё‑таки требуется исходное финансирование.

А что касается InterBase — хоть там и появилось много всяких интересных штук, полезных для бизнеса, за последние 10 лет (на 2025 год) он почти полностью потерял рынок в РФ. Там просто не успевают ни за Firebird, ни за Ред База Данных и HQbird. И я считаю, что это именно результат выхода из Open Source, и отсутствие общения с другими разработчиками.

Роман Симаков, менеджер продукта РЕД База Данных и директор департамента развития системных продуктов РЕД СОФТ

В 2006 году я уже закончил аспирантуру, защитил диссертацию, в институт обратились тогда люди, которые организовали компанию Ред Софт, она в общем‑то только появлялась, думали, где брать сотрудников. Вот тогда собственно выбор пал по некоторым рекомендациям на нашу кафедру в нашем институте, приехали, познакомились, и так я попал в проект. Надо было делать СУБД. Firebird уже был выбран, потому что одним из основателей Ред Софт был Николай Самофатов, он же главный технический руководитель и вдохновитель. Он же уже разрабатывал Firebird, у него уже была компетенция, к тому времени он уже много патчей влил, много где руку приложил к разработке. Но, собственно, почему еще Firebird? Потому что на тот момент, в общем‑то, СУБД Open Source и не было. PostgreSQL — это академическая тема была в районе 2000-х годов, это, в общем, совершенно не та СУБД, которую сейчас мы знаем. Надо сказать про Firebird то же самое. Те, кто думает, что это СУБД из 2000-х, они тоже сейчас очень сильно ошибаются. Поэтому, если мы говорим опять же о том времени, то Firebird — это наследие крупнейшего игрока в IT, это компании Borland, которая развивала и свои сервисы, и свои инструменты, и свои средства разработки. Одни из лучших компиляторов, если не лучшие были мировые в тот момент — это были её компиляторы. Вся страна изучала язык программирования Delphi, инструменты разработки и так далее. Поэтому, безусловно, все знали и умели ей пользоваться — это InterBase, и все семейство Borland. Основой Firebird по сути были исходники коммерческой СУБД, которые стали открыты. MySQL на тот момент тоже в общем‑то был для сайтов, без транзакций, без каких‑то там хранимых процедур, то есть особо сложных проектов на нем тоже не сделаешь. Firebird собственно был безусловным, наверное, лидером в мире коммерчески доступных лицензионно неограниченных бесплатных Open Source дистрибутивов СУБД, для которых есть вся экосистема для разработки.

Я попал в Ред Софт и сразу по сути попал в проект Firebird. Что дальше? Дальше первые попытки его как‑то скомпилировать, помню, собирали мы его дня три. Причину почему так долго не помню, видимо, попали на нестабильную мастер‑ветку. Так или иначе долго провозились. Первый патч, первые робкие попытки что‑то потрогать в коде. Переписка на английском языке была очень непривычной историей. Помню первое письмо, нашел я баг, долго, полдня составлял письмо, как там правильно его оформить, чтобы отправить его в сообщество, чтобы посмотрели, что там где не так. Ну, ответ — все просто: «Да, спасибо, Роман. Это действительно баг.» Подтвердили, исправили, патчик в одну строчку. Но почему‑то запомнилось. Ну, потом все сложнее, сложнее. То есть появились какие‑то первые фичи. Тот же самый nbackup. Тоже долго пришлось в него погружаться, потому что, по сути, надо было изучить, как работает движок, все эти блокировки, все эти состояния страницы. Конечно, параллельность очень сильно осложняет разработку, но в то же самое время делает, наверное, ее интересней. Дальше уже появляются новые люди, появляется сертификация ФСТЭК, появляются доработки безопасности. Начинаем больше уделять внимание тестированию, документированию, русскоязычной документации, дистрибутив, сертификат в конечном счете. И часть этих доработок начинает обсуждаться, часть начинает возвращаться в код Firebird, всякие SQL Security у хранимых процедур, трейс, собственно говоря, был так или иначе адаптирован в рамках этой работы в начале. Что там еще вспомнить? Ну, в общем‑то, DDL контроль. Репликация родилась уже позже. Репликация родилась в рамках версии 2.5, начала разрабатываться совместно с Дмитрием Емановым. Сначала синхронная, потом асинхронная, потом мы ее уже влили в Firebird 4. Вот сейчас сделали уже синхронно‑асинхронную, сейчас мы ее назвали адаптивная, способную переключаться от ситуации. Но это уже пока в недрах только у нас в РЕД Базе Данных.

Ну, потом появились функциональные разные доработки. Тестами мы тоже пытаемся делиться. Маркетинг пытаемся развивать. Маркетинг именно Firebird, он, конечно, сильно пострадал, им мало занимались, мало занимались в сообществе, мало занимались community. Вот это вот я считаю главная причина, почему Firebird потерял некоторую популярность с тех пор. Потому что этим надо было больше заниматься. PostgreSQL этим занимался, MySQL этим занимался, у них образовались компании, которые коммерческую деятельность на себя взяли, бизнес на нем стали делать и в какой‑то степени продвигать эти технологии. Вокруг Firebird в таком виде сообщество не сложилось в мировом варианте, к сожалению. Я считаю, это было некоторое упущение, серьезное даже упущение, поэтому это надо обязательно исправлять. Отсюда как раз вот эта конференция, именно Firebird Сonf, не Red Database Сonf. Отсюда попытки развить именно community, желание собрать всех разработчиков драйверов и так далее.

Денис Симонов, системный архитектор Firebird

С Firebird я работал достаточно много, примерно с 2008 года как прикладной программист. В проект Firebird я попал примерно в 2015 году через форум sql.ru. Тогда решили создать русскоязычную документацию для Firebird, тогда ещё для версии 2.5. И на sql.ru Дмитрий Кузьменко подал клич — кто хочет попробовать написать свои какие‑то отдельные части документации прислать свои варианты и у кого будет более‑менее хорошо получаться, тех они возьмут писать документацию. Тогда нас отобрали в количестве трех человек, мы написали первую русскоязычную документацию по Firebird 2.5. С тех пор я работаю в этом направлении, пишу документацию по Firebird на русском языке.

Также у меня выходили статьи на habr.ru. По сути эти статьи являются такой же документацией, только короче. Обычно я пишу статьи или по моему желанию, или по заказу компании Айбейз, которая дает мне темы, на которые может быть спрос в сообществе. Также есть книга про разработку приложений с использованием Firebird, она только на английском языке. По сути эта книга просто сборник моих статей с habr.ru на английском языке. В ней и на habr.ru можно прочитать как использовать FireDAC, EntityFramework, JDBC, PHP.

Выступал на конференции FBConf три раза, рассказал про создание UDR, компоненты доступа для различных языков программирования и в этом году выступил с докладом про создание собственных провайдеров для доступа к внешним источникам данных.

Для себя я обновил компоненты доступа PHP PDO, но это была разовая задача, просто выпустил патчи. Также можно найти мои разработки для FullTextSearch.

Александр Пешков, ведущий разработчик Firebird

В конце 1999 года компания, в которой я работал, решила использовать Interbase в качестве сервера баз данных, не в последнюю очередь потому, что было обещано передача исходных кодов в Open Source. Однако в Interbase отсутствовала возможность выполнять динамически сгенерированные (в PSQL‑процедуре) SQL‑запросы, а для текущего проекта это было очень важно. Я решил реализовать это самостоятельно — тогда была версия IB-6.01. Сейчас, конечно, я ужасаюсь, вспоминая тот код, но, как ни удивительно, он работал! Поскольку делиться полезными изменениями в открытом исходном коде — как минимум хороший тон, я отправил изменённые файлы в какое‑то сообщество Interbase Ring — и забыл об этом примерно на год. А через год я получил письмо от Дмитрия Еманова с предложением присоединиться к проекту.

Алексей Ковязин, Firebird Foundation

Как я попал в проект Firebird. Все началось с разработки FirstAID, приложения для ремонта баз данных InterBase и Firebird. Инструмент получил популярность, я написал книгу Мир InterBase, и познакомился с множеством людей в коммьюнити. Активные действия на ниве продвижения Firebird в итоге привели к тому, что меня первый раз избрали в комитет Firebird Foundation в 2013 году.

Николай Самофатов, ведущий разработчик СУБД Firebird и РЕД База Данных, cооснователь РЕД СОФТ

Начиная с конца 90-х годов у меня, как и у многих в России, был довольно большой опыт работы с Delphi/Interbase.

В марте 2001 года в компании БФТ, как архитектор и главный разработчик, я взялся за создание АЦК2 — системы казначейского исполнения бюджета субъектов федерации и муниципальных образований. От бизнеса была задача обеспечить совместимость ПО с тремя СУБД — Oracle, MS SQL и Interbase/Firebird. Вариант поставки с бесплатным Interbase/Firebird рассматривался для большинства небольших и средних инсталляций системы, которых должно было быть несколько тысяч. Для нужд прикладной разработки требовалось было выработать «минимальный общий знаменатель» возможностей среди нескольких СУБД.

В Interbase/Firebird не хватало нескольких нужных нам возможностей (SAVEPOINT, пессимистичные блокировки и несколько других). Были еще проблемы с сильной деградацией производительности при некоторых операциях. От поддержки MS SQL через некоторое время пришлось отказаться, т.к. в этой СУБД тогда не поддерживалась мультиверсионность записей. Мы сфокусировались на поддержке Oracle 9i и Firebird. Это было довольно удобно, т.к. SQL диалект Firebird и Oracle 9i имел много общего.

Тогда я открыл для себя кодовую базу Firebird на SourceForge. И тогда вместо того чтобы на прикладном ограничивать себя в возможностях, я стал реализовывать нужные нам возможности Oracle в Firebird. Я сразу начал с кода Firebird портированного с языка С на C++, т.к. мне этот язык был ближе и казался удобней для разработки СУБД. Много усилий у меня ушло на стабилизацию кода firebird2, который позже стал основой Firebird 1.5 и более поздних версий. Уже тогда техническим лидером проекта Firebird был Дмитрий Еманов, с которым у меня сложились хорошие рабочие отношения.

Проект АЦК2 был успешно реализован (к ~2004 году) и система находится эксплуатации по сей день. Побочным результатом этой деятельности стал опыт работы с кодовой базой Firebird: исправление ошибок и несколько крупных доработок. Именно в БФТ я познакомился с Кириллом Веселкиным и Вадимом Щепиновым, с которыми мы в 2006 году основали Ред Софт и стали развивать Ред Базу Данных на основе Firebird, реализовывать прикладные проекты на основе Ред Базы Данных.

Когда в 2006 году мы создавали Ред Софт у нас уже было видение создания полного российского технологического стека ПО для разработки государственных информационных систем. В некотором роде, мы изобрели «импортозамещение» когда и слова такого не было. В частности, мы дорабатывали Ред Базу Данных по требованиям ФСБ России и ФСТЭК России, встраивали российскую криптографию и выполняли доработки нужные для защиты информации. Сертифицировали СУБД по как средство защиты информации. Доработки из Ред Базы Данных попадают в Firebird только если они там нужны. Далеко не всё, что нужно российским структурам, нужно всем остальным.

nbackup появился до создания Ред Софт. В 2003 году на одной из конференций Firebird я встретился с Шоном Лейном (Sean Leyne), вице‑президентом канадской компании BroadView Software, пользователем и активистом Firebird. Он предложил реализовать механизм резервного копирования на основе физического копирования страниц базы данных. Я взялся реализовать этот механизм по заказу BroadView и он сразу был включен в Firebird. Изначально, я сильно недооценил сложность реализации этой доработки, т.к. Firebird Classic на Linux/Unix тогда для коммуникации процессов использовал сигналы, а код в обработчике сигнала сильно ограничен в возможностях своих вызовов. Сейчас эту возможность можно было бы реализовать намного проще, т.к. вместо сигналов используются потоки.

На этом моё сотрудничество с BroadView Software не закончилось, и я даже провёл в совокупности несколько лет в Канаде в период с 2003 по 2014 годы решая различные системные и прикладные задачи для нужд этой компании и её заказчиков.

Репликация на прикладном урове на основе мультиверсионной архитектуры СУБД разрабатывалась и использовалась и в проектах БФТ, и в BroadView Software и в Ред Софт (в частности, в АИС ФССП России). При построении территориально распределенных информационных систем это частое требование. У нас накопился большой опыт в этой области. Последний вариант репликации на основе передачи логических изменений базы данных реализовывал Дмитрий Еманов по заказу Ред Софт. Именно этот код попал в Firebird.

Дмитрий Стародубов, Начальник отдела разработки СУБД РЕД База Данных, разработчик СУБД Firebird

В проект Firebird я попал в 2007 году, когда сотрудники компании РедСофт пришли в наш Муромский институт в поисках разработчиков. В это же время Роман Симаков закончил аспирантуру и преподавал на кафедре информационных систем. Я тогда учился в аспирантуре и куратор из Ред Софт этого направления проводил собеседование с преподавателями, студентами перспективными, аспирантами. Если я правильно помню, изначально было выбрано 6 человек для открытия филиала в Муроме. Это были филиалы в Москве и в Муроме. Причем в Москве был он такой административный, организационный.

В этом филиале был я, Роман Симаков, ещё несколько человек и все мы занимались СУБД Firebird. Тогда мы взяли Firebird 2.0, занимались его сборкой, вливали свои доработки. Первые проблемы были как раз с сборкой из исходников, тем более мы тогда очень мало работали с Linux. Сборка была очень плохо задокументирована, скрипт сборки требовал времени чтобы разобраться с ним — мог запустить сборку, получить ошибку, что не хватает какого‑то пакета. Тем более сборки таких масштабных больших проектов не было у нас никогда до этого. Приходилось разбираться с отладкой, как снимать и смотреть дампы. Это были первые шаги.

Я с 2007 года работал в Ред Софт и на кафедре, сначала как аспирант, потом как преподаватель. Это позволяет смотреть студентов, оценивать их, давать материал, который им может пригодится в работе. Сейчас из бывших студентов МИ ВлГУ разработкой СУБД занимаются Артём Смирнов, Илья Еремин, Артем Иванов, Артем Абакумов, Василий Яшков, Андрей Кравченко.

Александр "Дед" Невский, Firebird Community

Вряд ли меня кто-либо знает за пределами нашей тусовки. Да и рассказывать-то особо нечего. Тяготел к системному программированию, в смысле ассемблер-драйвера и т.д. Работал в ЛЭТИ инженером - обеспечение учебного процесса и НИР в основном, но привлекали и к работе со студентами, что и выработало некоторую тягу к общению.

В смутное время с несколькими приятелями сформировали группу, параллельно с основной работой ведущую собственный софт‑бизнес, в жанре АСУП, 8 лет лепили на BTrieve‑Pascal. В середине 90х стали задумываться об SQL, я экспериментировал с Гуптой, Sybase, Informix, Interbase. Склонялся к Informix, но тут мы разошлись в мнениях и я ушёл в автономное плавание, устроился начальником отдела информатики в ООО «Берег», подчинённые тогда были совсем никакие, а какой‑то результат надо было начать выдавать быстро, поэтому остановился на чём попроще, связке среды и СУБД от одного производителя, то есть Delphi + InterBase. InterBase4 Classic Server в смысле.

Почитывал конференцию Epsylon, понемногу стал там и разглагольствовать. У InterBase 4 были неприятные особенности, когда вышла InterBase 5 бодро перепрыгнули и вляпались в изменения оптимизатора. А 6.5 была только SuperServer, то есть вис весь офис и по причине какого запроса не поймёшь. Дмитрий Кузьменко посоветовал попробовать Firebird 0.9, там был Classic Server и оптимизатор как в 5 и не было того что мешало в InterBase 4. Вычислили проблему за 20 минут, вис наглухо только тот, кто на неё наступал, остальные со скрипом, но тянули. Ну а дальше я был очарован самой идеей OpenSource и пустился во все тяжкие и на наших ресурсах и на Delphi, и на Firebird когда появились.

  

Павел «Таблоид» Зотов, QA СУБД Firebird

Firebird меня заинтересовал примерно в 2002 году. Точнее, тогда мне попался (на CD вместе с другими СУБД) Interbase 6.x, про существование ФБ я еще не догадывался. Была сильная надобность начать переделку большого приложения, написанного на Clipper 5.x + ADS. Эту переделку я начал, но быстро упёрся в отсутствие должных знаний SQL. В магазине купил книгу «Мир InterBase» (напомню, что один из двух авторов — наш Алексей Ковязин:)) — она много пользы принесла, но она не была учебником по SQL. Затем увидел сайт ibase.ru — там уже в то время было столько «много почитать», что я надолго завис на нём. Но — он также не учил SQL. Ну, и поэтому... я стал интересоваться другими СУБД :‑)

Далее мне попалась СУБД под названием Caché, наследница языка «M», продававшаяся в то время в РФ представительством компании InterSystems (США). Уговорил начальство купить лицензии на несколько рабочих мест, начал изучать. Потратил года полтора‑два, пока не понял, что это тупик и всё‑таки надо возвращаться в SQL‑струю. Далее был большой перерыв, года на три, вызванный сильными переделками старой программы. И примерно в 2008 попалась на глаза книга «Упражнения SQL», а заодно и сайт sql‑ex.ru, на котором я начал усиленно решать задачки (на MS SQL).

Примерно через год «вдруг» созрело мое прежнее начальство и заявило, что предприятие будет покупать готовую систему, предлагавшуюся компанией «АнСофт». Эта система использовала Firebird 1.5 и готовую клиентскую часть (Delphi). Через некоторое время стало ясно, что «за один взмах» систему от Ансофта внедрить нельзя, да к тому же они разругались. Далее появился некий «человек‑интегратор», который был ранее как‑то связан с Ансофтом. Он продал нам (не знаю, насколько законно) исходники клиентской части, а начальство наше купило у него еще и двух программистов. Вместе с ними я начал погружение в эту систему.

К счастью, мне не пришлось тратить время на клиентскую часть, я был «брошен» именно на серверную сторону, т. е. только на ФБ. Это было осенью 2009. Первые же попытки что‑то проверить на ФБ 1.5 на небольшой нагрузке (даже не от пользователей, а всего лишь от 3–4 человек) показали, что нас ждут проблемы. Поэтому было решено всё делать на ФБ 2.1 (в святой надежде, что там этого не будет). Примерно полгода было затрачено на переделки, и в итоге мы начали «пробные топки» — уже с участием пользователей.

Далее начался форменный кошмар. Во‑первых, эта система была спроектирована по шаблону «Сущность‑Атрибут‑Значение» (EAV).То есть, все виды справочников (пользователи; товары; виды услуг; единицы измерения и т. д.) — всё в одной таблице, просто для различения им проставлялись разные коды. Все виды заголовков документов — в другой, но тоже «в одной и той же» таблице. То же самое для детализаций (строк) документов. Это означало, что на такие таблицы («общие для всего и вся») невозможно установить, например, CHECK‑ограничения с требованиями, включающими два и более полей, которые относятся к одной и той же сущности. Например, нельзя было создать ограничение вида «остаток вида_1 должен всегда быть не меньше, чем остаток вида 2» — потому что остатки эти находятся в разных записях. Далее, мы почти сразу же напоролись на нарушения уникальности, которые разработчики системы пытались обеспечить триггерами (а триггера работают только внутри транзакций).

Во‑вторых, в системе было много «бутылочных горлышек», из‑за коорых сразу же стало ясно, что она не масштабируема. Прежде всего, это относилось к сводной таблице денежных остатков, которая должна была обновляться при каждой бизнес‑действии. Понимания того, что это можно делать в отложенном режиме, специальным заданием (и только им), у авторов этой системы почему‑то не было.

Ну, а в‑третьих, когда пользователей стало уже больше, у нас начались падения ФБ. И чем дальше — тем чаще. В то время я уже был на форуме sql.ru/bid=2, и весьма интенсивно спрашивал там «советов бывалых». Мне очень помогли ответы Влада Хорсуна и Дмитрия Еманов, а также Дмитрия Сибирякова. Однако, положение наше не улучшалось: система стала безбожно тормозить. И тогда Дмитрий Еманов (вроде) предложил нам перейти на 2.5, хотя он был еще не релизный (а только RC-3, ЕМНИП). Деваться нам было некуда, и мы перешли :‑) Некоторое время было всё нормально, однако в конце 2010 на нашей сцене появилась очень неприятная «гостья»: ошибка в индексах с сообщением «missing entries». Эта ошибка проявлялась в том, что при индексной навигации результат запроса (в т.ч. сумма чисел) отличался от результата при натуральном чтении. И весьма скоро этот «эффект» обнаружила бухгалтерия, которая стала недосчитываться денег :‑)

В то время я уже вовсю общался с Владом, было сделано много всяких тестов, чтобы поймать эту ошибку. На это ушло несколько месяцев (если не полгода). Это, полагаю, была одна из самых трудно уловимых ошибок, вызываемых гонками процессов. К сожалению, начальство наше потеряло терпение и в итоге «поставило вопрос рогом», сказав: мы уходим с ФБ, либо на MS SQL либо на Oracle, на что именно — сами решайте. В общем, с того момента (примерно начало 2011) у нас там шла параллельно‑перпендикулярная работа, то с ФБ (чтобы поддерживать юзеров), то с Ораклом (чтобы выполнять приказ начальства о переходе).

Узнав к тому моменту возможности ФБ, его логику, краткость и «запоминаемость» его PSQL‑синтаксиса, набор встроенных функций, — я совершенно уже не горел желанием переходить на что‑то. Поэтому, по возможности, старался больше уделять времени именно ФБ, чем Ораклу. Многие тесты/проверки были сделаны именно тогда, и тогда же было найдено много багов.

Так прошло примерно 2 года, после чего на моем предприятии полностью поменялось руководство, а новые собственники собрали всех нас и сказали: «здесь будет 1С»:) Затею свою они стали воплощать сразу, набрав свору 1С‑ников (бригаду из 10 человек, которые постоянно увольнялись / нанимались:)). Быстро у них это сделать не получилось, они потратили на это примерно 4 года(!). Всё это время я там дорабатывал, сопровождая старые программы, но при этом было и много свободного времени. Поэтому я предложил Firebird Foundation свои услуги в качестве QA‑шника (это было летом 2013). К счастью, «меня заметили» и пошли навстречу, предложив грант. После этого я составил примерный план того, что буду делать в ближайшие несколько месяцев, обсудил его с Дмитрием Емановым, и начал работу c Firebird Foundation.

В течение 2014 года делал тест для имитации OLTP‑нагрузки, причем сразу решил делать так, как если бы это была реальная программа: с полным набором бизнес‑операций.

Конечно же, стремился при этом учесть все фичи ФБ, которых так не хватало в системе от Ансофта (см выше). К моему удивлению, этот тест позволил сразу же выявить еще примерно 30 багов, приводивших к крашам :‑) Помимо прочего, он позволил найти несколько регрессий в производительности.

Алексею Ковязину тест понравился и он предложил мне сделать презентацию и рассказать о нём на конференции в Праге-2014 (что и было сделано). Далее этот тест еще многократно переделывался / улучшался, вплоть до примерно 2020 года. Затем этот тест стал запускаться на регулярной основе и его результаты в html‑виде стали публиковаться на firebirdtest.com, в виде графиков. Цель этого была в том, чтобы глядя на график за несколько недель/месяцев, увидеть т. н. «плавную регрессию» производительности, и понять, когда она началась. К сожалению, сейчас этот тест не запускается (по независящим от меня причинам). К тому же, его надо адаптировать под ФБ-6.х.

Далее, с января 2015 я стал добавлять тесты в наш QA‑набор (тогда это был python‑пакет под названием 'fbtest', с 2022 перешли на промышленный стандарт — pytest). Мне очень много помогли в освоении этих пакетов Дмитрий Еманов и Pavel Cisar.

За 10 лет удалось сделать примерно 1800 тестов. Часть из них делалась «в лёт», просто по тикетам из трекера ФБ, но были и такие, над которыми «висел» по месяцу. И пользуясь случаем, хочу сказать спасибо нашим Firebird‑светилам (Дмитрию Еманову, Владу Хорсуну и Александру Пешкову) за объяснения/уточнения/подсказки при разработке таких тестов.

Ну, и наконец, в 2020 стал разрабатывать (на связке Python + Firebird) сценарий обработки результатов QA‑прогонов, с тем чтобы видеть их результаты в форме кросс‑отчета. То есть, чтобы на одном экране можно было видеть итоги не только текущего прогона, но и N предыдущих, что сразу же была возможность понять — провалилось ли что‑то новое или нет.

Кроме того, была добавлена возможность просмотра «итории прогонов» конкретного теста — как на выбранном ФБ, так и в виде сводного отчета по всем проверявшимся Firebird на обеих ОС (Windows/Linux). Результаты работы этого сценария видны на firebirdtest.com, ими регулярно пользуются Firebird‑разработчики (ну и я, разумеется).

В общем, всё это так пока и идёт: вижу что‑то пофиксенное (в почте, куда приходят алерты с github'a) — делаю тест, если это возможно по смыслу fix‑коммита. Постепенно получилось так, что тестами охвачены почти все тикеты, для которых можно было их сделать. Исключение — тикеты, которые фисят баги, вызванные гонками. Иногда, если поступит запрос от команды Firebird тестировать что‑то конкретное (новую фичу и т. п.), то делаю соответствующие тесты/проверки, ну и пишу им отчеты.