Анна Сергеева. Контроль изменений кода при разработке встраиваемых программных приложений // Компоненты и технологии. 2015. № 9 (с. 82-89), № 10 (с. 102-106).
В статье приводится терминология и принципы управления версиями на примере системы Subversion. Также рассматриваются преимущества и удобство работы с системой контроля версий через графический интерфейс, интегрированный непосредственно в среду разработки программ, на примере взаимодействия системы Subversion с профессиональной средой разработки встраиваемых приложений Atollic TrueSTUDIO.
Опубликовано в разделе "Встраиваемые системы"
Эта же статья на сайте журнала и продолжение.
Разработка современных программных приложений связана с постоянными изменениями их исходного кода. Часто в этом задействованы целые команды разработчиков. Для отслеживания и упорядочивания всех изменений в коде разрабатываемых программ настоятельно рекомендуется применять специальные методологии и инструменты контроля изменений. Это позволяет предотвратить неизбежную путаницу в работе над проектом, сократить время разработки и, в конечном итоге, привести к повышению качества программного обеспечения.
В статье приводится терминология и принципы управления версиями на примере системы Subversion. Также рассматриваются преимущества и удобство работы с системой контроля версий через графический интерфейс, интегрированный непосредственно в среду разработки программ, на примере взаимодействия системы Subversion с профессиональной средой разработки встраиваемых приложений Atollic TrueSTUDIO.
Введение
Еще совсем недавно существовала практика, когда большинство встраиваемых приложений насчитывали всего несколько модулей исходного кода, созданных одним автором. Однако, современные проекты все чаще требуют поддержания порядка сотен модулей. Некоторые из них разрабатываются собственными усилиями участников проекта, другие покупаются у сторонних поставщиков, поступают от субподрядчиков или копируются из свободных источников с открытым исходным кодом.
Так что, в настоящее время разработка программных приложений перестает быть просто процессом написания и отладки кода. Теперь это довольно серьезная программная инженерия, которая предъявляет все больше требований к усовершенствованному проектированию, глубокой интеграции и тщательному тестированию. [1]
О необходимости управления изменениями в коде
По мере развития проекта, исходный код приложения претерпевает тысячи изменений. Рано или поздно разработчики вынуждены возвращаться к более старым версиям разрабатываемого и поддерживаемого ими кода с целью его обновления, исправления обнаруженных ошибок или же для внедрения новых функциональных возможностей.
Каждый, кто сталкивался с этим на практике, знает всю сложность процесса взаимодействия с унаследованным кодом. Часто сопроводительная и проектная документация, которая должна быть предоставлена в виде комментариев к коду, диаграмм и графиков, может иметь формальный характер, быть недостаточной, неактуальной или же вовсе отсутствовать. Таким образом, бывает довольно затруднительно получить ясную и подробную картину хода развития проекта и ориентироваться во всем многообразии внесенных изменений и дополнений в коде. Очень быстро теряется понимание того, кто выполнил те или иные изменения в коде, когда это произошло и для каких целей это было сделано.
Приведем такой распространенный пример. Нередко исправление существующих ошибок в коде способно приводить к непреднамеренному привнесению новых ошибок. Возникает необходимость в возврате к предыдущему, заведомо работоспособному, состоянию кода.
Без применения каких-либо методологий контроля версий, вся ценная информация о том, как ранее выглядел оригинальный код, до изменений, с течением времени может быть навсегда утрачена. Это делает невозможным быстрое восстановление работоспособности кода. В таких ситуациях, команды разработчиков теряют много лишнего времени на необоснованные, избыточные повторные действия, которых можно было бы избежать.
Существенную помощь даже в самых сложных и запутанных ситуациях способны оказывать механизмы управления историей изменений разрабатываемого и поддерживаемого кода. Они позволяют определять, кто внес те или иные изменения, когда они были выполнены и для каких целей. Эти весьма важные разъяснения просто необходимы для повышения эффективности обращения с существующим кодом и для внесения всех необходимых изменений своевременно.
На практике, применяются достаточно разноплановые подходы к управлению изменениями в коде разрабатываемых программных приложений. Начиная от обновления построчных комментариев в файлах с исходным кодом и отслеживания изменений в электронных таблицах и заканчивая применением целых специализированных программных приложений для отслеживания изменений в коде в процессе его разработки.
Такие приложения называются инструментами контроля версий кода и являются наиболее подходящими и эффективными средствами в решении подобных задач. И, хотя на обучение работе с этими инструментами требуется затратить определенное количество времени и усилий, это быстро окупится за счет преимуществ от применения этих инструментов. В следующих разделах данной статьи описывается работа с одной из распространенных в настоящее время систем контроля версий кода, Subversion.
О необходимости управления работой в команде
С другой стороны, использование управления версиями кода позволяет дисциплинировать всех членов команды разработчиков и наладить производственные взаимосвязи между ними, вне зависимости от личных черт характера и каких-либо персональных предпочтений.
Дополнительную сложность вносит и тот факт, что на сегодняшний день команды разработчиков часто многочисленны и рассредоточены по разным зданиям, городам, странам или даже континентам. Взаимодействие между ними может быть затруднено из-за разницы часовых поясов или деловых поездок, которые затрудняют выяснение таких простых, казалось бы, вопросов как: исправлена ли уже та или иная ошибка или выполнены ли уже запрошенные изменения в коде. Применение контроля версий упрощает получение такого рода информации даже тогда, когда коллеги по тем или иным причинам не доступны для личного общения.
В тех командах, которые применяют контроль версий, разработчики автоматически взаимодействуют друг с другом каждый раз, когда выполняют наиболее значимые для проекта операции, такие как помещение кода в репозиторий и извлечение из него, формирование и слияние ветвей кода, присвоение тегов и т. д.
Это помогает отдельным членам команд разработчиков ориентироваться в существующей структуре сложных проектов, а также дисциплинирует их в необходимости документирования всех новых вносимых изменений. Так что в любой момент времени можно получить достаточно полную информацию о ходе развития проекта.
Об управлении проектами для одиночных разработчиков
Для проектов, реализуемых силами одного единственного разработчика, контроль версий также имеет ряд преимуществ. В большинстве подобных проектов, один и тот же специалист может нести ответственность не только за разработку программного обеспечения, но и за проектирование аппаратуры, а также составление спецификаций и сопроводительной документации, заказ и закупку комплектующих и так далее.
Разумеется, проблема нехватки времени становится здесь катастрофической. Применение контроля версий помогает разработчикам оперативно возобновлять работу над текущим проектом после неизбежных перерывов. В долгосрочной перспективе, этот подход позволяет предотвращать, например, такие ситуации, когда исполнители забывают исправить важные ошибки и существенные дефекты или же выполняют реинжиниринг старого кода, хотя в этом не было необходимости. [2] [3]
Аргументы за и против
Большинство разработчиков уже применяет какие-либо системы контроля версий. Но есть и такие, которые этим не пользуются совсем. Вот какие аргументы они приводят.
Одни из них сомневаются, что время, затраченное на изучение работы с инструментами контроля версий, успешно окупится. Другие утверждают, что не менее эффективными являются и не столь строгие методы, такие как регулярное резервное копирование, и/или отслеживание изменений в электронных таблицах.
Одиночные разработчики часто утверждают, что поскольку они являются единственными авторами и модификаторами кода, то управление версиями им не нужно, потому что они способны держать всю подобную информацию в своей голове.
Так или иначе, все эти аргументы довольно сомнительны. Большинство организаций, профессионально занимающихся разработкой программных приложений, в числе официальных корпоративных требований к внутреннему распорядку настаивают на обязательном применении специальных инструментов контроля версий. [4]
Использование контроля версий также является хорошей практикой в разработке программного обеспечения и обычно является обязательным условием в разработке критичного программного обеспечения, в таких сферах как управление производственными процессами, авионика или медицинские устройства.
Еще одним фактором, который тормозит применение контроля версий, является тот факт, что внедрение специальных инструментов контроля версий требует приобретения, установки и поддержки отдельного приложения. Кроме того, необходимо еще и научиться им пользоваться. Безусловно, это так. Однако, усилия на внедрение разных инструментов значительно варьируются.
Существует достаточно широкий выбор клиентов для работы с системами контроля версий. Одни работают из командной строки, другие имеют графический интерфейс. Некоторые среды разработки имеют собственные интегрированные инструменты, но поддерживают очень ограниченный интерфейс взаимодействия с системами контроля версий. Другие разработаны сторонними производителями и недостаточно хорошо интегрированы в саму среду разработки. В некоторых случаях, подобные инструменты ограничивают доступ к полному перечню возможностей контроля версий, и их нельзя назвать идеальными. Вот почему так важно внимательно отнестись к выбору конкретного инструмента контроля версий.
От теории систем контроля версий к практике интеграции в профессиональные среды разработки встраиваемых приложений
В данной статье описаны преимущества от использования системы контроля версий Subversion в контексте разработки программного обеспечения для встраиваемых систем.
Также показано удобство и практическая эффективность интеграции графических клиентов в систему Subversion, на примере такого клиента, входящего в комплект поставки профессиональной среды для разработки встраиваемых приложений Atollic TrueSTUDIO. [5]
Такой клиент с удобным графическим интерфейсом пользователя, интегрированный непосредственно в среду разработки, способен существенно повышать производительность команды разработчиков, поскольку у инженеров пропадает необходимость покидать среду разработки, выполнять рутинные операции по контролю версий в каком-либо отдельном клиенте, а затем снова возвращаться в среду разработки для продолжения проектирования, программирования, отладки и других основных рабочих действий.
Статья состоит из двух взаимосвязанных частей:
- Организация контроля версий разрабатываемого программного обеспечения с использованием системы Subversion;
- Преимущества интегрирования со средой разработки программного обеспечения.
В первой части дается обзор преимуществ использования самих систем контроля версий в процессе разработки программных приложений. Здесь разработчики могут ознакомиться с новыми концепциями современных систем контроля версий, с принципами и механизмами их применения, а также с предназначением конкретных возможностей. В частности, приводится описание принципов работы с системой Subversion.
Освоение таких инструментов значительно упрощается, если начинать с понимания базовой модели, на которой строятся инструменты контроля версий, и соответствующих ей терминов. Изложенные основные понятия позволяют значительно сократить время обучения работе с такими системами как Subversion.
Во второй части внимание смещается на подробный обзор практических преимуществ от глубокого интегрирования графических клиентов системы Subversion непосредственно в среду программной разработки. Рассматривается интеграция с Atollic TrueSTUDIO, одной из наиболее популярных профессиональных сред разработки современных встраиваемых приложений с кодом на С/С++.
Организация контроля версий разрабатываемого ПО с использованием системы Subversion
Subversion — это одна из наиболее широко применяемых систем контроля версий в отрасли разработки программного обеспечения. В основном, популярность она получила, благодаря своей стабильности, доступности практически на всех платформах и богатому набору поддерживаемых функций.
К тому же, Subversion - это приложение с открытым исходным кодом, размещенным в открытом доступе [6].
Это является еще одним фактором ее широкого распространения и использования в отрасли разработки программного обеспечения. Благодаря большому количеству пользователей и поддержки масштабирования, Subversion постоянно становится все более стабильной и полезной системой. К тому же, она хорошо подходит для разработки критически важных программных проектов силами крупных распределенных команд разработчиков. [7]
Система Subversion была разработана с целью заменить систему CVS, которая ранее была одной из наиболее популярных систем контроля версий в области разработки программного обеспечения, но теперь заметно устарела и нуждается в замене на более современные аналоги.
Основные принципы работы Subversion
Subversion - это система контроля версий, которая управляет файлами и их изменениями с течением времени. Она отслеживает и предоставляет количественные показатели всех изменений во всех файлах, на протяжении всего жизненного цикла проекта.
Subversion отслеживает изменения не только в самих файлах, но также и в директориях. Кроме того, используемая методология контроля версий позволяет работать не только с текстовыми файлами в кодировке ASCII, такими как файлы заголовков и файлы исходного кода.
Поддерживается хранение с контролем версий для любых типов файлов, в том числе для бинарных, таких как изображения, аудио или даже офисные документы. Это особенно существенный момент, так как многие из перечисленных типов файлов имеют важное значение для поддержания структуры разрабатываемого приложения, а также используются для хранения сопроводительной документации и спецификаций.
Subversion позволяет извлекать старые версии файлов для их повторного использования, или изучать изменения между любыми двумя версиями одного и того же файла. Subversion отслеживает все изменения, внесенные в файл, так что можно наблюдать, как файл изменился с течением времени. Также можно увидеть, кто внес те или иные изменения, когда это произошло и почему. Если какое-либо конкретное изменение кода привело к проблеме в работе приложения, то достаточно просто вернуться к предыдущей стабильной версии, чтобы отменить изменения и продолжить работу. [8]
В сущности, системы контроля версий - это своего рода машины времени, которые позволяют перемещаться вперед и назад во времени, и видеть, как выглядели рабочие файлы и директории в определенное время в течение всего жизненного цикла проекта.
Клиент/серверная модель системы
При организации системы хранения версий лучше всего подходит использование сервера баз данных. Участники команды разработчиков будут получать доступ к нему через сетевое соединение, с использованием клиент/серверной модели.
Этот подход имеет ряд важных преимуществ. Во-первых, все нужные файлы проекта находятся в централизованном хранилище, доступном для всех разработчиков в команде. Во-вторых, в один и тот же момент времени сразу несколько разработчиков могут вносить изменения в один и тот же файл, и эти изменения могут быть впоследствии объединены.
В редких случаях, если в одной и той же строке обнаруживаются правки сразу нескольких разработчиков, то специальный менеджер конфликтов тут же обнаруживает эту ситуацию и предоставляет подходящие варианты для урегулирования конфликтующих изменений кода.
Все версии всех отслеживаемых файлов файлы хранятся в централизованном месте, называемом репозиторием. Доступ к этому репозиторию в системе Subversion осуществляется с клиентских компьютеров в любой точке сети. Здесь возможно использование как локального (LAN), так и глобального (WAN) подключения. Таким образом, разные разработчики, даже находящиеся в разных географических точках, имеют возможность работать с одними и теми же файлами исходного кода.
Следовательно, уже становится несущественным, находится команда разработчиков в одном месте или рассредоточена по различным городам, странам или континентам. Все разработчики могут иметь равный доступ к общему хранилищу, не зависимо от своего физического местоположения.
Базовые понятия систем контроля версий
Следующий раздел содержит обзор принципов работы с системой Subversion и охватывает такие важные понятия как репозиторий Subversion, локальные рабочие копии, проверка версий кода, передача кода в централизованное хранилище, и др.
Принципы организации репозиториев в системе Subversion
Система Subversion хранит все свои данные, то есть, все файлы и историю их изменений, в централизованном месте, называемом репозиторием. Как правило, такой репозиторий хранится на сетевом сервере, выделенном под нужды команды разработчиков программного обеспечения.
В соответствии с учетными настройками безопасности, к репозиторию на сервере может подключаться любое количество разработчиков и, с помощью клиента Subversion, получать доступ к хранящимся на сервере файлам и директориям.
При организации репозиториев соблюдаются следующие основные принципы.
- Репозиторий содержит полное дерево всех файлов и директорий в проекте. В нем хранится главная копия всех файлов исходного кода и, возможно, вспомогательных файлов и документов.
- При записи файла в репозиторий, система Subversion запоминает предыдущее состояние изменяемого файла, и только затем уже обновляет его, так что внесенные изменения немедленно становятся доступными для других разработчиков в команде.
- При чтении файла из репозитория предоставляется последняя версия файла, включая все последние изменения, сделанные другими разработчиками.
Существенное различие между Subversion и обычным файловым сервером, который дополнительно хранит файловое дерево, заключается в том, что Subversion запоминает каждое изменение, которое когда-либо было сделано для каждого файла. Система также помнит каждое изменение, связанное и с директориями: создание, переименование или удаление файлов, или просто их перемещение в структуре директорий.
При чтении файлов из репозитория, по умолчанию предоставляется последняя версия извлекаемого файла или набора файлов. Кроме того, в клиентах Subversion предусмотрена еще и возможность получения любой более ранней версии. Это позволяет использовать Subversion для ответа на такие вопросы как “кто сделал последнее изменение этого файла, и какие это были изменения?” или “как выглядел этот файл на прошлой неделе?”.
Возможность такого достаточно полного отслеживания версий в репозитории Subversion обеспечивает информацию обо всех когда-либо выполненных изменениях в каждом файле и директории проекта.
Рабочие копии
Рабочая копия в системе Subversion - это файловое дерево из репозитория, скопированное на локальный компьютер. Рабочая копия содержит полный или частичный набор файлов проекта и может рассматриваться как частное, временное рабочее пространство конкретного разработчика.
На рис. 1 представлен пример существования нескольких рабочих копий одного проекта. Так, каждый из разработчиков Joe и William имеет собственную рабочую копию проекта, извлеченную в версии Rev1. Каждый из них может вносить собственные изменения в исходные файлы и затем снова помещать их в хранилище, вне зависимости друг от друга.
Другие разработчики оперируют с локальными копиями других версий того же самого проекта: Caroline с версией Rev2, а Mark с версией Rev3.
Рис. 1. Рабочие копии в системе Subversion
Поскольку рабочая копия - это личная рабочая зона конкретного разработчика, то он может оперировать с исходным кодом по своему усмотрению. Можно редактировать, компилировать, отлаживать, тестировать, вносить новые функциональные возможности, и т. д. И пока файлы хранятся только в текущей локальной рабочей копии конкретного разработчика, все изменения в файлах остаются невидимыми для других участников команды. А значит, при работе с локальными копиями действия разных разработчиков в проекте не будут оказывать взаимного влияния друг на друга.
Каждый разработчик может иметь любое количество рабочих копий, одновременно хранящихся на различных местах на его локальном жестком диске. Эту возможность очень удобно использовать в следующих ситуациях:
- Можно работать над реализацией нескольких новых функций или над исправлением нескольких ошибок параллельно. И при этом все правки не окажут никакого взаимного влияния. Так что любые обновления кода могут быть зафиксированы в хранилище по отдельности друг от друга, из разных рабочих копий и в разное время. Subversion гарантирует правильное отслеживание всех изменений, вносимых параллельно за определенный период времени.
- Разработчику, оперирующему в настоящее время с последней версией кода, может понадобиться открыть также и более раннюю версию для проведения сравнительного анализа. Может возникнуть необходимость просмотреть предыдущий исходный код или же скомпилировать и запустить его, чтобы изучить поведение кода во время выполнения. В этом случае, для локального размещения файлов предыдущей версии из репозитория желательно создать отдельную рабочую копию. Преимущество здесь в том, что манипулирование с файлами прежних версий не будет влиять на работу, выполняемую с файлами из последней версии в текущей рабочей копии.
Другими словами, рабочая копия является изолированной, частной областью, где разработчик может работать с исходным кодом определенной версии, не оказывая влияния на код, доступный другим разработчикам, или на код других версий.
Импортирование
Для создания новых репозиториев в системе Subversion используются специальные административные инструменты. А в дальнейшем, разработчики могут самостоятельно наполнять его файловое дерево, уже за пределами существующего хранилища. Например, ведущий разработчик в своей локальной рабочей копии создал определенную структуру проекта и желает поместить ее в общедоступное хранилище.
Рис. 2. Импортирование (import) файлового дерева в систему Subversion
Для импортирования файлового дерева произвольной сложности в центральный репозиторий, в системе Subversion предусмотрена специальная операция import (рис. 2). После того как репозиторий будет заполнен начальными файлами и директориями, все участники команды смогут скопировать их в свою локальную рабочую копию и приступить к работе над ними, периодически синхронизируясь с системой контроля версий Subversion.
Извлечение кода из репозитория
Для создания локальной рабочей копии и ее заполнения копией файлов из центрального репозитория, выполняется специальная операция извлечения check-out.
Рис. 3. Извлечение файлов (check-out) из системы Subversion
В результате выполнения операции, в определенном месте на локальном диске создается рабочая копия, и в нее помещаются локальные копии файлов, доступные для автономной работы. Любые изменения с ними никак не затрагивают содержимое общедоступного репозитория до тех пор, пока не будет выполнена операция фиксирования обновлений (commit, рассматривается в следующем разделе).
На рис. 4 показано, что работа с локальной копией может вестись параллельно с централизованным репозиторием и вне зависимости от него.
Рис. 4. Раздельное существование локальных и общедоступных копий файлов в Subversion
По усмотрению разработчиков, допускается извлечение различных частей файлового дерева репозитория в различные локальные рабочие копии. Также можно получать различные версии файлов или директорий из центрального репозитория и помещать их в различные рабочие копии. Это позволяет иметь на локальном компьютере множество рабочих копий для разных целей, как было описано ранее.