ОГЛАВЛЕНИЕ ВВЕДЕНИЕ .......................................................................................................... 2

ОГЛАВЛЕНИЕ
ВВЕДЕНИЕ .......................................................................................................... 2
1. ИНСТРУМЕНТЫ И МЕТОДЫ ПРОГРАММНОЙ ИНЖЕНЕРИИ ........... 4
1.1. Инструменты работы с требованиями (Software Requirements Tools) ........... 4
1.2. Инструменты проектирования (Software Design Tools) .................................. 5
1.3. Инструменты конструирования (Software Construction Tools) ....................... 5
1.4. Инструменты тестирования (Software Testing Tools) ...................................... 6
1.5. Инструменты сопровождения (Software Maintenance Tools) .......................... 7
1.6. Инструменты конфигурационного управления (Software Configuration
Management Tools).................................................................................................................... 7
1.7. Инструменты управления инженерной деятельностью (Software
Engineering Management Tools) ............................................................................................... 8
1.8. Инструменты поддержки процессов (Software Engineering Process Tools) ... 8
1.9. Инструменты обеспечения качества (Software Quality Tools) ........................ 8
1.10. Дополнительные аспекты инструментального обеспечения (Miscellaneous
Tool Issues) 9
2. ИНСТРУМЕНТЫ КОНСТРУИРОВАНИЯ (SOFTWARE
CONSTRUCTION TOOLS) ............................................................................... 10
2.1. Eclipse ................................................................................................................. 11
2.2. IntelliJ IDEA ....................................................................................................... 12
2.3. Netbeans .............................................................................................................. 13
3. КОНФИГУРАЦИОННОЕ УПРАВЛЕНИЕ ................................................ 14
3.1. Цели и задачи .................................................................................................... 14
3.2. Процедуры управления конфигурацией ......................................................... 14
3.3. Инструменты отслеживания (tracking) дефектов, расширений и проблем . 15
3.3.1. Состав информации о дефекте ............................................................... 15
3.3.2. Жизненный цикл дефекта ......................................................................... 15
3.3.3. Atlassian JIRA ............................................................................................. 16
3.3.4. Trac .............................................................................................................. 16
3.3.5. Redmine ....................................................................................................... 17
3.3.6. Сравнение ................................................................................................... 19
3.4. Инструменты управления версиями ............................................................... 19
3.4.1. Типичный порядок работы с системой .................................................. 21
3.4.2. Subversion ................................................................................................... 28
3.4.3. Mercurial ..................................................................................................... 29
3.4.4. Git ................................................................................................................ 29
3.5. Инструменты сборки и выпуска ...................................................................... 30
3.5.1. Автоматизация сборки ............................................................................. 30
3.5.2. Apache Ant ................................................................................................... 31
3.5.3. Apache Maven ............................................................................................. 32
3.6. Непрерывная интеграция ................................................................................. 32
3.6.1. Hudson/Jenkins ............................................................................................ 33
3.6.2. Репозитории............................................................................................... 34
ЗАКЛЮЧЕНИЕ ................................................................................................. 35
ЛИТЕРАТУРА ................................................................................................... 36
1
ВВЕДЕНИЕ
Программные инструменты предназначены для обеспечения поддержки
процессов жизненного цикла программного обеспечения. Инструменты позволяют
автоматизировать определенные повторяющиеся действия, уменьшая загрузку
инженеров рутинными операциями и помогая им сконцентрироваться на творческих,
нестандартных аспектах реализации выполняемых процессов. Инструменты часто
проектируются с целью поддержки конкретных (частных) методов программной
инженерии, сокращая административную нагрузку, ассоциированную с “ручным”
применением соответствующих методов. Так же, как и методы программной
инженерии, инструменты призваны сделать программную инженерию более
систематической деятельностью и по своему содержанию (предлагаемой
функциональности) могут варьироваться от поддержки отдельных индивидуальных
задач вплоть до охвата всего жизненного цикла (в этом случае часто говорят об
инструментальной платформе или просто платформе разработки).
Методы программной инженерии накладывают определенные структурные
ограничения на деятельность в рамках программной инженерии с целью приведения
этой деятельности в соответствие с заданным систематическим подходом и более
вероятным и скорым, с точки зрения соответствующего метода, достижением успеха.
Методы обычно предоставляют соответствующие соглашения (нотацию), словарь
<терминов и понятий> и процедуры выполнения идентифицированных (и
охватываемых методом) задач, а также рекомендации по оценке и проверке
<выполняемого> процесса и <получаемого в его результате> продукта. Методы, как и
инструменты, варьируются по содержанию (охватываемой области применения) от
отдельной фазы жизненного цикла (или даже процесса) до всего жизненного цикла.
Данная область знаний касается только методов, охватывающих множество фаз
(этапов) жизненного цикла. Те методы, применение которых фокусируется на
отдельных фазах жизненного цикла или частных процессах, описаны в
соответствующих областях знаний.
Существует множество детальных описаний и руководств по конкретным
инструментам, и исследований, посвященных анализу (и категоризации, в первую
очередь, со стороны аналитиков) уже применяемых и новых инструментальных средств
(и вероятным направлениям их развития). В таком контексте, общее техническое
описание инструментов программной инженерии, действительно, может отпугнуть. (В
то же время, с точки зрения автора, при всей неоднозначности любой категоризации
инструментов, может быть сформирован общий взгляд на их целевую
функциональность, пусть в чем то и спорный, что, отразится в определенных случаях
ниже в соответствующих авторских комментариях). Одна из основных сложностей
такого описания, в общем случае, заключается в высокой изменчивости и быстром
эволюционировании
программных
инструментов.
Конкретные
аспекты
функциональности инструментов достаточно быстро изменяются, что усложняет
приведение конкретных актуальных примеров.
Данная область знаний охватывает все процессы жизненного цикла и,
соответственно, связана со всеми другими областями знаний SWEBOK.
2
Инструменты и методы программной инженерии
3
1. ИНСТРУМЕНТЫ И МЕТОДЫ ПРОГРАММНОЙ ИНЖЕНЕРИИ
1.1. Инструменты работы с требованиями (Software Requirements Tools)
SWEBOK говорит о том, что инструменты, применяемые для работы с
требованиями могут быть классифицированы в две категории: средства моделирования
(modeling) и средства трассировки (traceability). Однако, на практике, моделирование
требований, все же, является частью управления требований, как, кстати, и
трассировка. В принципе, инструменты трассировки могут быть рассмотрены как
самостоятельная категория, в силу своей значимости при проведении анализа
требований, в первую очередь, анализа влияний требований и изменений (т.н. “impact
analysis”). Но моделирование требований лишь часть управления требованиями.
Поэтому, в приведенной ниже классификации предлагаемая модификация
оригинального SWEBOK состоит в том, что вместо “инструментов моделирования
требований” используется термин “инструменты управления требованиями”, при
сохранении оригинального содержания данной темы SWEBOK. Соответственно,


Инструменты управления требованиями (моделирования требований –
Requirements modeling tools). Эти инструменты используются для
извлечения (eliciting), анализа, специфицирования и проверки
программных требований.
Инструменты трассировки требований (Requirement traceability tools). Эти
инструменты становятся все более важными по мере повышения
сложности программного обеспечения. В силе того, что они также
относятся и к другим процессам жизненного цикла, здесь они
представлены в качестве самостоятельной категории средств работы с
требованиями.
Необходимо заметить, что трассировка является неотъемлемой частью
полноценной работы с требованиями, что приводит к естественному объединению
предлагаемых SWEBOK категорий инструментов в единый класс “инструментов
управления
требованиями”,
функциональное
содержание
которых
может
варьироваться, например, в зависимости от сложности проектов и уровня зрелости
процессов. Если мы обратимся, например, к модели CMMI Staged, мы увидим, что на 2м уровне зрелости речь идет об “управлении требованиями” – Requirement Management,
а на 3-м уровне зрелости обсуждается “разработка требований” – Requirement
Development, обладающая более ёмким содержанием. В то же самое время, с
технократической точки зрения, требования могут восприниматься и как элементы
конфигураций, наравне с запросами на изменения и другими активами проекта (см.
область знаний SWEBOK “Конфигурационное управление”). Таким образом, в ряде
случаев (что подтверждается конкретными программными средствами, доступными на
рынке программного обеспечения), в качестве инструмента работы с требованиями
может выступать и система конфигурационного управления, если, конечно, она
изначально не ограничена базовой функциональностью контроля версий <файлов>. С
другой стороны, сегодняшние средства моделирования на основе UML и BPMN могут
также рассматриваться как элементы инструментального обеспечения работы с
требованиями, что часто отражается в их функциональности, включающей тесную
интеграцию с “классическими” средствами управления требованиями, а сама
интеграция воплощена не только в визуальном представлении работы с репозиториями
требований, но и в автоматизации трассировки между моделями (и/или их элементами)
и требованиями, соответственно.
4
1.2. Инструменты проектирования (Software Design Tools)
Эта тема охватывает инструменты для создания и проверки программного
дизайна. Существует большое разнообразие таких инструментов, использующих
различные нотации (соглашения, в том числе визуальные) и методы. Несмотря на такое
разнообразие, <авторами SWEBOK> не было найдено <адекватной> классификации
этих инструментов.
Однако, в данном случае, все же возможно разделение инструментов по
нескольким критериям, например, применяемым базовым нотациям моделирования и
проектирования (SADT/IDEF, UML, BPMN/BPEL, Microsoft DSL и т.п.) или целевым
задачам (бизнес-моделирование, проектирование БД, объектно-ориентированное
проектирование, интеграционное/SOA-проектирование и т.п.).
1.3. Инструменты конструирования (Software Construction Tools)
Данная тема касается инструментальных средств конструирования
программного обеспечения, в соответствии с пониманием “конструирования”,
заданным соответствующей областью знаний SWEBOK, рассматривавшейся ранее. Эти
инструменты используются для производства и трансляции программного
представления (например, исходного кода), достаточно детального и явного для
машинного выполнения.



Редакторы (program editors). Эти инструменты используются для
создания и модификации <исходного кода> программ и, возможно,
ассоциированной с ними документации. Это могут быть как редакторы
“общего назначения” (что на протяжении многих лет наблюдается в
UNIX и unix-подобных средах) или специализированные редакторы с
поддержкой специфики целевого языка программирования (что является,
в большинстве случаев, прерогативой интегрированных сред разработки
– IDE). В то же время, документирование все же является не только и не
столько
частью
редактора,
сколько
самостоятельной
функциональностью, пусть часто и тесно интегрированной с редактором.
Компиляторы и генераторы кода (compilers and code generators).
Традиционно, компиляторы являлись неинтерактивными (командными)
трансляторами исходного кода. Однако, существует тенденция (с точки
зрения автора, более чем явная, что отмечено ниже) интеграции
компиляторов
и
редакторов
в
интегрированные
среды
программирования. К этому классу также относятся препроцессоры,
линковщики/загрузчики, а также генераторы кода (за исключением,
может быть, объектно-ориентированных средств проектирования,
поддерживающих связь с исходным кодом и имеющих тенденцию быть
тесно интегрированными с новым поколением IDE).
Интерпретаторы (interpreters). Эти инструменты обеспечивают
исполнение программ посредством эмуляции. Они могут поддерживать
действия по конструированию программного обеспечения, предоставляя
для исполнения программ окружение, более контролируемое и
поддающееся наблюдению, чем это обычно способна сделать та или иная
операционная система.
Хочется отметить определенное “слияние”, если так можно выразиться, между
компиляторами и интерпретаторами. Ярким тому свидетельством является
использование так называемой just-in-time компиляции – компиляции “на лету”, когда
5
промежуточный программный код, по мере исполнения или с опережением (например,
в процессе запуска/загрузки программы) преобразуется в набор инструкций,
исполняемых непосредственно средствами операционной системы, но под контролем
среды исполнения, в первую очередь, с точки зрения безопасности. Такого рода подход
стал родоначальником ряда современных программных платформ, например, Java и
.NET. На этом фоне, возможно было бы объединить интерпретаторы с компиляторами
и генераторами кода, как средства непосредственной подготовки (трансляции)
исходного кода к исполнению.

Отладчики (debuggers). Эти инструменты было принято выделить в
самостоятельную категорию, так как они поддерживают процесс
конструирования программного обеспечения, но, в то же время,
<функционально> отличаются от редакторов и компиляторов.
С точки зрения классификации инструментов необходимо выделить явно и
давно присутствующие на рынке: “интегрированные средства разработки” (IDE integrated developers environment), а также программные библиотеки/библиотеки
компонент (frameworks, libraries, components), без которых просто невозможно
представить сегодняшний процесс разработки, да и рынок программных средств, в
целом. Кроме того, в данной теме можно говорить и о таких функционально ёмких
“супер”-категориях, как “программная платформа” (например, Java, J2EE и Microsoft
.NET) и “платформа облачных вычислений” (например, Microsoft Azure, Amazon и др.),
которые включают наравне с инструментами, как таковыми, и определенные модели
конструирования, преобразования и выполнения кода. При таком подходе, вероятно,
обоснованным было бы введение класса “элементарных” или “базовых инструментов
конструирования”, к которому можно было бы отнести редакторы, компиляторы,
интерпретаторы, отладчики, средства документирования и библиотеки, а также класса
“комплексных средств конструирования” – интегрированных сред и различных
платформ, что, безусловно, не претендует на истину в последней инстанции и является
одной из возможных точек зрения.
1.4. Инструменты тестирования (Software Testing Tools)





Генераторы тестов (test generators). Эти инструменты помогают в
разработке сценариев тестирования.
Средства выполнения тестов (test execution frameworks). Эти средства
обеспечивают среду исполнения тестовых сценариев в контролируемом
окружении,
позволяющем
отслеживать
поведение
объекта,
подвергаемого тестированию.
Инструменты оценки тестов (test evaluation tools). Эти инструменты
поддерживают оценку результатов выполнения тестов, помогая
определить в какой степени и где именно обнаруженное поведение
<тестируемого объекта> соответствует ожидаемому поведению.
Средства управления тестами (test management tools). Эти средства
обеспечивают поддержку всех аспектов процесса тестирования
программного обеспечения.
Инструменты анализа производительности (performance analysis tools).
Эти инструменты используются для количественной оценки и анализа
производительности
программного
обеспечения,
являющегося
специализированным видом тестирования, цель которого – в оценки
поведения программ в части производительности, в отличие от
тестирования <корректности> функционального поведения.
6
Последний класс инструментов тестирования, в какой-то степени, показывает
недостаточностьпредложенной классификации, упуская, например, инструменты
функционального тестирования, средства тестирования безопасности, инструменты
тестирования пользовательского интерфейса, инструменты нагрузочного тестирования
и др., соответствующие, различным целям тестирования, представленным в секции 2.2
области знаний SWEBOK “Тестирование”, и естественно задающим “подвиды”
возможного класса “специализированных или целевых инструментов тестирования”, к
которым, в частности, относится тестирование производительности.
1.5. Инструменты сопровождения (Software Maintenance Tools)
Эта тема охватывает инструменты, особенно важные для обеспечения
сопровождения существующего программного обеспечения, подверженного
модификациям. SWEBOK идентифицирует две категории таких инструментов:


Инструменты облегчения понимания (comprehension tools). Эти
инструменты помогают человеку в понимании программ. Примерами
могут служить различные средства визуализации.
Инструменты реинжиниринга (reengineering tools). Эти инструменты
поддерживают деятельность по реинжинирингу, описанную в области
знаний SWEBOK “Software Maintenance”.
Средства “обратного” инжиниринга (reverse engineering) помогают в процессе
восстановления для существующего программного обеспечения таких артефактов, как
спецификация и описание дизайна (архитектуры), которые, в дальнейшем, могут быть
трансформированы для генерации нового продукта на основе функциональности
существующего.
Последнее замечание, в сочетании с типичной функциональностью
современных средств проектирования, поддерживающих анализ исходного кода (в
случае объектно-ориентированных систем) и его визуализацию (в том числе,
поведенческую, например, в виде диаграмм UML Sequence), позволяет объединить
упомянутые категории инструментов в единый класс “инструментов реинжиниринга”.
В то же время, деятельность по сопровождению и поддержке, в частности, касающаяся
сбоев и исправления обнаруженных ошибок в программном обеспечении, требует, в
определенной степени, отнесения к этой теме и средств конфигурационного
управления, рассматриваемых ниже (например, в части обработки запросов на
изменения).
1.6. Инструменты конфигурационного управления (Software Configuration
Management Tools)
Инструменты конфигурационного управления делятся на три категории:



Инструменты отслеживания (tracking) дефектов, расширений и проблем.
Инструменты управления версиями.
Инструменты сборки и выпуска. Эти инструменты предназначены для
управления задачами сборки и выпуска продуктов, а также включают
средства инсталляции.
Дополнительная информация по данной теме представлена в области знаний
SWEBOK “Конфигурационное управление”.
7
1.7. Инструменты управления инженерной деятельностью (Software
Engineering Management Tools)
Средства управления деятельностью по программной инженерии делятся на три
категории:



Инструменты планирования и отслеживания проектов. Эти средства
используются календарного планирования работ, количественной оценки
усилий и стоимостных ожиданий, связанных с проектами.
Инструменты управления рисками. Эти средства используются для
идентификации, оценки ожиданий и мониторинга рисков.
Инструменты количественной оценки. Эти инструменты ведения
измерений помогают в выполнении работ, связанных с программой
количественной оценки, проводимой в отношении проектов
программного обеспечения.
Функциональные аспекты управления инженерной деятельностью достаточно
детально представлены в области знаний SWEBOK “Управление программной
инженерией” (Software Engineering Management).
1.8. Инструменты поддержки процессов (Software Engineering Process Tools)
В описании этой темы в текущей версии SWEBOK наблюдается противоречие
между кратким делением на категории инструментов и их более детальным
определением. Скорее всего, такая несогласованность связана, в первую очередь, с
отсутствием достигнутого консенсуса в этой области. Базируясь на обеих
классификациях, упомянутых в SWEBOK, хотелость бы отметить несколько типов
инструментов из “смежных” областей, имеющих особое значение в поддержке
процессов программной инженерии:




Инструменты моделирования, позволяющие, в частности, описать и
модель процессов, как таковую.
Инструменты управления проектами.
Инструменты конфигурационного управления, поддерживающие работу
с актуальными версиями всего комплекса артефактов проекта и, что не
менее важно, позволяющие задать поведенческие характеристики (в
упрощенном понимании - workflow) и атрибуты этих артефактов в форме
элементов конфигураций.
Ролевые
платформы
разработки
программного
обеспечения,
охватывающие все стадии жизненного цикла и, на сегодняшний день,
являющиеся развитием интегрированных средств разработки и CASEинструментов в направлении поддержки “смежной” функциональности –
управления требованиями, работ по конфигурационному управлению с
поддержкой управления изменениями, тестирования и оценки качества.
Первые три вида инструментов в такой классификации позволяют описать
применяемые процессы программной инженерии. Четвертый класс – “суперинтегрированные среды разработки”, называемые сегодня ролевыми платформами
разработки, обеспечивают поддержку заданных процессов, описанных, например, в
виде соответствующих правил на уровне глубоко интегрированных в такие среды
инструментов конфигурационного управления.
1.9. Инструменты обеспечения качества (Software Quality Tools)
Средства обеспечения качества делятся на две категории:
8


Инструменты инспектирования. Эти средства используются для
поддержки обзора (review) и аудита.
Инструменты (статического) анализа. Эти средства используются для
анализа программных артефактов, данных, потоков работ и
зависимостей. Такие инструменты предназначены для проверки
определенных свойств или артефактов, в целом, на соответствие
<заданным характеристикам>.
1.10. Дополнительные аспекты инструментального обеспечения (Miscellaneous
Tool Issues)
Эта тема охватывает вопросы, касающиеся всех классов инструментов.
Создателями SWEBOK идентифицированы три категории таких аспектов:


Техники интеграции инструментов. Эти техники важны для
естественного использования сочетания различных инструментов.
Типичные виды интеграции инструментов включают платформы,
представление, процессы, данные и управление.
Мета-инструменты. Такие средства генерируют другие инструменты.
Например, классическим примером мета-инструмента является
компилятор компиляторов.
Оценка инструментов. Данная тема представляется достаточно важной в силу
постоянной эволюции инструментов программной инженерии.
9
2. ИНСТРУМЕНТЫ КОНСТРУИРОВАНИЯ (SOFTWARE
CONSTRUCTION TOOLS)
Интегри́рованная среда́ разрабо́тки, ИСР (англ. IDE, Integrated development
environment или integrated debugging environment) — система программных средств,
используемая программистами для разработки программного обеспечения (ПО).
Интегрированные среды разработки были созданы для того, чтобы
максимизировать производительность программиста благодаря тесно связанным
компонентам с простыми пользовательскими интерфейсами. Это позволит
разработчику сделать меньше действий для переключения различных режимов, в
отличие от дискретных программ разработки. Однако, так как IDE является сложным
программным комплексом, то лишь после долгого процесса обучения среда разработки
сможет качественного ускорить процесс разработки ПО.
Обычно IDE ориентирована на определенный язык программирования,
предоставляя набор функций, который наиболее близко соответствует парадигмам
этого языка программирования. Однако, есть некоторые IDE с поддержкой нескольких
языков, такие как Eclipse, ActiveState Komodo, последние версии NetBeans, Microsoft
Visual Studio, WinDev и Xcode.
IDE обычно представляет из себя единственную программу, в которой
проводилась вся разработка. Она обычно содержит много функций для создания,
изменения, компилирования, развертывания и отладки программного обеспечения.
Цель среды разработки заключается в том, чтобы абстрагировать конфигурацию,
необходимую, чтобы объединить утилиты командной строки в одном модуле, который
позволит уменьшить время, чтобы изучить язык, и повысить производительность
разработчика. Также считается, что трудная интеграция задач разработки может далее
повысить производительность. Например, IDE позволяет проанализировать код и тем
самым обеспечить мгновенную обратную связь и уведомить о синтаксических
ошибках. В то время как большинство современных IDE является графическим, они
использовались еще до того, как появились системы управления окнами (которые
реализованы в Microsoft Windows или X11 для *nix-систем). Они были основаны на
тексте, используя функциональные клавиши или горячие клавиши, чтобы выполнить
различные задачи (например, Turbo Pascal). Использование IDE для разработки
программного обеспечения является прямой противоположностью способа, в котором
используются несвязанные инструменты, такие как vi (текстовый редактор), GCC
(компилятор), и т.п.
10
IDE
BlueJ
DrJava
Eclipse JDT
Geany
Greenfoot
IntelliJ IDEA
JBuilder
JCreator
JDeveloper
jGRASP
JVM
Windo
ws
Lin
ux
Ma
c
OS
X
Other
platfor
ms
GUI
builder
Yes
Yes
Yes
Yes
Solaris
No
Yes
Yes
No
Yes
Yes
Yes
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
Yes
Yes
Yes
Yes
Yes
Yes
No
Solaris
Solaris
Solaris
Solaris
No
Yes
No
No
Yes
Yes
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
GPL
No
No
Yes
No
Solaris
Proprietary
CDDL, GPL2
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Solaris
Proprietary
Yes
Yes
Yes
No
Solaris,
AIX
Yes
Yes
Yes
Yes
Solaris
Yes
No
No
Yes
License
GPL2+GNU linking
exception
Permissive
EPL
GPL
GPL
ALv2, proprietary
Proprietary
Proprietary
Proprietary OTN
JDeveloper License
(freeware)
Proprietary (freeware)
KDevelop
MyEclipse
NetBeans
Rational
Application
Developer
Servoy
Proprietary
Xcode
Proprietary
Unkno
wn
No
Solaris
generic
JVM
Yes
No
Unkno
wn
Yes
Yes
Yes
2.1. Eclipse
История
Первоначально Eclipse разрабатывалась фирмой IBM как преемник среды
разработки IBM VisualAge, в качестве корпоративного стандарта IDE для разработки на
разных языках под платформы IBM. По сведениям IBM, проектирование и разработка
стоили 40 миллионов долларов. [2] Исходный код был полностью открыт и сделан
доступным после того, как Eclipse был передан для дальнейшего развития
независимому от IBM сообществу.
В Eclipse 3.0 (2003 год) были выбраны спецификации сервисной платформы
OSGi, как архитектура времени выполнения. С версии 3.0 Eclipse перестал быть
монолитной IDE, поддерживающей расширения, а сам стал набором расширений. В
основе лежат фреймворк OSGi и SWT/JFace, на основе которых разработан следующий
слой — RCP (Rich Client Platform, платформа для разработки полноценных клиентских
приложений). RCP служит основой не только для Eclipse, но и для других RCPприложений, например Azureus и File Arranger. Следующий слой — сам Eclipse,
представляющий собой набор расширений RCP — редакторы, панели, перспективы,
модуль CVS и модуль Java Development Tools (JDT).
11
Преимущества
Eclipse — в первую очередь служит платформой для разработки расширений,
чем он и завоевал популярность: любой разработчик может расширить Eclipse своими
модулями. Уже существуют Java Development Tools (JDT), C/C++ Development Tools
(CDT), разрабатываемые инженерами QNX совместно с IBM, и средства для языков
COBOL, FORTRAN, PHP и пр. от различных разработчиков. Множество расширений
дополняет среду Eclipse менеджерами для работы с базами данных, серверами
приложений и др.
Eclipse JDT (Java Development Tools) — наиболее известный модуль, нацеленная
на групповую разработку: среда интегрирована с системами управления версиями —
CVS,GIT в основной поставке, для других систем (например, Subversion, MS
SourceSafe) существуют плагины. Также предлагает поддержка связи между IDE и
системой управления задачами (ошибками). В основной поставке включена поддержка
трекера ошибок Bugzilla, также имеется множество расширений для поддержки других
трекеров (Tract, Jira и др.). В силу бесплатности и высокого качества, Eclipse во многих
организациях является корпоративным стандартом для разработки приложений.
Eclipse написана на Java, потому является платформо-независимым продуктом,
за исключением библиотеки SWT, которая разрабатывается для всех распространённых
платформ. Библиотека SWT используется вместо стандартной для Java библиотеки
Swing. Она полностью опирается на нижележащую платформу (операционную
систему), что обеспечивает быстроту и натуральный внешний вид пользовательского
интерфейса, но иногда вызывает на разных платформах проблемы совместимости и
устойчивости приложений.
2.2. IntelliJ IDEA
Первая версия IntelliJ IDEA появилась в январе 2001 года и быстро приобрела
популярность, как первая Java IDE с широким набором интегрированных инструментов
для рефакторинга, которые позволяли программистам быстро реорганизовывать
исходные тексты программ. Дизайн среды ориентирован на продуктивность работы
программистов, позволяя им сконцентрироваться на разработке функциональности, в
то время как IntelliJ IDEA берет на себя выполнение рутинных операций.
Начиная с шестой версии продукта IntelliJ IDEA предоставляет
интегрированный инструментарий для разработки графического пользовательского
интерфейса.
Среди прочих возможностей, IntelliJ IDEA хорошо совместима со многими
популярными open source инструментами разработчиков, такими как CVS, Subversion,
Apache Ant, Maven и JUnit. В феврале 2007 года разработчики IntelliJ анонсировали
раннюю версию плагина для поддержки программирования на языке Ruby[2].
Начиная с версии 9.0, IntelliJ IDEA доступна в двух версиях: Community Edition
и Ultimate Edition. Community Edition является полностью open-source версией,
доступной под лицензией Apache 2.0. В ней реализована полная поддержка Java SE,
Groovy, Scala, а также интеграция с наиболее популярными системами управления
версиями. В версии Ultimate Edition реализована поддержка Java EE, UML-диаграмм,
подсчет покрытия кода, а также поддержка других систем управления версиями,
языков и фреймворков.
12
2.3. Netbeans
NetBeans IDE — свободная интегрированная среда разработки приложений
(IDE) на языках программирования Java, JavaFX, Python, PHP, JavaScript, C++, Ада[1] и
ряде других.
Для разработки программ в среде NetBeans и для успешной инсталляции и
работы самой среды NetBeans должен быть предварительно установлен Sun JDK или
J2EE SDK подходящей версии. Среда разработки NetBeans по умолчанию
поддерживала разработку для платформ J2SE и J2EE. Начиная с версии 6.0 Netbeans
поддерживает разработку для мобильных платформ J2ME, C++ (только g++) и PHP без
установки дополнительных компонентов.
Проект NetBeans IDE поддерживается и спонсируется компанией Oracle, однако
разработка NetBeans ведется независимо сообществом разработчиков-энтузиастов
(NetBeans Community) и компанией NetBeans Org.
По качеству и возможностям последние версии NetBeans IDE не уступают
лучшим коммерческим (платным) интегрированным средам разработки для языка Java,
таким, как IntelliJ IDEA, поддерживая рефакторинг, профилирование, выделение
синтаксических конструкций цветом, автодополнение набираемых конструкций на
лету, множество предопределённых шаблонов кода и др.
В версии NetBeans IDE 6.1[2] декларируется поддержка UML, SOA, языка
программирования Ruby (включая поддержку Ruby on Rails), а также средства для
создания приложений на J2ME для мобильных телефонов. В версии 6.5 добавлена
поддержка языка PHP. Также для тестирования выложен модуль поддержки Python[3].
NetBeans IDE поддерживает плагины, позволяя разработчикам расширять
возможности среды. Одним из самых популярных плагинов является мощный дизайнер
отчётов iReport[4] (основанный на библиотеке JasperReports).
На идеях, технологиях и в значительной части на исходном коде NetBeans IDE
базируются предлагаемые фирмой Sun коммерческие интегрированные среды
разработки для Java — Sun Java Studio Creator, Sun Java Studio Enterprise и Sun Studio
(для ведения разработки на C, C++ или Фортран). Сравнительно недавно Sun стала
предлагать эти среды разработки бесплатно для зарегистрировавшихся в Sun Developer
Network (SDN) разработчиков, сама же регистрация на сайте бесплатна и не требует
никаких предварительных условий, кроме согласия с лицензией CDDL.
NetBeans IDE доступна в виде готовых дистрибутивов (прекомпилированных
бинарных файлов) для платформ Microsoft Windows, Linux, FreeBSD, Mac OS X,
OpenSolaris и Solaris (как для SPARC, так и для x86 — Intel и AMD). Для всех
остальных платформ доступна возможность скомпилировать NetBeans самостоятельно
из исходных текстов.
В релизе NetBeans IDE 6.7 была добавлена интеграция с Project Kenai[5],
поддержка языка Groovy и веб-фреймворка Grails. В версии 6.8 — поддержка PHPфреймворка Symfony, а в 6.9 — Zend Framework.
13
3. КОНФИГУРАЦИОННОЕ УПРАВЛЕНИЕ
Software Configuration Management или Конфигурационное управление
подразумевает под собой комплекс методов, направленных на то, чтобы
систематизировать изменения, вносимые разработчиками в программный продукт в
процессе его разработки и сопровождения, сохранить целостность системы после
изменений, предотвратить нежелательные и непредсказуемые эффекты, а также сделать
процесс внесения изменений более формальным.
В целом, конфигурационное управление отвечает на вопрос: «Кто-то уже сделал
нечто, как нам это воспроизвести?»
Изначально управление конфигурацией применялось не в программировании.
Под конфигурацией понимался состав деталей конечного продукта и «взаимное
расположение частей» физического изделия. Таким образом, конфигурацией можно
управлять, контролируя документы, описывающие конечный продукт, требования к
нему, всю его проектную и технологическую документацию.
В связи с высокой динамичностью сферы разработки ПО, в ней
конфигурационное управление особенно полезно. К процедурам можно отнести
создание резервных копий, контроль исходного кода, требований проекта,
документации и т. д. Степень формальности выполнения данных процедур зависит от
размеров проекта, и при правильной её оценке данная концепция может быть очень
полезна.
3.1. Цели и задачи
Цели конфигурационного управления:




Контроль: SCM позволяет отслеживать изменения в контролируемых
объектах, обеспечивает соблюдение процесса разработки
Управление: SCM диктует процесс автоматической идентификации в
ходе всего жизненного цикла ПО, обеспечивает простоту модификации и
сопровождения ПО
Экономия средств: снизижается риск потерь от ротации кадров в
организации, предоставить возможность сменить организациюразработчика без перепроектирования
Качество
Задачи конфигурационного управления:







идентификация конфигурации
контроль конфигурации: контроль над изменениями материалов
учёт текущего состояния: состояние документов, состояние кода,
состояние отдельных задач и всего проекта в целом
управление процессом разработки
управление сборкой
управление окружением
отслеживание задач и проблем (в частности, отслеживание ошибок)
3.2. Процедуры управления конфигурацией
Ревизия конфигурации — процесс проверки того, что документ нижнего уровня
соответствует всем требованиям документа верхнего уровня.
14
Аудит конфигурации — процесс проверки того, что готовый продукт или его
часть соответствуют документации.
Контроль конфигурации — процесс, при котором все предлагаемые изменения
продукта проходят одобрение специальной группы (или отдельного человека). Одна из
функций такой группы — контроль актуальности всех имеющихся документов, а также
контроль того что все изменения сначала вносятся в документацию, а уже затем в
объект изменения.
Учет состояния конфигурации — процесс подготовки отчетов о текущем
состоянии продукта и состоянии утвержденных изменений.
3.3. Инструменты отслеживания (tracking) дефектов, расширений и проблем
Система отслеживания ошибок (англ. bug tracking system) — прикладная
программа, разработанная с целью помочь разработчикам программного обеспечения
(программистам, тестировщикам и др.) учитывать и контролировать ошибки (баги),
найденные в программах, пожелания пользователей, а также следить за процессом
устранения этих ошибок и выполнения или невыполнения пожеланий.
3.3.1. Состав информации о дефекте
Главный компонент такой системы — база данных, содержащая сведения об
обнаруженных дефектах. Эти сведения могут включать в себя:










номер (идентификатор) дефекта;
кто сообщил о дефекте;
дата и время, когда был обнаружен дефект;
версия продукта, в которой обнаружен дефект;
серьёзность (критичность) дефекта и приоритет решения[1];
описание шагов для выявления дефекта (воспроизведения неправильного
поведения программы);
кто ответственен за устранение дефекта;
обсуждение возможных решений и их последствий;
текущее состояние (статус) дефекта;
версия продукта, в которой дефект исправлен.
Кроме того, развитые системы предоставляют возможность прикреплять файлы,
помогающие описать проблему (например, дамп памяти или скриншот).
3.3.2. Жизненный цикл дефекта
Как правило, система отслеживания ошибок использует тот или иной вариант
«жизненного цикла» ошибки, стадия которого определяется текущим состоянием, или
статусом, в котором находится ошибка.
Типичный жизненный цикл дефекта:



Новый — дефект зарегистрирован тестировщиком
Назначен — назначен ответственный за исправление дефекта
Разрешён — дефект переходит обратно в сферу ответственности
тестировщика. Как правило, сопровождается резолюцией, например:
o Исправлено (исправления включены в версию такую-то)
o Дубль (повторяет дефект, уже находящийся в работе)
15


o Не исправлено (работает в соответствии со спецификацией, имеет
слишком низкий приоритет, исправление отложено до следующей
версии и т. п.)
o «У меня всё работает» (запрос дополнительной информации об
условиях, в которых дефект проявляется)
Далее тестировщик проводит проверку исправления, в зависимости от
чего дефект либо снова переходит в статус Назначен (если он описан как
исправленный, но не исправлен), либо в статус Закрыт.
Открыт повторно — дефект вновь найден в другой версии.
Система может предоставлять администратору возможность настроить, какие
пользователи могут просматривать и редактировать ошибки в зависимости от их
состояния, переводить их в другое состояние или удалять.
В корпоративной среде, система отслеживания ошибок может использоваться
для получения отчётов, показывающих продуктивность программистов при
исправлении ошибок. Однако, часто такой подход не даёт достаточно точных
результатов, из-за того что разные ошибки имеют различную степень серьёзности и
сложности. При этом серьёзность проблемы не имеет прямого отношения к сложности
устранения ошибки.
3.3.3. Atlassian JIRA
Atlassian JIRA — коммерческая система отслеживания ошибок, предназначена
для организации общения с пользователями, хотя в некоторых случаях систему можно
использовать для управления проектами. Разработана компанией Atlassian Software
Systems. Платная. Имеет веб-интерфейс. Название системы (JIRA) было получено
путём модификации названия конкурирующего продукта — Bugzilla.[1] JIRA
создавалась в качестве замены Bugzilla и во многом повторяет архитектуру Bugzilla.
Система позволяет работать с несколькими проектами. Для каждого из проектов
создаёт и ведёт схемы безопасности и схемы оповещения.
3.3.4. Trac
Trac — инструмент управления проектами и отслеживания ошибок в
программном обеспечении.
Trac является открытым программным обеспечением, разработанным и
поддерживаемым компанией Edgewall Software (не путать с TrackStudio Enterprise и
Track+, другими системами аналогичного назначения).
Trac использует минималистичный веб-интерфейс, основанный на технологии
Wiki, и позволяет организовать перекрёстные гиперссылки между базой данных
зарегистрированных ошибок, системой управления версиями и вики-страницами. Это
даёт возможность использовать Trac в том числе и как веб-интерфейс для доступа к
системе контроля версий Subversion, а также, через плагины, к Mercurial, Git, Bazaar и
другим.
Поддерживаются базы данных SQLite, PostgreSQL, MySQL и MariaDB (англ.)[1].
Trac написан на языке программирования Python и в настоящее время
распространяется по модифицированной лицензии BSD. В качестве системы HTMLшаблонов веб-интерфейса Trac до версии 0.11 использовал ClearSilver. Новые версии,
начиная с 0.11, используют разработанную в Edgewall систему шаблонов Genshi[2], при
этом совместимость с плагинами, использующими ClearSilver, будет оставлена еще в
течение нескольких версий.
16
3.3.5. Redmine
Redmine — открытое серверное веб-приложение для управления проектами и
отслеживания ошибок. Redmine написан на Ruby и представляет собой приложение на
основе широко известного веб-фреймворка Ruby on Rails. Распространяется согласно
GNU General Public License.
Функциональные возможности
Данный продукт предоставляет следующие возможности:
















ведение нескольких проектов;
гибкая система доступа, основанная на ролях;
система отслеживания ошибок;
диаграммы Ганта и календарь;
ведение новостей проекта, документов и управление файлами;
оповещение об изменениях с помощью RSS-потоков и электронной
почты;
вики для каждого проекта;
форумы для каждого проекта;
учёт временных затрат;
настраиваемые произвольные поля для инцидентов, временных затрат,
проектов и пользователей;
лёгкая интеграция с системами управления версиями (SVN, CVS, Git,
Mercurial, Bazaar и Darcs);
создание записей об ошибках на основе полученных писем;
поддержка множественной аутентификации LDAP;
возможность самостоятельной регистрации новых пользователей;
многоязыковой интерфейс (в том числе русский);
поддержка СУБД MySQL, PostgreSQL, SQLite, Oracle.
Недостатки






Управление файлами и документами в Redmine сводится к их
добавлению, удалению и редактированию. Правами доступа ни к файлам,
ни к отдельным документам управлять нельзя.
Отсутствуют оповещения об изменении документов.
В Redmine нельзя управлять правами доступа на уровне отдельных полей
задачи. Например, на данный момент от клиентов нельзя скрыть оценки
времени работы над проектом или информацию о потраченном времени.
В Redmine можно управлять правами доступа на уровне проектов, но
нельзя назначить права на какую-то версию проекта или отдельную
задачу. Это значит, что если пользователю нужен доступ всего к одной
задаче, то придется давать доступ ко всему проекту.
Если пользователь Redmine получил доступ к проекту, то сейчас нельзя
ограничить его активность какими-то отдельными типами задач
(трекерами). Например, нельзя разрешить просматривать только «свои»
задачи (это часто бывает нужно для организации техподдержки) или
разрешить создавать задачи только какого-то определенного типа.
В Redmine все дополнительные поля доступны всем пользователям, все
участники проекта смогут их видеть и изменять. Это ограничение может
17



привести к сложностям при наличии неоднородной команды, когда
доступ к проекту имеют и менеджеры, и разработчики, и клиенты.
В Redmine нет прав на отдельные типы переходов в workflow. Например,
сейчас нельзя указать, что когда кто-то заканчивает исправлять ошибку,
он должен выбрать ответственным тестировщика и должен указать номер
билда. Также нельзя скрыть внутреннюю переписку между
программистами от клиента.
В Redmine в список задач не выводится общая трудоемкость задач, а в
отчетах по трудоемкости нельзя делать отборы, в том числе и по
исполнителю.
В Redmine не реализовано делегирование задач — нельзя передать задачу
другому исполнителю, отметив, что задача должен исполнять он, но
оставив себе наблюдение за задачей.
18
3.3.6. Сравнение
Системы
отслеживания
ошибокСистема
Redmine
Trac
Jean-Philippe Lang
Edgewall
Software
GPL v2
BSD variant
Ruby on Rails
Python
Web, e-mail, RSS
Web, E-mail, Atom, iPhone(iRedmine)
Web
Серверная часть
DB2, Firebird, HSQLDB,
MaxDB, Mckoi, MySQL,
Oracle, PostgreSQL, SQL
Server, Sybase ASA
MySQL, PostgreSQL, SQLite
SQLite,
PostgreSQL,
MySQL
Интеграция с
системами
управления
версиями кода
ClearCase, AccuRev,
Perforce, CVS,
Subversion, Visual
SourceSafe (beta)
Да, Subversion, CVS, Bazaar, Darcs,
Mercurial, git
Да, Subversion
(built-in), Darcs,
Bazaar,
Mercurial,
Perforce, Git
Atlassian Confluence
(enterprise wiki)
Да, integrated wiki, discussion
forums, news blogs, email integration,
calendars, Gantt Charts, Экспорт в
PDF, Экспорт в Excel/CSV
Да, integrated
wiki
Создатель
Лицензия
Язык реализации
Пользовательский
интерфейс
Интеграция с или
генерация
динамической
документации
Интеграция с
планированием
тестов
Настраиваемый
workflow
Поддержка
Юникода
LDAP авторизация
Дата выпуска
Последнее
обновление
JIRA
Atlassian Software
Systems
проприетарное ПО,
бесплатная для
некоммерческого
использования
Java
Atlassian Bamboo
(continuous integration &
testing, via plugin)
plugin
Да
Да
Да
Да
Да
Да
Да
2003
Да
2006
plugin
01.10.2006
2010-February-25
07.03.2011
30.03.2009
3.4. Инструменты управления версиями
истема управления версиями (от англ. Version Control System, VCS или Revision
Control System) — программное обеспечение для облегчения работы с изменяющейся
информацией. Система управления версиями позволяет хранить несколько версий
одного и того же документа, при необходимости, возвращаться к более ранним
версиям, определять, кто и когда сделал то или иное изменение и многое другое.
Такие системы наиболее широко применяются при разработке программного
обеспечения, для хранения исходных кодов разрабатываемой программы. Однако, они
могут с успехом применяться и в других областях, в которых ведётся работа с большим
количеством непрерывно изменяющихся электронных документов, в частности, они
19
применяются в САПР, обычно, в составе систем управления данными об изделии
(PDM). Управление версиями используется в инструментах конфигурационного
управления (Software Configuration Management Tools).
Ситуация, когда электронный документ за время своего существования
претерпевает ряд изменений, достаточно типична. При этом часто бывает важно иметь
не только последнюю версию, но и несколько предыдущих. В простейшем случае,
можно просто хранить несколько вариантов документа, соответствующим образом их
нумеруя. Но такой способ неэффективен (приходится хранить несколько практически
идентичных копий), требует повышенного внимания и дисциплины и часто ведёт к
ошибкам. Поэтому были разработаны средства для автоматизации этой работы.
Традиционные системы управления версиями используют централизованную
модель, когда имеется единое хранилище документов, управляемое специальным
сервером, который и выполняет бо́льшую часть функций по управлению версиями.
Пользователь, работающий с документами, должен сначала получить нужную ему
версию документа из хранилища; обычно создаётся локальная копия документа, т. н.
«рабочая копия». Может быть получена последняя версия или любая из предыдущих,
которая может быть выбрана по номеру версии или дате создания, иногда и по другим
признакам. После того, как в документ внесены нужные изменения, новая версия
помещается в хранилище. В отличие от простого сохранения файла, предыдущая
версия не стирается, а тоже остаётся в хранилище и может быть оттуда получена в
любое время. Сервер может использовать т. н. дельта-компрессию — такой способ
хранения документов, при котором сохраняются только изменения между
последовательными версиями, что позволяет уменьшить объём хранимых данных.
Поскольку обычно наиболее востребованной является последняя версия файла, система
может при сохранении новой версии сохранять её целиком, заменяя в хранилище
последнюю ранее сохранённую версию на разницу между этой и последней версией.
Некоторые системы (например, ClearCase) поддерживают сохранение версий обоих
видов: большинство версий сохраняется в виде дельт, но периодически (по
специальной команде администратора) выполняется сохранение версий всех файлов в
полном виде; такой подход обеспечивает максимально полное восстановление истории
в случае повреждения репозитория.
Иногда создание новой версии выполняется незаметно для пользователя
(прозрачно), либо прикладной программой, имеющей встроенную поддержку такой
функции, либо за счёт использования специальной файловой системы. В этом случае
пользователь просто работает с файлом, как обычно, и при сохранении файла
автоматически создаётся новая версия.
Часто бывает, что над одним проектом одновременно работают несколько
человек. Если два человека изменяют один и тот же файл, то один из них может
случайно отменить изменения, сделанные другим. Системы управления версиями
отслеживают такие конфликты и предлагают средства их решения. Большинство
систем может автоматически объединить (слить) изменения, сделанные разными
разработчиками. Однако такое автоматическое объединение изменений, обычно,
возможно только для текстовых файлов и при условии, что изменялись разные
(непересекающиеся) части этого файла. Такое ограничение связано с тем, что
большинство систем управления версиями ориентированы на поддержку процесса
разработки программного обеспечения, а исходные коды программ хранятся в
текстовых файлах. Если автоматическое объединение выполнить не удалось, система
может предложить решить проблему вручную.
20
Часто выполнить слияние невозможно ни в автоматическом, ни в ручном
режиме, например, если формат файла неизвестен или слишком сложен. Некоторые
системы управления версиями дают возможность заблокировать файл в хранилище.
Блокировка не позволяет другим пользователям получить рабочую копию или
препятствует изменению рабочей копии файла (например, средствами файловой
системы) и обеспечивает, таким образом, исключительный доступ только тому
пользователю, который работает с документом.
Многие
возможностей:




системы
управления
версиями
предоставляют
ряд
других
Позволяют создавать разные варианты одного документа, т. н. ветки, с
общей историей изменений до точки ветвления и с разными — после неё.
Дают возможность узнать, кто и когда добавил или изменил конкретный
набор строк в файле.
Ведут журнал изменений, в который пользователи могут записывать
пояснения о том, что и почему они изменили в данной версии.
Контролируют права доступа пользователей, разрешая или запрещая
чтение или изменение данных, в зависимости от того, кто запрашивает
это действие.
3.4.1. Типичный порядок работы с системой
Каждая система управления версиями имеет свои специфические особенности в
наборе команд, порядке работы пользователей и администрировании. Тем не менее,
общий порядок работы для большинства VCS совершенно стереотипен. Здесь
предполагается, что проект, каким бы он ни был, уже существует и на сервере
размещён его репозиторий, к которому разработчик получает доступ.
Начало работы с проектом
Первым действием, которое должен выполнить разработчик, является
извлечение рабочей копии проекта или той его части, с которой предстоит работать.
Это действие выполняется с помощью стандартной команды извлечения версии
(checkout или clone) либо специальной команды, фактически выполняющей то же самое
действие. Разработчик задаёт версию, которая должна быть скопирована, по
умолчанию обычно копируется последняя (или выбранная администратором в качестве
основной) версия.
По команде извлечения устанавливается соединение с сервером и проект (или
его часть — один из каталогов с подкаталогами) в виде дерева каталогов и файлов
копируется на компьютер разработчика. Обычной практикой является дублирование
рабочей копии: помимо основного каталога с проектом на локальный диск (либо в
отдельный, специально выбранный каталог, либо в системные подкаталоги основного
дерева проекта) дополнительно записывается ещё одна его копия. Работая с проектом,
разработчик изменяет только файлы основной рабочей копии. Вторая локальная копия
хранится в качестве эталона, позволяя в любой момент без обращения к серверу
определить, какие изменения внесены в конкретный файл или проект в целом и от
какой версии была «отпочкована» рабочая копия; как правило, любая попытка ручного
изменения этой копии приводит к ошибкам в работе программного обеспечения VCS.
21
Ежедневный цикл работы
При некоторых вариациях, определяемых особенностями системы и деталями
принятого бизнес-процесса, обычный цикл работы разработчика в течение рабочего
дня выглядит следующим образом.
Обновление рабочей копии
По мере внесения изменений в проект рабочая копия на компьютере
разработчика стареет, расхождение её с основной версией проекта увеличивается. Это
повышает риск возникновения конфликтных изменений (см. ниже). Поэтому удобно
поддерживать рабочую копию в состоянии, максимально близком к текущей основной
версией, для чего разработчик выполняет операцию обновления рабочей копии (update)
насколько возможно часто (реальная частота обновлений определяется частотой
внесения изменений, зависящей от активности разработки и числа разработчиков, а
также временем, затрачиваемым на каждое обновление — если оно велико,
разработчик вынужден ограничивать частоту обновлений, чтобы не терять время).
Модификация проекта
Разработчик модифицирует проект, изменяя входящие в него файлы в рабочей
копии в соответствии с проектным заданием. Эта работа производится локально и не
требует обращений к серверу VCS.
Фиксация изменений
Завершив очередной этап работы над заданием, разработчик фиксирует (commit)
свои изменения, передавая их на сервер (либо в основную ветвь, если работа над
заданием полностью завершена, либо в отдельную ветвь разработки данного задания).
VCS может требовать от разработчика перед фиксацией обязательно выполнить
обновление рабочей копии. При наличии в системе поддержки отложенных изменений
(shelving) изменения могут быть переданы на сервер без фиксации. Если утверждённая
политика работы в VCS это позволяет, то фиксация изменений может проводиться не
ежедневно, а только по завершении работы над заданием; в этом случае до завершения
работы все связанные с заданием изменения сохраняются только в локальной рабочей
копии разработчика.
Ветвления
Делать мелкие исправления в проекте можно путём непосредственной правки
рабочей копии и последующей фиксацией изменений прямо в главной ветви (стволе) на
сервере. Однако при выполнении сколько-нибудь значительных по объёму работ такой
порядок становится неудобным: отсутствие фиксации промежуточных изменений на
сервере не позволяет работать над чем-либо в групповом режиме, кроме того,
повышается риск потери изменений при локальных авариях и теряется возможность
анализа и возврата к предыдущим вариантам кода в пределах данной работы. Поэтому
для таких изменений обычной практикой является создание ветвей (branch), то есть
«отпочковывания» от ствола в какой-то версии нового варианта проекта или его части,
разработка в котором ведётся параллельно с изменениями в основной версии. Ветвь
создаётся специальной командой. Рабочая копия ветви может быть создана заново
обычным образом (командой извлечения рабочей копии, с указанием адреса или
идентификатора ветви), либо путём переключения имеющейся рабочей копии на
заданную ветвь.
Базовый рабочий цикл при использовании ветвей остаётся точно таким же, как и
в общем случае: разработчик периодически обновляет рабочую копию (если с ветвью
22
работает более одного человека) и фиксирует в ней свою ежедневную работу. Иногда
ветвь разработки так и остаётся самостоятельной (когда изменения порождают новый
вариант проекта, который далее развивается отдельно от основного), но чаще всего,
когда работа, для которой создана ветвь, выполнена, ветвь реинтегрируется в ствол
(основную ветвь). Это может делаться командой слияния (обычно merge), либо путём
создания патча (patch), содержащего внесённые в ходе разработки ветви изменения и
применения этого патча к текущей основной версии проекта.
Слияние версий
Три вида операций, выполняемых в системе управления версиями, могут
приводить к необходимости объединения изменений. Это:



Обновление рабочей копии (изменения, сделанные в основной версии,
сливаются с локальными).
Фиксация изменений (локальные изменения сливаются с изменениями,
уже зафиксированными в основной версии).
Слияние ветвей (изменения, сделанные в одной ветви разработки,
сливаются с изменениями, сделанными в другой).
Во всех случаях ситуация принципиально одинакова и имеет следующие
характерные черты:



Ранее была сделана копия дерева файлов и каталогов репозитория или его
части.
Впоследствии и в оригинальное дерево и в копию были независимо
внесены некоторые изменения.
Требуется объединить изменения в оригинале и копии таким образом,
чтобы не нарушить логическую связность проекта и не потерять данные.
Совершенно очевидно, что при невыполнении условия (2) (то есть если
изменения были внесены только в оригинал или только в копию) объединение
элементарно — достаточно скопировать изменённую часть туда, где изменений не
было. В противном случае слияние изменений превращается в нетривиальную задачу,
во многих случаях требующую вмешательства разработчика.
Конфликты и их разрешение
Ситуация, когда при слиянии нескольких версий сделанные в них изменения
пересекаются между собой, называют конфликтом. При конфликте изменений система
управления версиями не может автоматически создать объединённый проект и
вынуждена обращаться к разработчику. Как уже говорилось выше, конфликты могут
возникать на этапах фиксации изменений, обновления или слияния ветвей. Во всех
случаях при обнаружении конфликта соответствующая операция прекращается до его
разрешения. Некоторые системы (например, Subversion) даже не пытаются разрешать
конфликты на этапе фиксации или слияния ветви со стволом; при возникновении таких
конфликтов операция полностью отменяется и разработчику предлагается сначала
выполнить обновление рабочей копии (очевидно, что при этом возникнут те же самые
конфликты), разрешить конфликты и только после этого выполнять объединение своих
изменений с базовой ветвью.
Для разрешения конфликта система, в общем случае, предлагает разработчику
три варианта конфликтующих файлов: базовый, локальный и серверный.
Конфликтующие изменения либо показываются разработчику в специальном
программном модуле объединения изменений (в этом случае там демонстрируются
23
сливаемые варианты и динамически изменяющийся в зависимости от команд
пользователя объединённый вариант файла), либо просто помечаются специальной
разметкой прямо в тексте объединённого файла (тогда разработчик должен сам
сформировать желаемый текст в спорных местах и сохранить его).
Конфликты в файловой системе разрешаются проще: там может конфликтовать
только удаление файла с одной из прочих операций, а порядок файлов в каталоге не
имеет значения, так что разработчику остаётся лишь выбрать, какую операцию нужно
сохранить в сливаемой версии.
Версии проекта, тэги
Система управления версиями обеспечивает хранение всех существовавших
вариантов файлов и, как следствие, всех вариантов проекта в целом, имевших место с
момента начала его разработки. Но само понятие «версии» в разных системах может
трактоваться двумя различными способами.
Одни системы поддерживают версионность файлов. Это означает, что любой
файл, появляющийся в проекте, получает собственный номер версии (обычно — номер
1, условной «нулевой» версией файла считается пустой файл с тем же именем). При
каждой фиксации разработчиком изменений, затрагивающих файл, соответствующая
часть фиксируемых изменений применяется к файлу и файл получает новый, обычно
следующий по порядку, номер версии. Поскольку фиксации обычно затрагивают
только часть файлов в репозитории, номера версий файлов, имеющиеся на один и тот
же момент времени, со временем расходятся, и проект в целом (то есть весь набор
файлов репозитория), фактически, никакого «номера версии» не имеет, поскольку
состоит из множества файлов с различными номерами версий. Подобным образом
работает, например, система управления версиями CVS.
Для других систем понятие «версия» относится не к отдельному файлу, а к
репозиторию целиком. Вновь созданный пустой репозиторий имеет версию 1 или 0,
любая фиксация изменений приводит к увеличению этого номера (то есть даже при
изменении одного файла на один байт весь репозиторий считается изменённым и
получает новый номер версии). Таким способом трактует номера версий, например,
система Subversion. Номера версии отдельного файла здесь, фактически, не существует,
условно можно считать таковым текущий номер версии репозитория (то есть считать,
что при каждом изменении, внесённом в репозиторий, все его файлы меняют номер
версии, даже те, которые не менялись). Иногда, говоря о «версии файла» в таких
системах, имеют в виду ту версию репозитория, в которой файл был последний раз (до
интересующего нас момента) изменён.
Для практических целей обычно имеет значение не отдельный файл, а весь
проект целиком. В системах, поддерживающих версионность отдельных файлов, для
идентификации определённой версии проекта можно использовать дату и время —
тогда версия проекта будет состоять из тех версий входящих в него файлов, которые
имелись в репозитории на указанный момент времени. Если поддерживается
версионность репозитория в целом, номером версии проекта может выступать номер
версии репозитория. Однако оба варианта не слишком удобны, так как ни дата, ни
номер версии репозитория обычно не несут информации о значимых изменениях в
проекте, о том, насколько долго и интенсивно над ним работали. Для более удобной
пометки версий проекта (или его частей) системы управления версиями поддерживают
понятие тэгов.
24
Тэг (tag) — это символическая метка, которая может быть связана с
определённой версией файла и/или каталога в репозитории. С помощью
соответствующей команды всем или части файлов проекта, отвечающим определённым
условиям (например, входящим в головную версию главной ветви проекта на
определённый момент времени) может быть присвоена заданная метка. Таким образом
можно идентифицировать версию проекта (версия «XX.XXX.XXX» — это набор
версий файлов репозитория, имеющих тэг «XX.XXX.XXX»), зафиксировав таким
образом его состояние на некоторый желаемый момент. Как правило, система тэгов
достаточно гибкая и позволяет пометить одним тэгом и не одновременные версии
файлов и каталогов. Это позволяет собрать «версию проекта» любым произвольным
образом. С точки зрения пользователя системы пометка тэгами может выглядеть поразному. В некоторых системах она изображается именно как пометка (тэг можно
создать, применить к определённым версиям файлов и каталогов, снять). В других
системах (например, Subversion) тэг представляет собой просто отдельный каталог на
файловом дереве репозитория, куда из ствола и ветвей проекта с помощью команды
копирования делаются копии нужных версий файлов. Так что визуально тэг — это
просто вынесенная в отдельный каталог копия определённых версий файлов
репозитория. По соглашению в дерево каталогов, соответствующее тэгу, запрещена
фиксация изменений (то есть версия проекта, представляемая тэгом, является
неизменной).
Базовые принципы разработки ПО в VCS
Порядок использования системы управления версиями в каждом конкретном
случае определяется техническими регламентами и правилами, принятыми в
конкретной фирме или организации, разрабатывающей проект. Тем не менее, общие
принципы правильного использования VCS немногочисленны и едины для любых
разработок и систем управления версиями.




Любые рабочие, тестовые или демонстрационные версии проекта
собираются только из репозитория системы. «Персональные» сборки,
включающие ещё не зафиксированные изменения, могут делать только
разработчики для целей промежуточного тестирования. Таким образом,
гарантируется, что репозиторий содержит всё необходимое для создания
рабочей версии проекта.
Текущая версия главной ветви всегда корректна. Не допускается
фиксация в главной ветви неполных или не прошедших хотя бы
предварительное тестирования изменений. В любой момент сборка
проекта, проведённая из текущей версии, должна быть успешной.
Любое значимое изменение должно оформляться как отдельная ветвь.
Промежуточные результаты работы разработчика фиксируются в эту
ветвь. После завершения работы над изменением ветвь объединяется со
стволом. Исключения допускаются только для мелких изменений, работа
над которыми ведётся одним разработчиком в течение не более чем
одного рабочего дня.
Версии проекта помечаются тэгами. Выделенная и помеченная тэгом
версия более никогда не изменяется.
Распределённые системы управления версиями
Также известны как англ. Distributed Version Control System, DVCS. Такие
системы используют распределённую модель вместо традиционной клиент-серверной.
Они, в общем случае, не нуждаются в централизованном хранилище: вся история
25
изменения документов хранится на каждом компьютере, в локальном хранилище, и при
необходимости
отдельные
фрагменты
истории
локального
хранилища
синхронизируются с аналогичным хранилищем на другом компьютере. В некоторых
таких системах локальное хранилище располагается непосредственно в каталогах
рабочей копии.
Когда пользователь такой системы выполняет обычные действия, такие как
извлечение определённой версии документа, создание новой версии и тому подобное,
он работает со своей локальной копией хранилища. По мере внесения изменений,
хранилища, принадлежащие разным разработчикам, начинают различаться, и возникает
необходимость в их синхронизации. Такая синхронизация может осуществляться с
помощью обмена патчами или так называемыми наборами изменений (англ. change
sets) между пользователями.
Описанная модель логически аналогична созданию отдельной ветки для
каждого разработчика в классической системе управления версиями (в некоторых
распределённых системах перед началом работы с локальным хранилищем нужно
создать новую ветвь). Отличие состоит в том, что до момента синхронизации другие
разработчики этой ветви не видят. Пока разработчик изменяет только свою ветвь, его
работа не влияет на других участников проекта и наоборот. По завершении
обособленной части работы, внесённые в ветви изменения сливают с основной (общей)
ветвью. Как при слиянии ветвей, так и при синхронизации разных хранилищ возможны
конфликты версий. На этот случай во всех системах предусмотрены те или иные
методы обнаружения и разрешения конфликтов слияния.
С точки зрения пользователя распределённая система отличается
необходимостью создавать локальный репозиторий и наличием в командном языке
двух дополнительных команд: команды получения репозитория от удалённого
компьютера (poll) и передачи своего репозитория на удалённый компьютер (push).
Первая команда выполняет слияние изменений удалённого и локального репозиториев
с помещением результата в локальный репозиторий; вторая — наоборот, выполняет
слияние изменений двух репозиториев с помещением результата в удалённый
репозиторий. Как правило, команды слияния в распределённых системах позволяют
выбрать, какие наборы изменений будут передаваться в другой репозиторий или
извлекаться из него, исправлять конфликты слияния непосредственно в ходе операции
или после её неудачного завершения, повторять или возобновлять неоконченное
слияние. Обычно передача своих изменений в чужой репозиторий (push) завершается
удачно только при условии отсутствия конфликтов. Если конфликты возникают,
пользователь должен сначала слить версии в своём репозитории (выполнить poll), и
лишь затем передавать их другим.
Обычно рекомендуется организовывать работу с системой так, чтобы
пользователи всегда или преимущественно выполняли слияние у себя в репозитории.
То есть, в отличие от централизованных систем, где пользователи передают свои
изменения на центральный сервер, когда считают нужным, в распределённых системах
более естественным является порядок, когда слияние версий инициирует тот, кому
нужно получить его результат (например, разработчик, управляющий сборочным
сервером).
Основные преимущества распределённых систем — их гибкость и значительно
бо́льшая (по сравнению с централизованными системами) автономия отдельного
рабочего места. Каждый компьютер разработчика является, фактически,
самостоятельным и полнофункциональным сервером, из таких компьютеров можно
26
построить произвольную по структуре и уровню сложности систему, задав (как
техническими, так и административными мерами) желаемый порядок синхронизации.
При этом каждый разработчик может вести работу независимо, так, как ему удобно,
изменяя и сохраняя промежуточные версии документов, пользуясь всеми
возможностями системы (в том числе доступом к истории изменений) даже в
отсутствие сетевого соединения с сервером. Связь с сервером или другими
разработчиками требуется исключительно для проведения синхронизации, при этом
обмен наборами изменений может осуществляться по различным схемам.
К недостатком распределённых систем можно отнести увеличение требуемого
объёма дисковой памяти: на каждом компьютере приходится хранить полную историю
версий, тогда как в централизованной системе на компьютере разработчика обычно
хранится лишь рабочая копия, то есть срез репозитория на какой-то момент времени и
внесённые изменения. Менее очевидным, но неприятным недостатком является то, что
в распределённой системе практически невозможно реализовать некоторые виды
функциональности, предоставляемые централизованными системами. Это:



Блокировка файла или группы файлов (для хранения признака
блокировки нужен общедоступный и постоянно находящийся в онлайне
центральный сервер). Это вынуждает применять специальные
административные меры, если приходится работать с бинарными
файлами, непригодными для автоматического слияния.
Слежение за определённым файлом или группой файлов (изменения
файлов происходят на разных серверах, слияния и выделения ветвей
происходят локально, об изменениях становится известно только при
синхронизации, причём не всем разработчикам, а только тем, кто в
данной синхронизации участвует).
Единая сквозная нумерация версий системы и/или файлов, в которой
номер версии монотонно возрастает (такая нумерация также требует
наличия главного сервера, задающего номера версий для всех
остальных). В распределённых системах приходится обходиться
локальными обозначениями версий и применять тэги, назначение
которых определяется соглашением между разработчиками или
корпоративными стандартами фирмы.
Можно выделить следующие типичные ситуации, в которых использование
распределённой системы даёт заметные преимущества:



Периодическая
синхронизации
нескольких
компьютеров
под
управлением одного разработчика (рабочего компьютера, домашнего
компьютера, ноутбука и так далее). Использование распределённой
системы избавляет от необходимости выделять один из компьютеров в
качестве сервера, а синхронизация выполняется по необходимости,
обычно при «пересадке» разработчика с одного устройства на другое.
Совместная работа над проектом небольшой территориально
распределённой группы разработчиков без выделения общих ресурсов.
Как и в предыдущем случае, реализуется схема работы без главного
сервера, а актуальность репозиториев поддерживается периодическими
синхронизациями по схеме «каждый с каждым».
Крупный распределённый проект, участники которого могут долгое
время работать каждый над своей частью, при этом не имеют
постоянного подключения к сети. Такой проект может использовать
27
централизованный сервер, с которым синхронизируются копии всех его
участников. Возможны и более сложные варианты — например, с
созданием групп для работы по отдельным направлениям внутри более
крупного проекта. При этом могут быть выделены отдельные
«групповые» серверы для синхронизации работы групп, тогда процесс
окончательного слияния изменения становится древовидным: сначала
отдельные разработчики синхронизируют изменения на групповых
серверах, затем обновлённые репозитории групп синхронизируются с
главным сервером. Возможна работа и без «групповых» серверов, тогда
разработчики одной группы синхронизируют изменения между собой,
после чего любой из них (например, руководитель группы) передаёт
изменения на центральный сервер.
В традиционной «офисной» разработке проектов, когда группа разработчиков
относительно невелика и целиком находится на одной территории, в пределах единой
локальной компьютерной сети, с постоянно доступными серверами, централизованная
система может оказаться лучшим выбором из-за своей более жёсткой структуры и
наличия функциональности, отсутствующей в распределённых системах (например,
уже упомянутой блокировки). Возможность фиксировать изменения без их слияния в
центральную ветвь в таких условиях легко реализуется путём выделения
незавершённых работ в отдельные ветви разработки.
3.4.2. Subversion
Subversion (также известная как «SVN») — свободная централизованная система
управления версиями, официально выпущенная в 2004 году компанией CollabNet Inc.
Цель проекта — заменить собой распространенную на тот момент систему
Concurrent Versions System (CVS), которая ныне считается устаревшей. Subversion
реализует все основные функции CVS и свободна от ряда недостатков последней.
В настоящее время Subversion используется многими сообществами
разработчиков открытого программного обеспечения (в том числе сообществами, ранее
использовавшими CVS). В их числе такие известные проекты, как Apache, GCC, Free
Pascal, Python, Ruby, Mono, FreeBSD, Haiku, AROS и MediaWiki. Subversion также
широко используется в закрытых проектах и корпоративной сфере. Хостинг Subversion,
в том числе для проектов с открытым кодом, также предоставляют популярные
хостинг-проекты SourceForge.net, Tigris.org, Google Code и BountySource.
В 2007 году независимая компания Forrester Research, сравнивая преимущества
и недостатки различных систем, оценила Subversion как «единоличного лидера в
категории Standalone Software Configuration Management (SCM) и сильного участника в
категории Software Configuration and Change Management (SCCM)».
По данным статистики использования пакетов Linux-дистрибутивов Debian и
Ubuntu, количество активных пользователей Subversion примерно такое же, как у Git, и
превосходит аналогичный показатель для CVS, Mercurial и Bazaar (по состоянию на
июнь 2011 года).
В качестве официальной документации позиционируется книга издательства
O'Reilly Media, выложенная в свободный доступ на сайте http://svnbook.red-bean.com/ и
дописываемая авторами по мере выхода новых версий SVN. Там же публикуются её
переводы на ряд языков, в том числе русский, но при том, что англоязычные версии
книги сейчас описывают версии 1.6 и 1.5, на русском языке имеются лишь книги,
описывающие версии до 1.4 включительно.
28
3.4.3. Mercurial
Mercurial — (англ. Ртутный) кроссплатформенная распределённая система
управления версиями, разработанная для эффективной работы с очень большими
репозиториями кода. Mercurial первоначально был написан для Linux, позже
портирован под Windows, Mac OS X и большинство Unix-систем. В первую очередь он
является консольной программой. Все его операции запускаются параметрами
программы hg, название которой взято от обозначения химического знака ртути (англ.
mercury).
Система Mercurial написана на Python, хотя чувствительные к
производительности части (например, своя реализация diff) выполнены в качестве
Python-расширений на C. Репозитории Mercurial управляются при помощи утилиты
командной строки hg.
Наряду с традиционными возможностями систем контроля версий, Mercurial
поддерживает полностью децентрализованную работу (отсутствует понятие основного
хранилища кода), ветвление (возможно вести несколько веток одного проекта и
копировать изменения между ветками), слияние репозиториев (чем и достигается
«распределённость» работы). Поддерживается обмен данными между репозиториями
через HTTP/HTTPS, SSH[1] и вручную при помощи упакованных наборов изменений.
Mercurial использует SHA1-хеши для идентификации ревизий и позволяет
присваивать отдельным ревизиям индивидуальные метки.
Утилита hg обладает компактным интерфейсом, и Mercurial считается более
простой в освоении системой, чем, например, git.
3.4.4. Git
Git (произн. «гит»[1]) — распределённая система управления версиями файлов.
Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux,
первая версия выпущена 7 апреля 2005 года. На сегодняшний день поддерживается
Джунио Хамано (англ. Junio C. Hamano).
Примерами проектов, использующих Git, являются ядро Linux, Drupal, Cairo,
GNU Core Utilities, Mesa, Wine, Chromium, Compiz Fusion, FlightGear, jQuery и
некоторые дистрибутивы Linux (см. ниже).
Программа является свободной и выпущена под лицензией GNU GPL версии 2.
Система спроектирована как набор программ, специально разработанных с
учётом их использования в скриптах. Это позволяет удобно создавать
специализированные системы контроля версий на базе Git или пользовательские
интерфейсы. Например, Cogito является именно таким примером фронтенда к
репозиториям Git, а StGit использует Git для управления коллекцией патчей.
Git поддерживает быстрое разделение и слияние версий, включает инструменты
для визуализации и навигации по нелинейной истории разработки. Как и Darcs,
BitKeeper, Mercurial, Bazaar и Monotone, Git предоставляет каждому разработчику
локальную копию всей истории разработки, изменения копируются из одного
репозитория в другой.
Удалённый доступ к репозиториям Git обеспечивается git-daemon, SSH- или
HTTP-сервером. TCP-сервис git-daemon входит в дистрибутив Git и является наряду с
SSH наиболее распространённым и надёжным методом доступа. Метод доступа по
29
HTTP, несмотря на ряд ограничений, очень популярен в контролируемых сетях, потому
что позволяет использовать существующие конфигурации сетевых фильтров.
3.5. Инструменты сборки и выпуска
3.5.1. Автоматизация сборки
Автоматизация сборки — этап написания скриптов или автоматизация широкого
спектра задач применительно к ПО, применяемому разработчиками в их повседневной
деятельности, включая такие действия, как:





Компиляция исходного кода в бинарный код
сборка бинарного кода
выполнение тестов
разворачивание программы на производственной платформе
написание сопроводительной документации или описание изменений
новой версии
История
Исторически так сложилось, что разработчики применяли автоматизацию
сборки для вызова компиляторов и линковщиков из скрипта сборки, в отличие от
вызова компилятора из командной строки. Довольно просто при помощи командной
строки передать один исходный модуль компилятору, а затем и линковщику для
создания конечного объекта. Однако, при попытке скомпилировать или слинковать
множество модулей с исходным кодом, причем в определенном порядке,
осуществление этого процесса вручную при помощи командной строки выглядит
слишком неудобным. Гораздо более привлекательной альтернативой является
скриптовый язык, поддерживаемый утилитой Make. Данный инструмент позволяет
писать скрипты сборки, определяя порядок их вызова, этапы компиляции и линковки
для сборки программы. GNU Make [1] также предоставляет такие дополнительные
возможности, как например, «зависимости» («makedepend»), которые позволяют
указать условия подключения исходного кода на каждом этапе сборки. Это и стало
началом автоматизации сборки. Основной целью была автоматизация вызовов
компиляторов и линковщиков. По мере роста и усложнения процесса сборки
разработчики начали добавлять действия до и после вызовов компиляторов, как
например, проверку (check-out) версий копируемых объектов на тестовую систему.
Термин «автоматизация сборки» уже включает в себя управление и действиями до и
после компиляции и линковки, так же как и действия при компиляции и линковке.
Новое поколение инструментов
В последние годы решения по управлению сборкой сделали еще более удобным
и
управляемым
процесс
автоматизированной
сборки.
Для
выполнения
автоматизированной сборки и контроля этого процесса существуют как коммерческие,
так и открытые решения. Некоторые решения нацелены на автоматизацию шагов до и
после вызова сборочных скриптов, а другие выходят за рамки действий до и после
обработки скриптов и полностью автоматизируют процесс компиляции и линковки,
избавляя от ручного написания скриптов. Такие инструменты чрезвычайно полезны для
непрерывной интеграции, когда требуются частые вызовы компиляции и обработка
промежуточных сборок.
30
Преимущества







Улучшение качества продукта
Ускорение процесса компиляции и линковки
Избавление от излишних действий
Минимизация «плохих (некорректных) сборок»
Избавление от привязки к конкретному человеку
Ведение истории сборок и релизов для разбора выпусков
Экономия времени и денег благодаря причинам, указанным выше.
Требования к системам сборки
Базовые требования:
1. Частые или ночные сборки для своевременного выявления проблем.
2. Поддержка управления зависимостями исходного кода (Source Code
Dependency Management)
3. Обработка разностной сборки
4. Уведомление при совпадении исходного кода (после сборки) с
имеющимися бинарными файлами.
5. Ускорение сборки
6. Отчет о результатах компиляции и линковки.
Дополнительные требования:
1. Создание описания изменений (release notes) и другой сопутствующей
документации (например, руководства).
2. Отчет о статусе сборки
3. Отчет об успешном/неуспешном прохождении тестов.
4. Суммирование добавленных/измененных/удаленных особенностей в
каждой новой сборке
3.5.2. Apache Ant
Apache Ant (англ. ant — муравей и акроним — «Another Neat Tool») — утилита
для
автоматизации процесса
сборки
программного продукта. Является
платформонезависимым аналогом UNIX-утилиты make (в качестве «Makefile»
применяется «build.xml»).
Ant был создан в рамках проекта Jakarta, сегодня — самостоятельный проект
первого уровня Apache Software Foundation.
Первая версия была разработана инженером Sun Microsystems Джеймсом
Дэвидсоном (James Davidson), который нуждался в утилите, подобной make,
разрабатывая первую референтную реализацию J2EE.
В отличие от make, утилита Ant полностью независима от платформы, требуется
лишь наличие на применяемой системе установленной рабочей среды Java — JRE.
Отказ от использования команд операционной системы и формат XML обеспечивают
переносимость сценариев.
Управление процессом сборки происходит посредством XML-сценария, также
называемого Build-файлом. В первую очередь этот файл содержит определение
проекта, состоящего из отдельных целей (Targets). Цели сравнимы с процедурами в
языках программирования и содержат вызовы команд-заданий (Tasks). Каждое задание
представляет собой неделимую, атомарную команду, выполняющую некоторое
элементарное действие.
31
Между целями могут быть определены зависимости — каждая цель
выполняется только после того, как выполнены все цели, от которых она зависит (если
они уже были выполнены ранее, повторного выполнения не производится).
Типичными примерами целей являются clean (удаление промежуточных
файлов), compile (компиляция всех классов), deploy (развёртывание приложения на
сервере). Конкретный набор целей и их взаимосвязи зависят от специфики проекта.
Ant позволяет определять собственные типы заданий путём создания Javaклассов, реализующих определённые интерфейсы.
3.5.3. Apache Maven
Apache Maven — фреймворк для автоматизации сборки
специфицированных на XML-языке POM (англ. Project Object Model).
проектов,
Maven, в отличие от другого сборщика проектов Apache Ant, обеспечивает
декларативную, а не императивную сборку проекта. То есть, в файлах проекта pom.xml
содержится его декларативное описание, а не отдельные команды. Все задачи по
обработке файлов Maven выполняет через плагины.
3.6. Непрерывная интеграция
Непрерывная интеграция (англ. Continuous Integration) — это практика
разработки программного обеспечения, которая заключается в выполнении частых
автоматизированных сборок проекта для скорейшего выявления и решения
интеграционных проблем. В обычном проекте, где над разными частями системы
разработчики трудятся независимо, стадия интеграции является заключительной. Она
может непредсказуемо задержать окончание работ. Переход к непрерывной интеграции
позволяет снизить трудоёмкость интеграции и сделать её более предсказуемой за счет
наиболее раннего обнаружения и устранения ошибок и противоречий.
Требования к проекту
Исходные коды и все, что необходимо для сборки и тестирования проекта,
хранится в репозитории системы управления версиями;
операции копирования из репозитория, сборки и тестирования всего проекта
автоматизированы и легко вызываются из внешней программы.
Организация
На выделенном сервере организуется служба, в задачи которой входят:





получение исходного кода из репозитория;
сборка проекта;
выполнение тестов;
развёртывание готового проекта;
отправка отчетов.
Локальная сборка может осуществляться:



по внешнему запросу,
по расписанию,
по факту обновления репозитория и по другим критериям.
32
Сборка по расписанию
В случае сборки по расписанию (англ. daily build — рус. ежедневная сборка),
они, как правило, проводятся каждой ночью в автоматическом режиме — ночные
сборки (чтобы к началу рабочего дня были готовы результаты тестирования). Для
различения дополнительно вводится система нумерации сборок — обычно, каждая
сборка нумеруется натуральным числом, которое увеличивается с каждой новой
сборкой. Исходные тексты и другие исходные данные при взятии их из репозитория
системы контроля версий помечаются номером сборки. Благодаря этому, точно такая
же сборка может быть точно воспроизведена в будущем — достаточно взять исходные
данные по нужной метке и запустить процесс снова. Это даёт возможность повторно
выпускать даже очень старые версии программы с небольшими исправлениями.
Преимущества




проблемы интеграции выявляются и исправляются быстро, что
оказывается дешевле;
немедленный прогон модульных тестов для свежих изменений;
постоянное наличие текущей стабильной версии вместе с продуктами
сборок — для тестирования, демонстрации, и т. п.
немедленный эффект от неполного или неработающего кода приучает
разработчиков к работе в итеративном режиме с более коротким циклом.
Недостатки




затраты на поддержку работы непрерывной интеграции;
потенциальная необходимость в выделенном сервере под нужды
непрерывной интеграции;
немедленный эффект от неполного или неработающего кода отучает
разработчиков от выполнения периодических резервных включений кода
в репозиторий.
в случае использования системы управления версиями исходного кода с
поддержкой ветвления, эта проблема может решаться созданием
отдельной "ветки" (англ. branch) проекта для внесения крупных
изменений (код, разработка которого до работоспособного варианта
займет несколько дней, но желательно более частое резервное
копирование в репозиторий). По окончании разработки и
индивидуального тестирования такой ветки, она может быть объединена
(англ. merge) с основным кодом или "стволом" (англ. trunk) проекта.
3.6.1. Hudson/Jenkins
Hudson (рус. Ха́дсон, или Гудзо́н) — инструмент непрерывной интеграции,
написанный на Java. Запускается в контейнере сервлетов, таких как Apache Tomcat или
GlassFish. Поддерживает инструментарий для работы с разными системами контроля
версий, включая CVS, Subversion, Mercurial, Git и Clearcase, может собирать проекты
Apache Ant и Apache Maven, а также исполнять shell-скрипты и команды Windows.
Основной разработчик Hudson — Косукэ Кавагути — ранее работал в Sun
Microsystems и в 2010 году, после поглощения Sun компанией Oracle, основал
компанию InfraDNA, нацеленную на коммерческую поддержку инструмента. В феврале
2011 года Кавагути ответвил проект, дав ему наименование Jenkins, в ответ на отказ
корпорации Oracle передать права на торговую марку Hudson. В мае 2011 года Oracle
33
отказалась от контроля над проектом и наименованием, предложив целиком передать
разработку инструмента под управление Eclipse Foundation.
Сборка проектов может быть назначена на разные события, например,
производиться по расписанию, используя механизм подобный cron, либо стартовать
когда другая сборка уже собрана, либо при запросе определённого URL.
Последние годы Hudson стал популярной альтернативой CruiseControl и другим
программам для сборки с открытым исходным кодом. На состоявшейся в мае 2008 года
конференции JavaOne приложение стало лауреатом Duke’s Choice Award в категории
«Решения для разработчиков». Компания Sun Microsystems объявила о коммерческой
поддержке инструмента в августе 2009 года.
По состоянию на конец 2010 года Hudson выпускался под лицензией MIT.
Благодаря богатству плагинов для «Хадсона» его функциональность как
инструмента для сборки проектов можно существенно расширить. Примером может
быть Serenity, которая представляет собой написанную на Java библиотеку для
составления метрик покрытия кода, его сложности, зависимостей в нём, соединённую с
плагином «Хадсон» для отображения отчётов.
3.6.2. Репозитории
Для хранения большого количества библиотек в организации
использоваться хранилище артефактов. Наиболее известные из них:



может
Apache Archiva
Artifactory
Nexus
Все эти системы тесно интегрируются с системами автоматической сборки и
системами непрерывной интеграции.
34
ЗАКЛЮЧЕНИЕ
Командная разработка программного обеспечения сложный процесс.
Необходимо знать не только средства, которыми должны пользоваться
разработчики/аналитики, но и уметь управлять командой.
С одной стороны – увеличиваются затраты на поддержание инфраструктуры и,
возможно, обучение сотрудников использованию средств. Но с другой – хорошо
налаженная работа в команде несет несомненную выгоду организации:


увеличивается скорость разработки, что снижает затраты на труд
продукт получается качественнее, что снижает затраты на поддержку
35
ЛИТЕРАТУРА
1. Aiello, R. (2010). Configuration Management Best Practices: Practical
Methods that Work in the Real World (1st ed.). Addison-Wesley. ISBN 0-32168586-5.
2. Сергей Орлик. Программная инженерия. Конфигурационное управление
(рус.). — Перевод главы из SWEBOK с комментариями. Проверено 18
июня 2011.
3. Дмитрий Лапыгин, Александр Новичков. Конфигурационное управление
проектами разработки программного обеспечения
(рус.) (2004).
Проверено 18 июня 2011.
4. Александр Новичков, Дмитрий Лапыгин. конфигурациями или кессонная
болезнь проектов Зачем нам нужен план управления конфигурациями?
Основные понятия и концепции документа (рус.) (27 января 2008).
Проверено 18 июня 2011.
5. Юрий Удовиченко. Управление конфигурациями или кессонная болезнь
проектов (рус.) (13 февраля 2011). Проверено 18 июня 2011.
6. Записки отставного сиэмщика: блог, статьи и книги по Software
Configuration Management (рус.) (20 октября 2011). Проверено 20 октября
2011.
7. Поль М. Дюваль, Стивен М. Матиас III, Эндрю Гловер Непрерывная
интеграция: улучшение качества программного обеспечения и снижение
риска = Continuous Integration: Improving Software Quality and Reducing
Risk (The Addison-Wesley Signature Series) — Вильямс, 2008. — 2000 экз.
— ISBN 978-5-8459-1408-8, 0-321-33638-0.
8. Википедия – свободная энциклопедия http://wikipedia.org
9. Software Engineering Coordinating Committee, IEEE Computer Society –
SWEBOK (Software Engineering Body of Knowledge)
36