Software-Repository - Software repository
Ein Software-Repository , oder kurz „Repo“, ist ein Speicherort für Softwarepakete . Häufig wird neben Metadaten auch ein Inhaltsverzeichnis gespeichert. Ein Software-Repository wird normalerweise von Quellcodeverwaltungs- oder Repository-Managern verwaltet. Paketmanager ermöglichen das Installieren und Aktualisieren der Repositorys (manchmal als „Pakete“ bezeichnet), anstatt dies manuell tun zu müssen.
Überblick
Viele Softwarehersteller und andere Organisationen unterhalten zu diesem Zweck Server im Internet , entweder kostenlos oder gegen eine Abonnementgebühr. Repositorys können ausschließlich für bestimmte Programme wie CPAN für die Programmiersprache Perl oder für ein ganzes Betriebssystem bestimmt sein . Betreiber solcher Repositorys stellen typischerweise ein Paketverwaltungssystem bereit , Werkzeuge, die dazu bestimmt sind, Softwarepakete aus den Repositorys zu suchen, zu installieren und anderweitig zu manipulieren. Viele Linux-Distributionen verwenden beispielsweise das Advanced Packaging Tool (APT), das häufig in Debian- basierten Distributionen zu finden ist, oder yum, das in Red Hat- basierten Distributionen zu finden ist. Es gibt auch mehrere unabhängige Paketverwaltungssysteme, wie pacman, das in Arch Linux verwendet wird, und equo, das in Sabayon Linux zu finden ist .
Da Software-Repositorys so konzipiert sind, dass sie nützliche Pakete enthalten, sind die wichtigsten Repositorys so konzipiert, dass sie frei von Malware sind . Wenn ein Computer so konfiguriert ist, dass er ein digital signiertes Repository eines seriösen Anbieters verwendet und mit einem entsprechenden Berechtigungssystem gekoppelt ist , reduziert dies die Bedrohung durch Malware für diese Systeme erheblich. Als Nebeneffekt benötigen viele Systeme, die über diese Funktionen verfügen, keine Anti-Malware-Software wie Antiviren-Software .
Die meisten großen Linux-Distributionen haben viele Repositorys auf der ganzen Welt, die das Haupt-Repository spiegeln.
In einer Unternehmensumgebung wird ein Software-Repository normalerweise verwendet, um Artefakte zu speichern oder externe Repositorys zu spiegeln, auf die aufgrund von Sicherheitsbeschränkungen möglicherweise nicht zugegriffen werden kann. Solche Repositorys können zusätzliche Funktionen wie Zugriffskontrolle, Versionierung, Sicherheitsprüfungen für hochgeladene Software, Cluster-Funktionalität usw. bieten und unterstützen in der Regel eine Vielzahl von Formaten in einem Paket, um alle Anforderungen in einem Unternehmen zu erfüllen einen einzigen Punkt der Wahrheit liefern. Beliebte Beispiele sind JFrog Artifactory und das Nexus-Repository.
Auf Client-Seite hilft ein Paketmanager bei der Installation aus und beim Aktualisieren der Repositorys.
Auf der Serverseite wird ein Software-Repository normalerweise von Quellcodeverwaltungs- oder Repository-Managern verwaltet. Einige der Repository-Manager ermöglichen es, andere Repository-Speicherorte in einer URL zusammenzufassen und einen Caching-Proxy bereitzustellen. Bei kontinuierlichen Builds werden viele Artefakte erzeugt und oft zentral gespeichert, daher ist es wichtig, die nicht freigegebenen automatisch zu löschen.
Paketverwaltungssystem vs. Paketentwicklungsprozess
Ein Paketverwaltungssystem unterscheidet sich von einem Paketentwicklungsprozess .
Eine typische Verwendung eines Paketverwaltungssystems besteht darin, die Integration von Code aus möglicherweise unterschiedlichen Quellen in eine kohärente eigenständige Betriebseinheit zu erleichtern. Somit könnte ein Paketverwaltungssystem verwendet werden, um eine Linux-Distribution zu erstellen , möglicherweise eine Distribution, die auf eine bestimmte eingeschränkte Anwendung zugeschnitten ist.
Im Gegensatz dazu wird ein Paketentwicklungsprozess verwendet, um die gemeinsame Entwicklung von Code und die Dokumentation einer Sammlung von Funktionen oder Routinen mit einem gemeinsamen Thema zu verwalten, wodurch ein Paket von Softwarefunktionen erzeugt wird, die normalerweise nicht vollständig und allein verwendbar sind. Ein gutes Paket Entwicklungsprozess hilft Anwendern zu gute Dokumentation und Kodierung Praktiken entsprechen, ein gewisses Maß an Integration Unit - Tests .
Ausgewählte Repositorys
In der folgenden Tabelle sind einige Sprachen mit Repositorys für beigesteuerte Software aufgeführt. Die Spalte "Autochecks" beschreibt die durchgeführten Routinechecks.
Nur sehr wenige Leute haben die Möglichkeit, ihre Software unter mehreren Betriebssystemen mit verschiedenen Versionen des Kerncodes und mit anderen beigesteuerten Paketen zu testen, die sie möglicherweise verwenden. Für die Programmiersprache R führt das Comprehensive R Archive Network (CRAN) routinemäßig Tests durch.
Um zu verstehen, wie wertvoll dies ist, stellen Sie sich eine Situation mit zwei Entwicklern vor, Sally und John. Sally steuert ein Paket A bei. Sally führt die aktuelle Version der Software nur unter einer Version von Microsoft Windows aus und hat sie nur in dieser Umgebung getestet. In mehr oder weniger regelmäßigen Abständen testet CRAN Sallys Beitrag unter einem Dutzend Kombinationen von Betriebssystemen und Versionen der Kernsoftware R. Wenn eine von ihnen einen Fehler generiert, erhält sie diese Fehlermeldung. Mit etwas Glück können diese Fehlermeldungsdetails genügend Input liefern, um eine Behebung des Fehlers zu ermöglichen, auch wenn sie ihn mit ihrer aktuellen Hardware und Software nicht replizieren kann. Nehmen wir als Nächstes an, dass John dem Repository ein Paket B beisteuert, das ein Paket A verwendet. Paket B besteht alle Tests und wird den Benutzern zur Verfügung gestellt. Später reicht Sally eine verbesserte Version von A ein, die leider B zerstört. Die Autochecks ermöglichen es, John Informationen zur Verfügung zu stellen, damit er das Problem beheben kann.
Dieses Beispiel offenbart sowohl eine Stärke als auch eine Schwäche des R-Contributed-Package-Systems: CRAN unterstützt diese Art des automatisierten Testens von Contributed-Packages, aber Pakete, die zu CRAN beigetragen haben, müssen nicht die Versionen anderer Contributed-Packages angeben, die sie verwenden. Es gibt Verfahren zum Anfordern bestimmter Versionen von Paketen, aber Mitwirkende verwenden diese Verfahren möglicherweise nicht.
Darüber hinaus bietet ein Repository wie CRAN, das regelmäßige Überprüfungen der beigesteuerten Pakete durchführt, tatsächlich eine umfangreiche Ad-hoc -Testsuite für Entwicklungsversionen der Kernsprache. Wenn Sally (im obigen Beispiel) eine Fehlermeldung erhält, die sie nicht versteht oder für unangemessen hält, insbesondere von einer Entwicklungsversion der Sprache, kann sie (und tut dies bei R oft) das Kernentwicklungsteam um Hilfe bitten . Auf diese Weise kann das Repository dazu beitragen, die Qualität der Kernsprachsoftware zu verbessern.
| Sprache / Zweck | Paketentwicklungsprozess | Repository | Installationsmethoden | Kollaborative Entwicklungsplattform | Autochecks |
|---|---|---|---|---|---|
| Haskell | Gemeinsame Architektur zum Erstellen von Anwendungen und Bibliotheken | Hacken | Kabale (Software) | ||
| Java | Maven | ||||
| Julia | |||||
| Gemeinsame Lisp | Quicklisp | ||||
| .NETZ | NuGet | NuGet | |||
| Node.js | npm | ||||
| Perl | CPAN | PPM | |||
| PHP | BIRNE , Komponist | PECL , Paketist | |||
| Python | Einrichtungstools | PyPI | pip , EasyInstall , PyPM , Anaconda | ||
| R | R CMD-Prüfprozess | KRAN | install.packages- Fernbedienungen |
GitHub |
Häufig auf 12 Plattformen oder Kombinationen verschiedener Versionen von R (devel, prerel, patched, release) auf verschiedenen Betriebssystemen (verschiedene Versionen von Linux, Windows, macOS und Solaris). |
| Rubin | RubyGems | Ruby-Anwendungsarchiv | RubyForge | ||
| Rost | Ladung | Kisten | Ladung | ||
| TeX , LaTeX | CTAN |
(Teile dieser Tabelle wurden aus einer "Liste der Top-Repositorys nach Programmiersprache" auf Stack Overflow kopiert. )
Viele andere Programmiersprachen, darunter C , C++ und Fortran , besitzen kein zentrales Software-Repository mit universellem Geltungsbereich. Bemerkenswerte Repositories mit begrenztem Umfang sind:
- Netlib , hauptsächlich mathematische Routinen für Fortran und C, historisch gesehen eines der ersten offenen Software-Repositorys;
- Boost , eine streng kuratierte Sammlung hochwertiger Bibliotheken für C++; ein Teil des in Boost entwickelten Codes wurde später Teil der C++-Standardbibliothek.
Paketmanager
Paketmanager helfen bei der Verwaltung von Repositorys und deren Verteilung. Wenn ein Repository aktualisiert wird, erlaubt ein Paketmanager dem Benutzer normalerweise, dieses Repository über den Paketmanager zu aktualisieren. Sie helfen auch bei der Verwaltung von Dingen wie Abhängigkeiten zwischen anderen Software-Repositorys. Einige Beispiele für Paketmanager sind:
| Paket-Manager | Beschreibung |
|---|---|
| npm | Ein Paketmanager für Node.js |
| Pip | Ein Paketinstallationsprogramm für Python |
| geeignet | Zum Verwalten von Debian-Paketen |
| Hausbrauen | Ein Paketinstallationsprogramm für MacOS, mit dem Sie Pakete installieren können, die Apple nicht installiert hat |
| vcpkg | Ein Paketmanager für C und C++ |
| lecker und dnf | Paketmanager für Fedora und Red Hat Enterprise Linux |
| pacman | Paketmanager für Arch Linux |
Repository-Manager
Beziehung zur kontinuierlichen Integration
Als Teil des Entwicklungslebenszyklus wird Quellcode mittels Continuous Integration kontinuierlich in binäre Artefakte eingebaut . Dies kann mit einem binären Repository-Manager interagieren, ähnlich wie es ein Entwickler tun würde, indem er Artefakte aus den Repositorys holt und Builds dorthin verschiebt. Die enge Integration mit CI-Servern ermöglicht die Speicherung wichtiger Metadaten wie:
- Welcher Benutzer hat den Build ausgelöst (ob manuell oder durch die Verpflichtung zur Revisionskontrolle)
- Welche Module wurden gebaut
- Welche Quellen wurden verwendet (Commit-ID, Revision, Branch)
- Verwendete Abhängigkeiten
- Umgebungsvariablen
- Installierte Pakete
Artefakte und Pakete
Artefakte und Pakete bedeuten von Natur aus unterschiedliche Dinge. Artefakte sind einfach eine Ausgabe oder Sammlung von Dateien (zB JAR, WAR, DLLS, RPM etc.) und eine dieser Dateien kann Metadaten enthalten (zB POM-Datei). Während Pakete eine einzelne Archivdatei in einem wohldefinierten Format (z. B. NuGet ) sind, die Dateien enthalten, die für den Pakettyp geeignet sind (z. B. DLL, PDB). Viele Artefakte resultieren aus Builds, aber auch andere Arten sind entscheidend. Pakete sind im Wesentlichen eines von zwei Dingen: eine Bibliothek oder eine Anwendung.
Im Vergleich zu Quelldateien sind binäre Artefakte oft um Größenordnungen größer, sie werden selten gelöscht oder überschrieben (außer in seltenen Fällen wie Snapshots oder nächtliche Builds) und sie werden normalerweise von vielen Metadaten wie ID, Paketname, Version begleitet , Lizenz und mehr.
Metadaten
Metadaten beschreiben ein binäres Artefakt, werden getrennt vom Artefakt selbst gespeichert und angegeben und können mehrere zusätzliche Verwendungen haben. Die folgende Tabelle zeigt einige gängige Metadatentypen und ihre Verwendung:
| Metadatentyp | Benutzt für |
|---|---|
| Verfügbare Versionen | Automatisches Upgrade und Downgrade |
| Abhängigkeiten | Geben Sie andere Artefakte an, von denen das aktuelle Artefakt abhängt |
| Downstream-Abhängigkeiten | Geben Sie andere Artefakte an, die vom aktuellen Artefakt abhängen |
| Lizenz | Rechtskonformität |
| Datum und Uhrzeit erstellen | Rückverfolgbarkeit |
| Dokumentation | Stellen Sie Offline-Verfügbarkeit für kontextbezogene Dokumentation in IDEs bereit |
| Zulassungsinformationen | Rückverfolgbarkeit |
| Messwerte | Codeabdeckung, Regelkonformität, Testergebnisse |
| Vom Benutzer erstellte Metadaten | Benutzerdefinierte Berichte und Prozesse |