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

Шмаркатюк Сергей (EPAM Systems)

2

Особенности, которые присущи современному стилю разработки веб-приложений:> Подверженность частым изменениям требований> Проекты более склонны к увеличению в размерах чем к

уменьшению> Большое число используемых при разработке инструментов и

технологий> Некоторая степень хаотичности, с которой всегда приходится

бороться

Актуальность организации налаженных процессов разработки

Как используемые инструменты влияют на процесс разработки?> Каждый инструмент используется для решения ряда

специфических задач> Решение задачи предполагает предшествующее использованию

инструмента удовлетворение набора требований, без которых инструмент не будет эффективен или не будет работать

> Часто набор требований, выдвигаемый множеством используемых инструментов удовлетворен не полностью, в связи с чем эффективность их использования уменьшается

3

Управление конфигурациями

Управление конфигурациями определяет:> Способ управления рабочими материалами проекта> Как производится контроль над проектом> Как осуществляется внесение изменений> Как определить состояние отдельных задач> Как определить состояние всего проекта в целом

В частности, управление конфигурациями занимается:> Управлением выпуском (release management)> Наладкой поставок (delivery)> Организацией налаженных процессов разработки> Согласованием способа взаимодействия разных частей

программного проекта

4

Классификация инструментов управления конфигурациями

Контроль версий (version control)

Непрерывная интеграция (continuous integration)

Управление сборками (build management)

Юнит-тестирование

Анализ покрытия кода

Статический анализ кода

Генерация документации

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

5

Контроль версий(version control)

> Контроль версий – основной процесс управления конфигурациями

> Отсутствие необходимости использовать контроль версий при разработке практически равна нулю

> Большинство разработчиков знакомы с CVS, Subversion или VSS; популярность приобретают распределенные системы контроля версий: git, mercurial, bazaar

> Обычно разработчики не задумываются о продуманной организации репозитория. Subversion предлагает простейшее решение, которое используется чаще всего: деление на trunk, branches и tags.

> Одна из самых больших головных болей разработчиков – слияние. Без слияний жизнь проще.

> При командной разработке полностью избежать слияний сложно.

> Можно минимизировать их количество регламентируя ситуации, при которых можно проводить слияния, а при которых – нет.

6

Управление сборками

(build management)Управление сборками – автоматизация действий по: > Компиляции исходного кода> Развертыванию (deployment) приложения> Запуску юнит-тестов> Инициализации базы-данных

Инструменты управления сборками характеризуются:

> Файлами сборок, использующих XML-синтаксис (Ant, Nant, Maven, MSBuild, Phing)

> Наличием специфических для процесса сборки команд:> Групповые операции над файлами> Компиляция> Развертывание> Взаимодействие с системами контроля версий

> Простотой интеграции с инструментами, использующимися при разработке

7

Юнит-тестирование(unit-testing)

> Большинство инструментов юнит-тестирования очень похожи между собой и заимствуют идеи, заложенные при создании JUnit

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

> Юнит-тестирование появляется там, где предполагается проведение рефакторинга

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

> Хоть это и неочевидно, но принятие решения о использовании юнит-тестирования автоматически подразумевает введение ряда дополнительных процессов связанных с организацией разработки.

8

Статический анализ исходного кода

(static code analysis)> Кроме поддержки архитектурной и логической

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

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

в коде часто необходимо в автоматическом режиме проводить верификацию на соответствие code conventions

> Иногда статический анализ может производиться для сбора метрик исходного кода и составления соответствующей отчетности

> PHP-библиотеки, используемые для статического анализа исходного кода:

• PHP_Depend• PHP_Codesniffer• PHP-sat

9

Генерация документации(documentation generation)

> Генерация документации на основе исходного кода и комментариев в стиле phpDoc актуальна чаще всего для проектов с активным использованием исходного кода: библиотек, повторно используемых компонентов, фреймворков и др.

> Инструменты для генерации документации на основе комментариев к исходному коду:

• phpDocumentor• Doxygen

> Полезной особенностью представляется возможность интеграции сгенерированной документации с системой trac посредством соответствующих плагинов: DoxygenPlugin и PhpdocPlugin

10

Непрерывная интеграция(continuous integration)

> Непрерывная интеграция – это практика разработки, состоящая в выполнении частых автоматизированных сборок для раннего выявления и решения ошибок интеграции.

> Требования к проекту для организации непрерывной интеграции: Исходный код и всё необходимое для сборки

сохраняется либо в репозитории исходного кода, либо в легкодоступном месте;

Операции копирования из репозитория, сборки и тестирования всего проекта автоматизированы и легко вызываются из внешней программы

> При наличии этапа развертывания включенного в процесс сборки непрерывная интеграция может быть приспособлена к обеспечению команды тестировщиков работающей и готовой к тестированию копии приложения

> Обычно для организации процесса интеграции выделяется отдельный сервер

11

Интеграция баз данных(database integration)

> База данных обычно требует процесса сборки аналогично с, например, компиляцией исходного кода.

> SQL-приложение имеет свою специфику. Часто его можно рассматривать как приложение в приложении и выделять в отдельный проект, подлежащий версионированию.

> Выделяют два типа идентификационных элементов, использующихся при версионировании баз данных: DML (Database Manipulation Language) и DDL (Database Definition Language)

> Интеграция баз данных предусматривает наличие общих шагов:> Удаление базы данных> Создание базы данных> Добавление системных данных в базу данных> Добавление тестовых данных в базу данных> Миграция базы данных> Изменение тестовых данных> Изменение процедур, функций, триггеров> Изменение атрибутов полей и ограничений> Backup и restore

12

Гибкая разработка(agile development)

http://agilemanifesto.org

13

Шаблоны управления конфигурациямиhttp://www.scmpatterns.com/

14

Конфигурационные элементы

> Исходный код

> Библиотеки (бинарные файлы)

> Конфигурационные файлы

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

> Файлы ресурсов (изображения, иконки)

> Структура БД

> Данные и словари данных

> Тесты (юнит-тесты)

> Исполняемые файлы и инсталляционные

пакеты

15

Элементы идентификации

> Сборки

> Типы сборок

> Релизы

> Типы релизов

> Платформы

> Компоненты (third-party)

> Экспериментальные разработки

16

Типы сборок и релизов

Сборки

Релизы

> PA – пре-альфа (тестирование производится разработчиками,

smoke testing)

> A – альфа (тестирование производится тестировщиками)

> B – бета (тестирование производится тестировщиками и пользователями)

> AR – альфа-релиз

> BR – бета-релиз

> RC – релиз-кандидат

> ST – стабильная версия

17

Стандартные директории репозитория

Ствол Директория теговДиректория веток

/trunk /branches /tags

/

Репозиторий

18

Обобщенная структура директорий проекта[codebase]

svn:externals – библиотеки, компоненты

исходный код

файлы конфигурацииsql-файлы инициализации БДфайлы локализациифайлы ресурсов

файлы сборок, развертывания

спецификации, проектная документация

юнит-тестыутилиты

19

Менеджмент веток

Директория веток

/experimental /maintenance /releases

/branches

20

Менеджмент тегов

Директория тегов

/builds /releases

/tags

/PA /A /B /AR /BR /RC /ST

21

Именование версий

1.2.3_x64

Номер сборки Платформа

Мажорная версия

Минорная версия (номер

итерации)

ТипШаблон

(регулярные выражения)

Релиз (/tags/releases) \d+\.\d+\.\d+(_.*)?

Ветка, ориентированная на релиз (/branches/releases)

\d+\.\d+\.x(_.*)?

Сборка (/tags/builds) \d+\.x\.\d+(_.*)?

Ветка поддержки версии (/branches/maintenance/versions)

\d+\.x\.x

([1-9]\d*)\.([1-9]\d*|[0x])\.([1-9]\d*|[0x])(_.*)?

22

Шаблоны именования директорий

Директория базиса исходного кода (codebase)

Шаблон именования директории22

23

Правила наследования номеров версий

Мажорной версии (N.x.x) соответствуют отрезки: В стволе: от места ответвления предыдущей мажорной

версии (N-1) до ответвления текущей версии (N) В ветке поддержки версии: вся ветка N.x.x

24

Иерархия типов элементов дерева репозитория

Директория альфа-сборокДиректория бета-сборокДиректория пре-альфа сборокДиректория альфа-релизовДиректория бета-релизовДиректория кандидат-релизов

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

Директория программного проекта в репозитории исходного кода

Директория тегов

Ствол (основное направление разработки)

Директория сборок

Директория релизов

Директория веток

Директория веток, соответствующих экспериментальным разработкам

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

Директори веток поддержки версий

Директория веток платформ

Директория веток, ориентированных на релиз

25

Организация интеграции релизов и сборок

trunk

PA

A

B

/tags/builds

AR

BR

RC

ST

/tags/releases

1.x.0

1.x.1

1.x.2

1.x.3

2.x.1

1.x.5

1.x.4

2.x.2

2.x.0

/branches/maintenance/versions/1.x.x

/branches/releases/1.0.x

1.0.1

1.0.2 1.0.3

1.0.0

1.0.4

1.x.x 2.x.x

26

trunkPA

A

B

/tags/builds

AR

BR

RC

ST

/tags/releases

1.x.0

1.x.1

1.x.2

1.x.3

2.x.1

1.x.5

1.x.4

2.x.2

2.x.0

/branches/maintenance/versions/1.x.x

/branches/releases/1.0.x

1.0.1

1.0.2 1.0.3

1.0.0

1.0.4

1 12 39 52 73 79 93 112 126 139 155 170 193 201 215 230140

Зависимость содержимого директорий репозитория от номера ревизии1.x.x 2.x.x

Номера ревизий

Развертывание результатов сборки

СУБД

1.x.0 Проверка службой непрерывной интеграции изменений в директории сборок репозитория исходного кода и инициирование процесса сборки

1.x.0

Детализация процесса

интеграции

Репозиторий Файловая система Файловая система

Определение параметров сборки

Выполнение интеграции базы данных

Загрузка исходного кода из репозитория

Production-сервер

Процесс сборки

CI служба

Условные обозначения

Директория сборки в репозитории исходного кода

Процесс выполнения сборки

Детализация процесса интеграции

27

28

Процесс непрерывной интеграции веток

29

Архитектура программных средств

30

Заключение

Метод организации репозитория исходного кода позволяет достичь:> Прозрачности процессов управления конфигурациями> Улучшенного контроля и учета изменений при

разработке программного обеспечения> Упрощенного развертывания программных артефактов

на рабочие платформы> Использования усовершенствованных процессов

тестирования и, как результат, ПО более высокого качества

> Уменьшения времени, необходимого для выпуска рабочей версии ПО

> Простоты при построении платформы управления конфигурациями для разработки программного обеспечения