РЕПОЗИТОРИЙ КАК СРЕДСТВО ПРЕДОСТАВЛЕНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ В ПРОЦЕССЕ ЕГО РАЗВЁРТЫВАНИЯ

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

Наиболее важная проблема, с которой сталкиваются разработчики при развёртывании программного обеспечения, состоит в том, как в кратчайший срок предоставить пользователям очередную версию приложения после добавления в него нового средства [1]. Новые полезные идеи появляются весьма часто. Кроме того, после обнаружения ошибки в приложении необходимо как можно быстрее устранить её и предоставить пользователям исправленную версию. Не менее значимой также является проблема распространения файлов установки программного обеспечения между пользователями и разработчиками.

Одним из средств предоставления программного обеспечения является хранение установочных файлов в репозиторий. Согласно стандарту ГОСТ Р 54593-2011 «Информационные технологии. Свободное программное обеспечение» даётся следующее определение данному понятию: репозиторий программных пакетов - замкнутая совокупность программных пакетов и метаинформации о них. Репозитории позволяют пользователю использовать простой, централизованный метод установки программ, а также предоставляет удобный способ их обновления [2]. В репозиториях также имеется система контроля версий, в которой хранится история изменения исходных текстов программы.

Другим средством предоставления программного обеспечения является клиент-серверная система контроля версий. Данные системы доминировали в течение 1980-х и 1990-х гг. на рынке, но распространение сети Интернет и распределённой модели разработки показал их два существенных недостатка:

• любые операции для работы с историей требуют подключения к серверу;
• небольшое количество информации в рабочей копии разработчика требует передачи значительных объёмов данных по сети.

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

Для решения проблем клиент-серверных систем были придуманы распределённые системы контроля версий. В распределённых системах практически нет разделения на репозитории и рабочие копии, поскольку любая полная рабочая копия содержит полную историю проекта и может выступать в качестве репозитория. Такой подход позволил решить как проблему работы без подключения к серверу, так и на низкоскоростных соединениях: получив один раз полную историю изменений проекта, разработчик может работать удалённо, периодически получая новые изменения из другого репозитория и отправляя туда свои изменения.

Ранние опыты в разработке распределённых систем контроля версий Arch и Monotone работали достаточно медленно, но позволили накопить опыт для создания быстродействующих распределённых систем контроля версий, таких как git.

Git разрабатывался как система контроля версий для ядра Linux, но оказался крайне удобен для разработчиков дистрибутивов Linux.

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

Импорт из множества систем контроля версий. Использовать для разработки дистрибутива десятки или даже сотни систем контроля версий, которыми пользуются разработчики ПО, слишком сложно. Вместо этого для выбранной системы контроля версий должен существовать набор конвертеров для импорта истории из других систем контроля версий. Для git существует множество конвертеров из свободных и закрытых систем контроля версий. В частности, конверторы git-cvsimport и git-svn входят в стандартный набор инструментов git.

Очень высокая скорость работы. Единицы и десятки секунд, требуемых для фиксации изменения, - неприемлемо низкая скорость работы для разработчика дистрибутива. Также неприемлема деградация производительности при росте дерева исходного текста. git показывает самую высокую скорость среди распределённых систем контроля версий, как для фиксации изменений, так и для их просмотра, поиска и обмена по сети.

Удобство ведения параллельных ветвей разработки, независимых от основной разработки. Разработчики дистрибутивов часто вынуждены вести свою собственную ветку, имеющую долгое время существования и включающую изменения, необходимые для интеграции приложений в дистрибутив. Без наличия инструментов для удобной работы с такими ветками производительность разработчиков дистрибутива будет крайне низка. git предоставляет инструмент слияния ветвей, учитывающую такой вариант использования, а также инструмент для адаптации локальных изменений к новым версиям исходного кода.

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

Различают два вида замкнутости [3]:

• замкнутость по установке – попытка установить все бинарные пакеты не обнаружит неудовлетворенных зависимостей;
• замкнутость по сборке – возможность полностью пересобрать репозиторий из собственных исходных пакетов.

Таким образом, для решения проблемы предоставления программного обеспечения в процессе его развёртывания выбирается использование репозитория. Основным преимуществом репозитория перед другими средствами предоставления заключается в его замкнутости. Использование других средств предоставления программного обеспечения приводит к затруднительным действиям как разработчиков, так и пользователей. Это связано с недостатками данных средств. Использование репозиториев среди пользователей является простым, централизованным методом установки или удаления программ, а также их распространения; для разработчиков репозитории удобны своим способом загрузки обновлений программного обеспечения.

Список литературы:

1. Дж. Хамбл, Д. Фарли, Непрерывное развертывание ПО: автоматизация процессов сборки, тестирования и внедрения новых версий программ. : Пер. с англ. — М. : ООО “И.Д. Вильямс”, 2011. — 432 с.;
2. Репозитории | Русскоязычная документация по Ubuntu [Электронный ресурс], URL: http://help.ubuntu.ru/wiki/репозиторий (Дата обращения 30.10.2016);
3. Репозиторий СПО [Электронный ресурс], URL: https://www.altlinux.org/Репозиторий_СПО (Дата обращения 17.11.2016)