[PHPConf 2009] Метод организации репозитория исходного кода

Я голосую ...

  • За доклад на конфернции

    Голосов: 9 47,4%
  • Больше для мастеркласса подходит

    Голосов: 8 42,1%
  • Не включать

    Голосов: 2 10,5%
  • Укажу в топике

    Голосов: 0 0,0%

  • Всего проголосовало
    19
  • Опрос закрыт .

confguru

ExAdmin
Команда форума
[PHPConf 2009] Метод организации репозитория исходного кода

Метод организации репозитория исходного кода
Шмаркатюк С.В. – Senior Software Engineer at EPAM Systems

Потребность в разработке больших и сложных программных продуктов была всегда и также всегда была независимой от уровня технологий, существующих на тот или иной момент времени. Но исследуя и анализируя существующие подходы к разработке ПО, зачастую не находится ответов на самые простые вопросы, связанные с «правильной» разработкой качественных программных продуктов. Одним из таких простейших вопросов является то, как назначать номера версий выпускаемому программному продукту. Смысл назначения версий возникает тогда, когда программа перестает быть экспериментом и начинает делать что-то полезное. Но существует необходимость даже экспериментальным версиям назначать уникальный идентификатор: изменение номеров версий отображает последовательный подход к разработке и, с одной стороны, представляет собой соответствие выдвигаемым к разрабатываемой программе требованиям, а с другой стороны – связь с предыдущими версиями в виде общей базовой функциональности или базы исходного кода (source codebase).

Отдельная дисциплина инженерии программного обеспечения, которая занимается подобного рода организационными задачами без привязки к методологиям, носит название конфигурационный менеджмент (configuration management, управление конфигурациями). Управление конфигурациями является основной дисциплиной в определении того, каким образом управляются и контролируются рабочие материалы программного проекта, внесенные в него изменения, а также информация про состояние отдельных задач и всего проекта в целом.

В область интересов конфигурационного менеджмента попадают:

1. Контроль версий (version control)
2. Билд-менеджмент (build management)
3. Юнит-тестирование (unit-testing)
4. Статический анализ кода (static analysis)
5. Генерация документации (phpDoc)
6. Непрерывная интеграция (continuous integration)
7. Управление зависимостями (dependency management)
8. Интеграция баз данных
9. Баг-трекинг (bug-tracking) и контроль постановки задач (issue-tracking)

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

Для решения данной проблемы предлагается использовать метод организации репозитория исходного кода (сокращенно МОРИК), базирующийся на следующих принципах:

1. Определенная структура репозитория исходного кода.
2. Подход к именованию версий.
3. Формальное определение правил ведения репозитория.

Формализация правил ведения репозитория определена в таком виде, чтобы принятые соглашения могли использоваться в любом из составных элементов платформы управления конфигурациями – в инструментах сборок, инструментах непрерывной интеграции, и, конечно же, людьми. Также отличительным моментом такой формализации является то, что каждой директории репозитория соответствует определенный класс содержимого, который может в этой директории находиться. При соблюдении всех правил ведения репозитория может быть проведена валидация иерархии директорий и, таким образом, поддержка репозитория в структурированном (а также доступном для используемых в управлении конфигурациями инструментов) виде. В подходе к именованию версий используется шаблон, который можно описать регулярным выражением вида \d+\.[\dx]+\.[\dx]+(_.*)?. Такой шаблон соответствует наиболее распространенной системе именования сборок и релизов, к которой большинство разработчиков привыкли (примеры: 1.0.2, 2.3.5, 3.10.23). Отличие использования известного всем подхода к именованию заключается в том, что зависимости изменений каждой цифры в системе именования от некоторого момента времени описываются формально, Кроме того, составные части версии поставлены в зависимость от изменения структуры репозитория. Это позволяет достичь универсальности и гибкости при построении платформы конфигурационного менеджмента независимо от инструментов, используемых для решения отдельных задач.
 

pilot911

Новичок
для меня это самый интересный доклад

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