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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

39. PHP_Depend

40. PHP_Codesniffer

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

43. phpDocumentor

44. Doxygen

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

63. Backup и restore11

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

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

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

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

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

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

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

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

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

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

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

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

80. В ветке поддержки версии: вся ветка N.x.x23

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

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

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

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

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

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

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

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

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

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

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