Опыт использования Open Source в небольшом проекте

Author / Автор: Сергей Сацкий
Publication date / Опубликовано: 20.06.2005
Version / Версия текста: 1.0

Введение

Окунаясь впервые в мир Open Source, часто человек не знает, с чего начать. Как организовать работу, где взять необходимый инструментарий. Цель статьи - дать отправные точки для вновь открывающихся проектов. При этом акцент сделан на инструментах поддержки работы коллектива разработчиков, а не на библиотеках и технологиях, использованных для разработки кода.

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

С момента начала работ в описываемом проекте прошло время. Новый Open Source инструментарий стал доступен на рынке. В связи с этим то, что было выбрано раньше по веским причинам, теперь может казаться совершенно неверным. Однако, несмотря на упомянутые проблемы, подобный опыт может быть интересным.

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

Проект

Компания разработчик проекта только начинала работать на рынке разработки программного обеспечения. Фактически это был второй проект по счету и первый, базирующийся на операционной системе семейства UNIX. Больших финансовых вложений не предполагалось ни при каких обстоятельствах ни в аппаратуру, ни в инструменты разработчика, поэтому Open Source технологии пришлись как нельзя лучше.

Задачей проекта была разработка программного обеспечения для одноплатного компьютера архитектуры PC на базе Intel - совместимого процессора производства компании VIA. Все программное обеспечение, включая операционную систему, должно было располагаться на Compact Flash носителе. Имелся также набор плат расширения, которым необходимо было управлять. Существенных ограничений ни по размеру оперативной памяти, ни по объему памяти Compact Flash носителя не было. Однако относится безответственно к этим вопросам было неприемлемо, и в качестве ориентиров были выбраны 256 мегабайт оперативной памяти и такой же объем Compact Flash носителя.

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

Миг удачи состоял в том, что проект начинался с "нуля", поэтому можно было использовать даже такие идеи, которые обычно трудно внедрить, когда проект уже стартовал из-за большого объема изменений и возможных побочных эффектов.

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

Коллективная работа над исходным кодом

Поскольку с самого начала в проекте предполагалось участие нескольких разработчиков, то для поддержки работы был использован сервер. На нем был установлен все тот же Linux, использованный для рабочих мест разработчиков и целевой платформы. В качестве аппаратуры сервера был использован компьютер, едва ли не самый низкопроизводительный среди всех компьютеров проекта. В нем использовался процессор серии Intel Celeron, а количество оперативной памяти равнялось 256 мегабайтам. Сервер выигрывал по вычислительной мощности только у целевой платформы. Этот компьютер был единственными прямыми финансовыми расходами на аппаратуру и программное обеспечение в дополнении к расходам на рабочие места разработчиков и целевую платформу.

В качестве системы контроля версий исходных текстов использовался CVS (http://savannah.nongnu.org/projects/cvs). Разработчики получали доступ к исходным текстам, используя утилиты командной строки или графическую оболочку для X Window LinCVS (http://www.lincvs.com). Для доступа к исходным текстам с компьютеров, на которых установлена операционная система семейства MS Windows, использовалось приложение WinCVS (http://cvsgui.sourceforge.net/). WinCVS позволяет использовать скрипты для автоматизации работы с репозиторием CVS. Для этого требуется установка Python для Windows (http://www.python.org) или TCL (http://tcl.sourceforge.net).

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

Со своей задачей CVS справился. Самым серьезным неудобством работы с CVS было отсутствие возможности блокировать изменяемый файл. Из-за этого иногда приходилось вручную "сливать" изменения в файлах, модифицированных одновременно несколькими разработчиками. Однако этот недостаток отчасти компенсировался очень короткими циклами изменений. Кроме того, острота проблемы снималась небольшим количеством разработчиков. Еще одним неидеальным моментом было хранение двоичных файлов. Часть документации велась в формате RTF. Каждая новая версия такого файла сохранялась целиком как двоичный файл, что приводило к излишнему расходу дискового пространства.

Система отслеживания ошибок

Желание иметь доступ к базе данных ошибок было не только у людей, непосредственно занятых в проекте, но и у других сотрудников компании. На многих компьютерах компании была установлена операционная система семейства MS Windows, поэтому система отслеживания ошибок искалась такая, что бы доступ к ней осуществлялся через Web интерфейс.

Немаловажным аспектом была простота настройки, установки, поддержка русского языка в интерфейсе и легкость освоения. Такая система быстро нашлась - это оказалась малоизвестная система Mantis (http://www.mantisbt.org). Эта система хранит сведения об ошибках в базе данных MySQL и представляет собой набор PHP (http://www.php.net) скриптов, работающих под управлением Web сервера. Таким образом, потребовался запуск сервера баз данных MySQL (http://www.mysql.com) и запуск Web сервера Apache (http://www.apache.org). Теперь схему работы в проекте выглядела так, как показано на рисунке 1.


Рисунок 1. Доступ к исходным текстам и базе данных ошибок

Система Mantis отлично справилась со своей задачей. Единственным недостатком было отсутствие поддержки уведомлений о появлении новых записей по электронной почте. Такая поддержка была обещана разработчиками в будущих версиях, но на тот момент отсутствовала. Возможно, для больших проектов более подходящим выбором будут системы отслеживания ошибок вроде Bugzilla (http://www.bugzilla.org) или GNATS (http://www.gnu.org/software/gnats), однако для небольших проектов вполне подойдут системы вроде Mantis.

Документация

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

Чтобы избежать, по возможности, расхождения документации по исходным текстам и самих исходных текстов было принято решение использовать систему генерации документации по исходным текстам. Была выбрана система Doxygen (http://www.doxygen.org). Эта система допускает несколько вариантов документирования кода, однако в проекте хотелось иметь единый стиль. Для достижения единого стиля документирования, а так же для навязывания разработчику необходимости документировать свой собственный код, в стандарт кодирования были включены соответствующие разделы. Стандарт кодирования был разработан в рамках работы над проектом. В этом стандарте не ставилась цель дать исчерпывающее описание всех вариантов использования языковых конструкций, идиом и т.п., а, скорее, дать почувствовать общий дух. Кроме того, текст стандарта хотелось сделать возможно более коротким (см. [4]).

Для графического представления зависимостей Doxygen предлагает возможность использовать внешний инструментарий Graphviz (http://www.graphviz.org). При этом в документацию будут включены графические диаграммы зависимостей между классами и файлами проекта.

Сгенерированная Doxygen документация может быть в разных форматах. Один из них - html. Оказалось очень удобным давать доступ к сгенерированным html файлам через web интерфейс, благо apache сервер был уже запущен. Для библиотек Doxygen документация оказалась весьма полезной, а для оконечных исполняемых модулей, в некоторых случаях, избыточной. С другой стороны, даже для оконечных исполняемых модулей, Doxygen был дополнительным стимулом для разработчиков во-первых документировать код вообще, а во-вторых давать внятные комментарии.

Резервные копии

В компании уже имелось оборудование для создания резервных копий. Это оборудование использовалось совместно с программным обеспечением, работающим под управлением MS Windows. Чтобы задействовать эту инфраструктуру была использована следующая схема работы:

  • Раз в определенный промежуток времени запускался shell скрипт, в задачу которого входило создание архива (tar) со всеми необходимыми файлами и его упаковка (bzip2). Запуск shell скипта осуществлялся автоматически с помощью демона crond.
  • Готовый архив :.tar.bz2 копировался в папку специально созданного пользователя.
  • На сервере был запущен ftp сервер proftpd (http://www.proftpd.org).
  • Внешняя система создания резервных копий использовала ftp доступ чтобы скопировать готовый архив. При этом использовалась учетная запись специального пользователя.

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

Доступ к CVS через web интерфейс

В процессе работы над проектом оказалось, что иногда бывает удобным иметь доступ к системе контроля исходных текстов через web интерфейс. Такую функциональность предлагает система ViewCVS (http://viewcvs.sourceforge.net).

ViewCVS отлично справилась со своей задачей.

Сборка и тестирование

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

Среди обязательных целей были следующие:

  • dependency. По этой цели должны были строиться зависимости для файлов исходных текстов.
  • item. По этой цели строился конкретный подпроект. Готовые библиотеки, файлы настроек, исполняемые модули и т.п. не устанавливались.
  • install. По этой цели выполнялась цель item, после чего выполнялась установка готовых библиотек, файлов настроек, исполняемых модулей и т.п.
  • doc. По этой цели производилась подготовка генерируемой по исходным текстам документации.
  • webdoc. По этой цели выполнялась цель doc, а затем копировалась html документация в такую папку, чтобы обеспечить удобный доступ к ней через web интерфейс. Кроме того, аналогичным образом копировалась документация в формате RTF.
  • test. Каждый подпроект содержал папку, в которой находились исходные тексты программ, выполняющих unit тестирование. Требование к таким программам было выводить результаты в удобном для чтения виде на стандартный вывод. По цели test производилась сборка соответствующих программ тестового назначения.
  • exectest. По этой цели запускались на выполнение собранные тестовые программы. Каждая из тестовых программ запускалась с контролем утечек памяти.

Если какая-то из обязательных целей была неприменима к конкретному подпроекту, то цель присутствовала в make-файле, но никаких существенных действий не выполнялось. Обычно на стандартный вывод отправлялось сообщение о том, что цель пустая.

Сборка всего проекта осуществлялась shell скриптом, который делал слепок кода из CVS, а затем вызывал нужные цели нужных подпроектов, учитывая как порядок сборки отдельного проекта так и последовательность проектов. Еще один скрипт работал совместно с crond демоном. Весь вывод процесса сборки, включая вывод тестовых программ, собирался в единый html файл и копировался в такую папку, чтобы обеспечить доступ к результатам через web интерфейс. Скрипт запускался каждый день в ночное время.

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

Система сборки зарекомендовала себя превосходно.

По мере разработки проекта объем исходных текстов и, соответственно, время компиляции увеличивались. Сборка отдельных модулей на компьютере разработчика стала занимать больше времени, чем хотелось бы. С другой стороны ситуация, когда все разработчики компилировали или выполняли сборку одновременно, была редка. Оказалось, что можно задействовать все имеющиеся компьютеры для сборки одного модуля. Такую функциональность предоставляет пакет distcc (http://distcc.samba.org). Он позволяет произвести разспределение компиляции по нескольким компьютерам на пофайловой основе. Использование этого пакета позволило сэкономить массу времени на перекомпиляциях. При этом изменения в системе сборки при замене gcc на distcc коснулись лишь пары строк в общем файле правил.

Установка сборки на целевую систему

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

Для автоматизации копирования на целевой системе был установлен ftp сервер proftpd. На сервере использовался ftp клиент ncftp (http://www.ncftp.com), позволяющий автоматизировать процесс копирования файлов. Вместо этого вполне можно было воспользоваться стандартным ftp клиентом в паре с утилитой expect.

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

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

Целевая система

Для целевой системы исходная версия Linux была специальным образом подготовлена. Был отобран необходимый и достаточный минимум программного обеспечения, модифицированы стартовые скрипты системы, подготовлены файлы настроек, изменены некоторые параметры стека протоколов IP по умолчанию и т.п. Ядро для целевой системы было скомпилировано из исходных текстов (http://www.kernel.org) с учетом используемой аппаратуры и исключения ненужной функциональности. Этим обеспечивались максимальная компактность и скорость загрузки и работы системы.

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

В течение работы над проектом несколько раз выходили обновления ядра Linux. Каждый раз ядро компилировалось заново и снова готовился образ Compact Flash носителя.

Мелочи

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

  • Для синхронизации времени на компьютерах проекта использовалась утилита ntp, которая запускалась в ночное время демоном crond и корректировала работу часов компьютеров.
  • Сторонняя документация вроде справочников по языку программирования или стандартов на используемые протоколы также выкладывалась таким образом, чтобы иметь к ней удобный доступ через web интерфейс.
  • В проекте появилось довольно большое число терминов предметной области, которые часто появлялись в исходных текстах. Чтобы добиться единообразия идентификаторов и иметь краткое описание терминов, был сделан доступный через web интерфейс словарь с возможностью поиска, добавления и удаления элементов. Для этого была использована система glossar, слегка доработанная для текущих потребностей.

Полная схема работы в проекте

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


Рисунок 2. Полная схема работы в проекте

Заключение

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

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

Может возникнуть вопрос об Open Source инструментах разработчика и Open Source библиотеках, которые были использованы в проекте. Если отзывы по этой статье покажут интерес к возможному продолжению, то автор с удовольствием поделится и этим опытом.

Сводная таблица

В таблице приведены ссылки и краткое описание Open Source проектов, которые были использованы в проекте. Стоит заметить, что часть из этих проектов входит в состав популярных Linux дистрибутивов, что позволяет избежать скачивания пакетов из сети Интернет при использовании этой операционной системы.

Проект Описание Адрес в сети Интернет
CVS Система контроля версий исходных текстов. http://savannah.nongnu.org/projects/cvs
LinCVS Графическая оболочка доступа к CVS для X Windows. http://www.lincvs.com
WinCVS Графическая оболочка доступа к CVS для MS Windows. http://cvsgui.sourceforge.net
Mantis Система отслеживания ошибок. http://www.mantisbt.org
Bugzilla Система отслеживания ошибок. http://www.bugzilla.org
GNATS Система отслеживания ошибок. http://www.gnu.org/software/gnats
PHP Скриптовый язык общего назначения. http://www.php.net
TCL Скриптовый язык. http://tcl.sourceforge.net
MySQL Сервер баз данных. http://www.mysql.com
Apache Web сервер. http://www.apache.org
Doxygen Система генерации документации по исходным текстам. http://www.doxygen.org
Graphviz Система построения графических диаграмм зависимостей. http://www.graphviz.org
Proftpd ftp сервер. http://www.proftpd.org
ViewCVS Система доступа к CVS через web интерфейс. http://viewcvs.sourceforge.net
Kernel Ядро Linux. http://www.kernel.org
Ncftp ftp клиент, расширяющий функциональность стандартного ftp клиента. http://www.ncftp.com
Distcc Рапределенная компиляция файлов проекта на нескольких компьютерах. http://distcc.samba.org

Список литературы и дополнительные ссылки

  1. Free Software Foundation. http://www.gnu.org
  2. Домашний сайт Open Source. http://www.opensource.org
  3. Каталог программного обеспечения с открытыми исходными текстами, распространяемого по различным лицензиям. http://www.freshmeat.net
  4. Стандарт кодирования на языке C++, используемый автором. http://satsky.spb.ru

Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.

Разрешается копирование и распространение этой статьи любым способом без внесения изменений, при условии, что это разрешение сохраняется.
Last Updated: September 27, 2005