1.
Метод организации репозитория исходного кода<br />Шмаркатюк Сергей (EPAM Systems)<br />

2.
Актуальность организации налаженных процессов разработки<br />Особенности, которые присущи современному стилю разработки веб-приложений:<br />Подверженность частым изменениям требований<br />Проекты более склонны к увеличению в размерах чем к уменьшению<br />Большое число используемых при разработке инструментов и технологий<br />Некоторая степень хаотичности, с которой всегда приходится бороться<br />Как используемые инструменты влияют на процесс разработки?<br /><ul><li>Каждый инструмент используется для решения ряда специфических задач

3.
Решение задачи предполагает предшествующее использованию инструмента удовлетворение набора требований, без которых инструмент не будет эффективен или не будет работать

4.
Часто набор требований, выдвигаемый множеством используемых инструментов удовлетворен не полностью, в связи с чем эффективность их использования уменьшается</li></li></ul><li>Управление конфигурациями<br />Управление конфигурациями определяет:<br /><ul><li>Способ управления рабочими материаламипроекта

5.
Как производится контроль над проектом

6.
Как осуществляется внесение изменений

7.
Как определить состояние отдельных задач

8.
Как определить состояние всего проекта в целом</li></ul>В частности, управление конфигурациями занимается:<br /><ul><li>Управлением выпуском (release management)

9.
Наладкой поставок (delivery)

10.
Организацией налаженных процессов разработки

11.
Согласованием способа взаимодействия разных частей программного проекта</li></ul>3<br />

12.
Классификация инструментов управления конфигурациями<br />В область интересов управления конфигурациями попадают следующие процессы: <br />Контроль версий (version control)<br />Юнит-тестирование<br />Анализ покрытия кода<br />Непрерывная интеграция (continuous integration)<br />Статический анализ кода<br />Генерация документации<br />Управление сборками (build management)<br />

13.
Контроль версий(version control)<br /><ul><li>Контроль версий – основной процесс управления конфигурациями

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

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

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

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

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

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

20.
Управление сборками (build management)<br />Управление сборками – автоматизация действий по: <br /><ul><li>Компиляции исходного кода

21.
Развертыванию (deployment) приложения

22.
Запуску юнит-тестов

23.
Инициализации базы-данных</li></ul>Инструменты управления сборками характеризуются:<br /><ul><li>Файлами сборок, использующих XML-синтаксис (Ant, Nant, Maven, MSBuild, Phing)

24.
Наличием специфических для процесса сборки команд:

25.
Групповые операции над файлами

26.
Компиляция

27.
Развертывание

28.
Взаимодействие с системами контроля версий

29.
Простотой интеграции с инструментами, использующимися при разработке</li></li></ul><li>Юнит-тестирование(unit-testing)<br /><ul><li>Большинство инструментовюнит-тестирования очень похожи между собой и заимствуют идеи, заложенные при создании JUnit

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

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

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

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

34.
Статический анализ исходного кода(static code analysis)<br /><ul><li>Кроме поддержки архитектурной и логической целостности в больших проектах существует необходимость выявления синтаксических ошибок на ранних стадиях разработки

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

36.
Кроме выявления синтаксических и логических ошибок в коде часто необходимо в автоматическом режиме проводить верификацию на соответствие code conventions

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

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

39.
PHP_Depend

40.
PHP_Codesniffer

41.
PHP-sat</li></li></ul><li>Генерация документации(documentation generation)<br /><ul><li>Генерация документации на основе исходного кода и комментариев в стиле phpDocактуальна чаще всего для проектов с активным использованием исходного кода: библиотек, повторно используемых компонентов, фреймворков и др.

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

43.
phpDocumentor

44.
Doxygen

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

46.
Непрерывная интеграция(continuous integration)<br /><ul><li>Непрерывная интеграция – это практика разработки, состоящая в выполнении частых автоматизированных сборок для раннего выявления и решения ошибок интеграции.

47.
Требования к проекту для организации непрерывной интеграции:

48.
Исходный код и всё необходимое для сборки сохраняется либо в репозитории исходного кода, либо в легкодоступном месте;

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

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

51.
Обычно для организации процесса интеграции выделяется отдельный сервер</li></li></ul><li>Интеграция баз данных(database integration)<br /><ul><li>База данных обычно требует процесса сборки аналогично с, например, компиляцией исходного кода.

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

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

54.
Интеграция баз данных предусматривает наличие общих шагов:

55.
Удаление базы данных

56.
Создание базы данных

57.
Добавление системных данных в базу данных

58.
Добавление тестовых данных в базу данных

59.
Миграция базы данных

60.
Изменение тестовых данных

61.
Изменение процедур, функций, триггеров

62.
Изменение атрибутов полей и ограничений

63.
Backup и restore</li></ul>11<br />

64.
Гибкая разработка(agile development)<br />http://agilemanifesto.org<br />

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

66.
Конфигурационные элементы<br />Исходный код<br />Библиотеки (бинарные файлы)<br />Конфигурационные файлы<br />Документация<br />Файлы ресурсов (изображения, иконки)<br />Структура БД<br />Данные и словари данных<br />Тесты (юнит-тесты)<br />Исполняемые файлы и инсталляционные пакеты<br />

67.
Элементы идентификации<br />15<br />Сборки<br />Типы сборок<br />Релизы<br />Типы релизов<br />Платформы<br />Компоненты (third-party)<br />Экспериментальные разработки<br />

68.
Типы сборок и релизов<br />Сборки<br /><ul><li>PA – пре-альфа(тестирование производится разработчиками, smoke testing)

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

70.
B – бета (тестирование производится тестировщиками и пользователями)</li></ul>Релизы<br /><ul><li>AR – альфа-релиз

71.
BR – бета-релиз

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

73.
ST – стабильная версия</li></li></ul><li>Стандартные директории репозитория<br />Репозиторий<br />/<br />/trunk<br />/branches<br />/tags<br />Ствол<br />Директория тегов<br />Директория веток<br />17<br />

74.
Обобщенная структура директорий проекта<br />[codebase]<br />файлы сборок, развертывания<br />спецификации, проектная документация<br />исходный код<br />svn:externals – библиотеки, компоненты<br />файлы конфигурации<br />sql-файлы инициализации БД<br />файлы локализации<br />файлы ресурсов<br />юнит-тесты<br />утилиты<br />

75.
Менеджмент веток<br />/branches<br />Директория веток<br />/experimental<br />/maintenance<br />/releases<br />19<br />

76.
Менеджмент тегов<br />Директория тегов<br />/tags<br />/builds<br />/releases<br />/PA<br />/A<br />/B<br />/AR<br />/BR<br />/RC<br />/ST<br />

77.
Именование версий<br />1.2.3_x64<br />([1-9]*)([1-9]*|[0x])([1-9]*|[0x])(_.*)?<br />Минорная версия (номер итерации)<br />Номер сборки<br />Мажорная версия<br />Платформа<br />21<br />

78.
Шаблоны именования директорий<br />Директориябазисаисходногокода (codebase)<br />22<br />Шаблон именованиядиректории<br />

79.
Правила наследования номеров версий<br />Мажорной версии (N.x.x)соответствуют отрезки:<br /><ul><li>В стволе: от места ответвления предыдущей мажорной версии (N-1) доответвления текущей версии (N)

80.
В ветке поддержки версии: вся ветка N.x.x</li></ul>23<br />

81.
Иерархия типов элементов дерева репозитория<br />Директория программногопроекта в репозиторииисходногокода<br />Директорияальфа-сборок<br />Директориябета-сборок<br />Ствол (основноенаправлениеразработки)<br />Директорияпре-альфасборок<br />Директориятегов<br />Директория альфа-релизов<br />Директориясборок<br />Директориярелизов<br />Директориябета-релизов<br />Директорияветок<br />Директориякандидат-релизов<br />Директорияветок, соответствующихэкспериментальнымразработкам<br />Директориястабильных релизов<br />Директорияветок, соответствующихдлительнымразработкам (веткиподдержки)<br />Директори ветокподдержкиверсий<br />Директорияветок платформ<br />Директорияветок, ориентированных на релиз<br />

82.
Организация интеграции релизов и сборок<br />1.x.x<br />2.x.x<br />1.x.0<br />1.x.3<br />2.x.0<br />1.x.1<br />2.x.1<br />1.x.4<br />1.x.2<br />1.x.5<br />2.x.2<br />/branches/maintenance/versions/1.x.x<br />1.0.0<br />1.0.1<br />1.0.2<br />1.0.3<br />1.0.4<br />/branches/releases/1.0.x<br />25<br />

83.
Зависимость содержимого директорий репозитория от номера ревизии<br />1.x.x<br />2.x.x<br />1.x.0<br />1.x.3<br />2.x.0<br />1.x.1<br />2.x.1<br />1.x.4<br />1.x.2<br />1.x.5<br />2.x.2<br />/branches/maintenance/versions/1.x.x<br />1.0.0<br />1.0.1<br />1.0.2<br />1.0.3<br />1.0.4<br />/branches/releases/1.0.x<br />Номера ревизий<br />1<br />12<br />39<br />52<br />73<br />79<br />93<br />112<br />126<br />139<br />155<br />170<br />193<br />201<br />215<br />230<br />140<br />26<br />

84.
Детализация процесса интеграции<br />Условные обозначения<br />Директория сборки в репозитории исходного кода<br />Проверкаслужбойнепрерывнойинтеграцииизменений в директориисборокрепозиторияисходногокода и инициированиепроцессасборки<br />Процесс выполнения сборки<br />CI служба<br />Детализацияпроцессаинтеграции<br />Процесс сборки<br />Загрузка исходногокодаизрепозитория<br />Репозиторий<br />Файловаясистема<br />Файловаясистема<br />Определениепараметровсборки<br />Развертывание результатов сборки<br />Выполнениеинтеграциибазыданных<br />Production-сервер<br />27<br />

85.
Процесс непрерывной интеграции веток<br />28<br />

86.
Архитектура программных средств<br />29<br />

87.
Заключение<br />Метод организациирепозитория исходного кода позволяет достичь:<br /><ul><li>Прозрачности процессов управления конфигурациями

88.
Улучшенного контроля и учета изменений при разработке программного обеспечения

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

90.
Использования усовершенствованных процессов тестирования и, как результат, ПО более высокого качества

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

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