Репозиторий программирование

Репозиторий программногообеспечения . Или “репо” для краткости. Является местом хранения пакетов программногообеспечения . Часто также хранится оглавление вместе с метаданными. Репозиторий программного обеспечения обычно управляется системой управления версиями или менеджерами репозиториев. Менеджеры пакетов позволяют устанавливать и обновлять репозитории (иногда называемые “пакетами”). А не делать это вручную.

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

CPAN для языка программирования Perl. Или для всей операционной системы. Операторы таких хранилищ обычно предоставляют систему управления пакетами, инструменты. Предназначенные для поиска. Установки и иного управления пакетами программного обеспечения из хранилищ. Например, многие дистрибутивы Linux используют Advanced Packaging Tool (APT). Обычно встречающийся в дистрибутивах на основе Debian. Или yum встречается в дистрибутивах на базе Red Hat. Существует также несколько независимых систем управления пакетами. Таких как pacman. Используемая в

Arch Linux, и equo. Найденная в Sabayon Linux.

Поскольку репозитории программного обеспечения предназначены для включения полезных пакетов. Основные репозитории предназначены для того. Чтобы быть свободными от вредоносных программ. Если компьютер настроен на использование хранилища с цифровой подписью от авторитетного поставщика и связан с соответствующей системой разрешений, это значительно снижает угрозу вредоносного ПО для этих систем. В качестве побочного эффекта многие системы. Обладающие этими возможностями. Не требуют антивирусного программного обеспечения. Такого как антивирусное программноеобеспечение.]

Большинство основных дистрибутивов Linux имеют множество репозиториев по всему миру. Которые отражают основной репозиторий.

В корпоративной среде репозиторий программного обеспечения обычно используется для хранения артефактов или зеркального отображения внешних репозиториев. Которые могут быть недоступны из-за ограничений безопасности. Такие репозитории могут предоставлять дополнительные функциональные возможности. Такие как контроль доступа. Управление версиями. Проверка безопасности загруженного программного обеспечения. Функциональность кластера и т. Д., и обычно поддерживают различные форматы в одном пакете. Чтобы удовлетворить все потребности предприятия и. Таким образом. Обеспечить единую точку истины.

Популярными примерами являются JFrog Artifactory[2][3] и Nexus repository[4]

На стороне клиента менеджер пакетов помогает устанавливать и обновлять репозитории.

На стороне сервера репозиторий программного обеспечения обычно управляется системой управления версиями или менеджерами репозиториев. Некоторые менеджеры репозиториев позволяют объединять другие местоположения репозиториев в один URL-адрес и предоставлять кэширующий прокси-сервер. При непрерывной сборке создается много артефактов. Которые часто хранятся централизованно. Поэтому важно автоматически удалять те. Которые еще не выпущены.

Система управления пакетами и процесс разработки пакетов

Система управления пакетами отличается от процесса разработки пакетов.

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

Процесс разработки пакета, напротив. Используется для управления совместной разработкой кода и документации набора функций или подпрограмм с общей темой. Создавая таким образом пакет программных функций. Которые обычно не будут полными и пригодными для использования сами по себе. Хороший процесс разработки пакетов поможет пользователям соответствовать хорошей документации и практике кодирования. Интегрируя некоторый уровень модульного тестирования.

Выбранные хранилища

В следующей таблице перечислены несколько языков с репозиториями для предоставленного программного обеспечения. Колонка

Очень немногие люди имеют возможность тестировать свое программное обеспечение под несколькими операционными системами с различными версиями основного кода и с другими предоставленными пакетами. Которые они могут использовать. Для RКомплексная архивная сеть R (CRAN) регулярно проводит тесты. Чтобы понять. Насколько это ценно. Предположим. Что Салли предоставляет пакет А. Салли запускает только текущую версию программного обеспечения под одной версией Microsoft Windows и тестировала его только в этой среде. Через более или менее регулярные промежутки времени КРЭН тестирует вклад Салли в дюжину комбинаций операционных систем и версий основного программного обеспечения на языке R. Если кто — то из них выдает ошибку. Она получает это сообщение. Если повезет. Этого сообщения об ошибке может быть достаточно. Чтобы позволить ей исправить ошибку. Даже если она не сможет воспроизвести ее с помощью имеющегося у нее оборудования и программного обеспечения. Затем предположим. Что Джон вносит в репозиторий пакет B. Который использует пакет A. Пакет B проходит все тесты и становится доступным для пользователей. Позже Салли представляет улучшенную версию А, которая. К сожалению. Ломает Б. Автопроверки позволяют предоставить Джону информацию. Чтобы он мог решить проблему.

Этот пример показывает как силу. Так и слабость в системе R contributed-package: CRAN поддерживает этот вид автоматизированного тестирования вложенных пакетов, но пакеты. Внесенные в CRAN. Не должны указывать версии других вложенных пакетов. Которые они используют. Существуют процедуры запроса конкретных версий пакетов. Но участники проекта могут не использовать эти процедуры.

Помимо этого. Репозиторий. Такой как CRAN. Выполняющий регулярные проверки внесенных пакетов. Фактически предоставляет обширный. Если не специальный набор тестов для разработки версий основного языка. Если Салли (в приведенном выше примере) получает сообщение об ошибке. Которое она не понимает или считает неуместным. Особенно из версии языка разработки. Она может (и часто делает это с R) обратиться за помощью к основной команде разработчиков этого языка. Таким образом. Репозиторий может внести свой вклад в повышение качества основного языкового программного обеспечения.

Язык / цель Процесс Разработки Пакета Хранилище Методы установки Платформа совместной разработки Авточеки
Хаскелл Общая архитектура для построения приложений и библиотек[5] Хакаж кабал (программное обеспечение)
Ява Maven[6]
Джулия[7]
Общий Шепелявый Quicklisp[8]
.NET NuGet NuGet[9]
Node.js npm[10]
Perl CPAN PPM[11]
PHP ГРУША, Композитор ПЕКЛ, Упаковщик
Питон Setuptools ПиПИ pip, EasyInstall, PyPM, Anaconda
Р R CMD check process[12][13] КРЭН[14] install.packages[15]
remotes[16]
GitHub[17] Часто на 12 платформах или комбинациях различных версий R (devel. Prerel, patched. Release) в разных операционных системах (различные версии Linux, Windows. MacOS и Solaris).
Рубин РубиГемы Архив приложений Ruby Рубифорж
Ржавчина Груз[18] Ящики[19] Груз[18]
Текс, латекс CTAN

(Части этой таблицы были скопированы из Stack Overflow[20].)

Многие другие языки программирования. В том числе C, C++и Fortran, не имеют центрального хранилища программного обеспечения с универсальной областью применения. Известные репозитории с ограниченным охватом включают в себя:

  • Netlib, в основном математические подпрограммы для Fortran и C. Исторически один из первых открытых репозиториев программного обеспечения;
  • Boost-строго контролируемая коллекция высококачественных библиотек для C++; некоторый код . Разработанный в Boost. Позже стал частью стандартной библиотеки C++.

Менеджеры пакетов

Менеджеры пакетов помогают управлять репозиториями и их распространением. Если репозиторий обновляется. Менеджер пакетов обычно позволяет пользователю обновлять этот репозиторий через менеджер пакетов. Они также помогают управлять такими вещами. Как зависимости между другими репозиториями программного обеспечения. Некоторые примеры менеджеров пакетов включают в себя:

Менеджеры репозиториев

Отношение к непрерывной интеграции

В рамках жизненного цикла разработки исходный код непрерывно встраивается в двоичные артефакты с помощью непрерывной интеграции. Это может взаимодействовать с двоичным менеджером репозиториев так же. Как разработчик. Получая артефакты из репозиториев и толкая туда сборки. Тесная интеграция с серверами CI позволяет хранить важные метаданные, такие как:

  • Какой пользователь инициировал сборку (вручную или путем фиксации в системе управления версиями)
  • Какие модули были построены
  • Какие источники были использованы (идентификатор фиксации. Ревизия, ветвь)
  • Используемые зависимости
  • Переменные среды
  • Установленные пакеты

Артефакты и пакеты

Артефакты и пакеты по своей сути означают разные вещи. Артефакты-это просто выходные данные или коллекция файлов (например. JAR, WAR, DLL, RPM и т. Д.) И Один из этих файлов может содержать метаданные (например, POM-файл). В то время как пакеты представляют собой один архивный файл в четко определенном формате (например, NuGet), который содержит файлы. Соответствующие типу пакета (например. DLL, PDB).[29] Многие артефакты являются результатом сборки. Но другие типы также имеют решающее значение. Пакеты-это, по сути. Одна из двух вещей: библиотека или приложение.[30]

По сравнению с исходными файлами двоичные артефакты часто больше на порядки. Они редко удаляются или перезаписываются (за исключением редких случаев. Таких как моментальные снимки или ночные сборки). И они обычно сопровождаются большим количеством метаданных. Таких как идентификатор. Имя пакета, версия. Лицензия и многое другое.

Метаданные

Метаданные описывают двоичный артефакт. Хранятся и задаются отдельно от самого артефакта и могут иметь несколько дополнительных применений. В следующей таблице приведены некоторые распространенные типы метаданных и их использование:

Тип метаданных Используется для
Доступные версии Автоматическое обновление и понижение рейтинга
Зависимости Укажите другие артефакты. От которых зависит текущий артефакт
Нисходящие зависимости Укажите другие артефакты. Зависящие от текущего артефакта
Лицензия Соблюдение законодательства
Дата и время сборки Прослеживаемость
Документация Обеспечьте автономную доступность контекстной документации в IDE
Информация об утверждении Прослеживаемость
Метрика Охват кода. Соответствие правилам. Результаты испытаний
Созданные пользователем метаданные Пользовательские отчеты и процессы
  1. ^
  2. ^ https://www.wikieduonline.com/wiki/JFrog_Artifactory
  3. ^ https://jfrog.com/artifactory/
  4. ^ https://www.sonatype.com/products/repository-pro
  5. ^ . www.haskell.org. Извлечено 2019-03-25.
  6. ^ . maven.apache.org. Извлечено 2019-03-25.
  7. ^ . pkg.julialang.org. Извлечено 2019-03-25.
  8. ^ . www.quicklisp.org. Извлечено 2019-03-25.
  9. ^ каранн-msft. . docs.microsoft.com. Извлечено 2019-03-25.
  10. ^ . www.npmjs.com. Извлечено 2019-03-25.
  11. ^ . www.cpan.org. Извлечено 2019-03-25.
  12. ^ Leisch, Friedrich. (PDF).
  13. ^ Грейвс, Спенсер Б.; Дорай-Радж, Сундар. (PDF).
  14. ^ . cran.r-project.org. Извлечено 2019-03-25.
  15. ^ . cran.r-project.org. Извлечено 2019-03-25.
  16. ^ Уикхем, Хэдли; Брайан, Дженни. . Пакеты R. О’Рейли.
  17. ^ Decan, Alexandre; Mens, Tom; Claes, Maelick; Grosjean, Philippe (2015). Материалы Европейской конференции по архитектуре программного обеспечения 2015 — ECSAW ’15: 1-6. doi:10.1145/2797433.2797476.
  18. ^ b . Документация. Язык программирования Rust. Извлечено 2019-08-26.
  19. ^ . crates.io. Извлечено 2019-08-26.
  20. ^ . Переполнение стека. Проверено 2010-04-14.
  21. ^ . www.npmjs.com. 2019-11-21 .
  22. ^ разработчики. The pip, pip: Рекомендуемый PyPA инструмент для установки пакетов Python., проверено 2019-11-21
  23. ^ . wiki.debian.org. Проверено 2019-11-22.
  24. ^ . Доморощенный. Проверено 2019-11-22.
  25. ^ . Времена СД. 20 сентября 2016 года.
  26. ^ . Времена СД. 25 апреля 2018 года.
  27. ^ Чинтагунтла, Керти. . Включить Sysadmin. 2021-04-11 .
  28. ^ . вики.archlinux.org. Получено 2021-04-11.
  29. ^ Крис, Такер (2007-03-15). (PDF). UC San Diego: 1. 2011-09-14.
  30. ^ . брейнтикл.blogspot.com. Проверено 2008-03-01.