Войти
A репозиторий программного обеспечения, или для краткости «репо», является местом хранения пакетов программного обеспечения. Часто оглавление сохраняется, а также метаданные. Репозитории групповых пакетов. Иногда группировка предназначена для языка программирования, например CPAN для языка программирования Perl, иногда для всей операционной системы, иногда лицензия на содержимое критерии. В корпоративной среде репозиторий программного обеспечения обычно используется для хранения артефактов или для зеркалирования внешних репозиториев, которые могут быть недоступны из-за ограничений безопасности. Такие репозитории могут предоставлять дополнительные функции, такие как контроль доступа, управление версиями, проверки безопасности для загруженного программного обеспечения, функциональные возможности кластера и т. Д., И обычно поддерживают различные форматы в одном пакете, чтобы удовлетворить все потребности предприятия, и, таким образом, чтобы обеспечить единую истину. Популярные примеры - Artifactory и Nexus.
На стороне клиента менеджер пакетов помогает устанавливать и обновлять репозитории.
На стороне сервера репозиторий программного обеспечения обычно управляется системой контроля версий или менеджерами репозитория. Некоторые из менеджеров репозиториев позволяют объединить другое местоположение репозитория в один URL-адрес и предоставить кэширующий прокси. При непрерывной сборке создается множество артефактов, которые часто хранятся централизованно, поэтому важно автоматическое удаление тех, которые не были выпущены.
Многие издатели программного обеспечения и другие организации поддерживают серверы в Интернете для этой цели либо бесплатно, либо за абонентскую плату. Хранилища могут быть исключительно для определенных программ, таких как CPAN для языка программирования Perl или для всей операционной системы. Операторы таких репозиториев обычно предоставляют систему управления пакетами, инструменты, предназначенные для поиска, установки и иного управления пакетами программного обеспечения из репозиториев. Например, многие дистрибутивы Linux используют Advanced Packaging Tool (APT), обычно встречающийся в дистрибутивах на основе Debian, или yum, найденный в Распределения на основе Red Hat. Также существует несколько независимых систем управления пакетами, таких как pacman, используемый в Arch Linux и equo, найденный в Sabayon Linux.
Поскольку репозитории программного обеспечения предназначены для включения полезных пакетов, разработаны основные репозитории быть вредоносным свободным. Если компьютер настроен на использование репозитория с цифровой подписью от известного поставщика и в сочетании с соответствующей системой разрешений , это значительно снижает угрозу вредоносного ПО для этих систем. В качестве побочного эффекта многие системы, обладающие этими возможностями, не требуют антивирусного программного обеспечения, такого как антивирусное программное обеспечение.
Большинство основных дистрибутивов Linux имеют множество репозиториев по всему миру, которые отражают основные репозиторий.
A Система управления пакетами отличается от процесса разработки пакетов.
Типичное использование системы управления пакетами - облегчить интеграцию код из, возможно, разных источников, в целостную автономную операционную единицу. Таким образом, система управления пакетами может использоваться для создания дистрибутива Linux, возможно, дистрибутива, адаптированного для конкретного ограниченного приложения.
Процесс разработки пакета, напротив, используется для управления совместной разработкой кода и документации набора функций или подпрограмм с общей темой, создавая тем самым пакет программных функций, которые обычно не используются. полные и пригодные для использования сами по себе. Хороший процесс разработки пакетов поможет пользователям соответствовать хорошей документации и методам кодирования, интегрировав некоторый уровень модульного тестирования. В таблице ниже приведены примеры процессов разработки пакетов.
В следующей таблице перечислены несколько языков с репозиториями для предоставленного программного обеспечения. В столбце «Автоматические проверки» описаны выполненные стандартные проверки.
Очень немногие люди имеют возможность тестировать свое программное обеспечение в нескольких операционных системах с разными версиями основного кода и с другими предоставленными пакетами, которые они могут использовать. Для R, комплексная сеть архивов R (CRAN) регулярно выполняет тесты. Чтобы увидеть, насколько это ценно, предположим, что Салли предоставляет пакет A. Салли запускает только текущую версию программного обеспечения под одной версией Microsoft Windows и только тестировала ее в этой среде. С более или менее регулярными интервалами CRAN тестирует вклад Салли в дюжине комбинаций операционных систем и версий программного обеспечения на основном языке R. Если один из них выдает ошибку, она получает это сообщение об ошибке. Если повезет, этого сообщения об ошибке может быть достаточно, чтобы позволить ей исправить ошибку, даже если она не может воспроизвести ее с помощью имеющегося у нее оборудования и программного обеспечения. Затем предположим, что Джон вносит в репозиторий пакет B, который использует пакет A. Пакет B проходит все тесты и становится доступным для пользователей. Позже Салли отправляет улучшенную версию A, которая, к сожалению, ломает B. Автоматические проверки позволяют предоставить Джону информацию, чтобы он мог решить проблему.
Этот пример демонстрирует как сильные, так и слабые стороны системы дополнительных пакетов R: CRAN поддерживает этот вид автоматического тестирования дополнительных пакетов, но пакеты, внесенные в CRAN, не должны указывать версии других добавленных пакетов, которые они используют. Существуют процедуры для запроса конкретных версий пакетов, но участники могут не использовать эти процедуры.
Помимо этого, репозиторий, такой как CRAN, выполняющий регулярные проверки предоставленных пакетов, фактически предоставляет обширный набор специальных тестов для разрабатываемых версий основного языка. Если Салли (в приведенном выше примере) получает сообщение об ошибке, которое она не понимает или считает неуместным, особенно в разрабатываемой версии языка, она может (и часто делает это с R) обратиться за помощью к основной группе разработчиков.. Таким образом, репозиторий может способствовать повышению качества программного обеспечения на основном языке.
| Язык / цель | Процесс разработки пакета | Репозиторий | Методы установки | Платформа совместной разработки | Autochecks |
|---|---|---|---|---|---|
| Haskell | Общая архитектура для Создание приложений и библиотек | Взлом | |||
| Java | Maven | ||||
| Julia | |||||
| Common Lisp | Quicklisp | ||||
| .NET | NuGet | NuGet | |||
| Node.js | NPM | ||||
| Perl | CPAN | PPM | |||
| PHP | PEAR, Composer | PECL, Packagist | |||
| Python | Setuptools | PyPI | pip, EasyInstall, PyPM, Anaconda | ||
| R | R CMD check process | CRAN | install.packages | Примерно еженедельно на 12 платформах или комбинациях различных версий R (devel, prerel, patched, release) с 7 различными операционными системами (разные версии Linux, Windows и Mac). | |
| Ruby | RubyGems | Архив приложений Ruby | RubyForge | ||
| Rust | Cargo | Ящики | Cargo | ||
| TeX, LaTeX | CTAN |
(части этой таблицы были скопированы из «Списка самых популярных репозиториев по языку программирования» на Stack Overflow )
Многие другие языки программирования, среди них C, C ++, и Fortran, не имеют центрального репозитория программного обеспечения с универсальной областью применения. Известные репозитории с ограниченным охватом включают:
Менеджеры пакетов помогают управлять репозиториями и их распространением. Если репозиторий обновляется, менеджер пакетов обычно позволяет пользователю обновлять этот репозиторий через менеджер пакетов. Они также помогают в управлении этим такие как зависимости между другими репозиториями программного обеспечения. Вот некоторые примеры менеджеров пакетов:
| Менеджер пакетов | Описание |
|---|---|
| NPM | Менеджер пакетов для Node.js |
| pip | Установщик пакетов для Python |
| APT | Для управления пакетами Debian |
| Homebrew | Программа установки пакетов для MacOS, позволяющая устанавливать пакеты, которые не использовала Apple |
В рамках жизненного цикла разработки исходный код постоянно встраивается в двоичные артефакты с использованием непрерывной интеграции. Он может взаимодействовать с диспетчером двоичного репозитория так же, как разработчик, получая артефакты из репозиториев и отправляя туда сборки. Тесная интеграция с серверами CI позволяет хранить важные метаданные, такие как:
Артефакты и пакеты по своей сути означают разные вещи. Артефакты - это просто выходные данные или набор файлов (например, JAR, WAR, DLLS, RPM и т. Д.), И один из этих файлов может содержать метаданные (например, файл POM). В то время как пакеты представляют собой один архивный файл в четко определенном формате (например, NuGet ), который содержит файлы, соответствующие типу пакета (например, DLL, PDB). Многие артефакты возникают в результате сборки, но важны и другие типы. Пакеты - это, по сути, одно из двух: библиотека или приложение.
По сравнению с исходными файлами двоичные артефакты часто на порядки больше, они редко удаляются или перезаписываются (за исключением редких случаев, таких как снимки или ночные сборки), и они обычно сопровождаются большим количеством метаданных, таких как идентификатор, имя пакета, версия, лицензия и многое другое.
Метаданные описывают двоичный артефакт, хранятся и указываются отдельно от самого артефакта и могут иметь несколько дополнительных применений. В следующей таблице показаны некоторые общие типы метаданных и их использование:
| Тип метаданных | Используется для |
|---|---|
| доступных версий | Автоматическое обновление и понижение версии |
| Зависимости | Укажите другие артефакты, от которых зависит текущий артефакт |
| Нисходящие зависимости | Укажите другие артефакты, которые зависят от текущего артефакта |
| Лицензия | Правовое соответствие |
| Дата и время сборки | Прослеживаемость |
| Документация | Обеспечивает автономную доступность контекстной документации в IDE |
| Информация об утверждении | Прослеживаемость |
| Метрики | Покрытие кода, соответствие правила, результаты тестирования |
| Пользовательские метаданные | Пользовательские отчеты и процессы |
.
Программное обеспечение для управления репозиториями (менеджеры репозиториев) включает: