-
HINTERGRUND
-
Vor einigen Jahren haben Softwareingenieure sich zum Ziel gesetzt, Applikationen auf einer Vielzahl von Plattformen zu bauen, wie etwa iOS, Android, Windows Phone, BlackBerry und Firefox OS. Diese Applikationen benutzen oft Softwareentwicklungssysteme, die den Nutzern Zugriff auf Daten und Funktionalität, wie Landkarten, E-Mails, Nachrichten und soziale Netzwerkinformationen bereitstellen. Ein Softwareentwicklungssystem kann auch einen Satz von Softwareentwicklungstools, Bibliotheken, Dokumentation, Header-Dateien und Muster umfassen, die für die Entwicklung von Applikationen für eine bestimmte Entwicklungsplattform mit spezifischer Funktionalität benutzt werden können, die in dem Softwareentwicklungssystem festgelegt wird. Softwareentwicklungssysteme können Programmierschnittstellen, umfassen, sodass Softwareentwickler einen kontrollierten Zugriff auf Methoden und Daten von anderen Applikationen oder Service wie etwa Webservice haben können. Unter Schutz gestellt werden und Gegenstand des Gebrauchsmusters sind, entsprechend den Vorschriften des Gebrauchsmustergesetzes, lediglich Vorrichtungen wie in den beigefügten Schutzansprüchen definiert, jedoch keine Verfahren. Soweit nachfolgend in der Beschreibung gegebenenfalls auf Verfahren Bezug genommen wird, dienen diese Bezugnahmen lediglich der beispielhaften Erläuterung der in den beigefügten Schutzansprüchen unter Schutz gestellten Vorrichtung oder Vorrichtungen.
-
So kann beispielsweise ein Anbieter eines Softwareentwicklungssystems einen Mapping-Service und eine Landkartenprogrammierschnittstelle entwickeln, damit Softwareentwickler Zugriff auf die Funktionalität des Mapping-Services erhalten. Das Softwareentwicklungssystem für Landkarten kann Mustercode, Bibliotheken und Dokumentationen dahingehend wie die Landkartenfunktionalität benutzt werden sollte, umfassen. Die Landkartenprogrammierschnittstelle kann Informationen über den Mapping-Service einschließlich Methoden enthalten, wie man Folgendes erhält: Wegbeschreibungen zu einem Standort, die Reiseentfernung zwischen Standorten, die Reisezeit zwischen Standorten und die Höhenangabe eines Standortes. Falls ein Softwareentwickler eine Applikation für ein Fast-Food-Restaurant entwickelt, kann der Softwareentwickler die Landkartenprogrammierschnittstelle verwenden, um es einem Nutzer möglich zu machen, Wegbeschreibungen zum Restaurant vom aktuellen Standort des Nutzers abzufragen. Der Softwareentwickler muss keinen spezifischen Code für Landkarten schreiben, um die Wegbeschreibungen zu erhalten, aber stattdessen die Landkartenprogrammierschnittstelle nutzen, um Zugriff auf die Funktionalität des Mapping-Services und Wegbeschreibungen erhalten.
-
Üblicherweise hat jedes Team für ein Softwareentwicklungssystem einen von anderen Teams für Softwareentwicklungssysteme gänzlich unabhängigen End-zu-End-Releaseprozess. Diese getrennten Releaseprozesse können verschiedene Probleme aufweisen. So können beispielsweise individuelle Softwareentwicklungssysteme in verschiedenen Formaten bereitgestellt werden, was zu inkonsistente Paketstrukturen und Komponenten führt, die den Entwicklern verfügbar gemacht werden. Entwickler müssen dann wissen, wie mit jedem bestimmten Format umgegangen werden soll. Ein weiteres Problem ergibt sich als minimal, falls jegliche Kompatibilitätstests unter Softwareentwicklungssystemen durchgeführt werden. Da jedes Team für ein Softwareentwicklungssystem ein eigenes Softwareentwicklungssystem freigibt, testet jedes Team nur sein eigenes Softwareentwicklungssystem, ohne andere Softwareentwicklungssysteme in Betracht zu ziehen, die auf der gleichen Entwicklungsplattform benutzt werden können. Fehlendes Testen unter Softwareentwicklungssystemen kann binäre Inkompatibilitäten unter entwickelten Softwareentwicklungssystemen schaffen, da Softwareentwicklungssysteme von der gleichen Abhängigkeit abhängig sein können, aber unterschiedliche Versionen der Abhängigkeit nutzen. Ein weiteres Problem ergibt sich, da es aktuell keinen Weg gibt, eine konsistente Dokumentation über ein Softwareentwicklungssystem bereitzustellen, einschließlich wie ein spezifisches Softwareentwicklungssystem in einem Entwicklungsprojekt genutzt werden kann. Des Weiteren gibt es keine Koordination des externen Messaging unter freigegebenen Softwareentwicklungssystemen für eine bestimmte Softwareplattform.
-
Wie die Erfinder erkannt haben, sollte es ein automatisiertes System geben, dass einen End-zu-End-Releaseprozess für Softwareentwicklungssysteme geben sodass Softwareentwicklungssysteme in Verbindung mit anderen Softwareentwicklungssystemen freigegeben werden können.
-
KURZDARSTELLUNG
-
Diese Spezifikation beschreibt Technologien bezüglich dem Hosting und Publishing von Softwarepaketen.
-
Im Allgemeinen können Aspekte des in dieser Spezifikation beschriebenen Gegenstands in computerimplementierten Verfahren und Systemen realisiert werden. Ein Beispielsystem beinhaltet ein oder mehrere Verarbeitungsgeräte und Speichersysteme, die Anweisungen speichern, die bei der Ausführung durch ein oder mehrere Verarbeitungsgeräte ein oder mehrere Verarbeitungsgeräte veranlassen, ein Beispielverfahren umzusetzen. Ein Beispielverfahren beinhaltet: Empfangen und Speichern von Artefakten in Bezug auf ein Softwareentwicklungssystem und Metadaten, die die Version des Softwareentwicklungssystems beschreiben; Umwandeln der empfangenen Artefakte und Metadaten in ein Paket für das Softwareentwicklungssystem; Aufbereiten des Pakets und Prüfen aller Abhängigkeiten des Pakets, um sicherzustellen, dass die Abhängigkeiten des Pakets existieren und es keinen Abhängigkeitskonflikt mit einem anderen aufbereiteten Paket gibt; Testen der derzeit aufbereiteten Pakete, um festzustellen, ob es jegliche Inkompatibilitäten unter den aufbereiteten Paketen gibt und Verwenden von Zugriffssteuerungsinformationen, um die derzeit aufbereiteten Pakete in einem gebräuchlichen Format für die angemessenen Nutzer bereit zu stellen.
-
Ein weiteres Beispielsystem für Hosting und Publishing von Softwarepaketen umfasst: einen Host für ein Softwareentwicklungssystem, der Artefakte in Bezug auf ein Softwareentwicklungssystem und Metadaten, die die Version des Softwareentwicklungssystems beschreiben, empfängt und speichert; einen Wandler, der die empfangenen Artefakte und Metadaten in ein Paket für das Softwareentwicklungssystem umwandelt; einen Staginghost, der das Paket aufbereitet und alle Abhängigkeiten prüft, um sicherzustellen das die Abhängigkeiten des Pakets existieren und es keinen Abhängigkeitskonflikt mit einem anderen aufbereiteten Paket gibt; einen Tester, der die derzeit aufbereiteten Pakete holt und testet, um festzustellen, ob es jegliche Inkompatibilitäten unter den aufbereiteten Paketen gibt; einen Pakethost, der die derzeit aufbereiteten Pakete vom Tester empfängt und Zugriffssteuerungsinformationen verwendet, um die derzeit aufbereiteten Pakete in einem gebräuchlichen Format für angemessene Nutzer bereit zu stellen.
-
Diese und andere Ausführungsformen können als Option eine oder mehrere der folgenden Eigenschaften beinhalten. Artefakte können umfassen: Änderungsprotokolle, Lizenzdateien, Ressourcen, Mediendateien, Musterprojekte, Quelldateien, kompilierte Binärdateien, Bibliotheken und andere Informationen in Bezug auf ein spezielles Softwareentwicklungssystem. Artefakte können in einem komprimierten Format empfangen werden. Metadaten können umfassen: den Namen des Softwareentwicklungssystems, Versionierungsinformationen, Abhängigkeiten des Softwareentwicklungssystems, Beschreibungen, was das Softwareentwicklungssystem ausführt, die Verfasser eines Softwareentwicklungssystems, Kontaktinformationen für Verfasser eines Softwareentwicklungssystems, Lizenzinformationen, die offizielle Website für ein Softwareentwicklungssystem, Plattformanforderungen für das Softwareentwicklungssystem, Screenshots, Befehle, die vor dem Integrieren des Softwareentwicklungssystems ausgeführt werden müssen, Missbilligungsinformationen, Kompilierungs- und Projekteinstellungen, oder andere Details des Softwareentwicklungssystems. Metadaten können im JSON-, YAML-, XML-Format oder in einem allgemeinen domainspezifischen Sprachformat empfangen werden. Metadaten können durch Kennzeichen in einem an die Öffentlichkeit gerichteten Managementsystem für Source-Steuerung und statischen Zip-Dateien, die über HTTP bereitgestellt werden, empfangen werden. Artefakte und Metadaten können nur für unterstützte Versionen eines Softwareentwicklungssystems gespeichert werden. Ein Umwandlungsprozess kann bei einer Bedingung ausgelöst werden, wie etwa ein ausdrückliches Signal von einem Anbieter des Softwareentwicklungssystems, eine Erhebung des Status des Hosts für ein Softwareentwicklungssystem oder das Empfangen eines Signals vom Host für ein Softwareentwicklungssystem hinsichtlich einer Veränderung darstellt. Mit einem Befehlszeilentool oder einem anderen Weg des gegenseitigen Beeinflussens können Anbieter des Softwareentwicklungssystems dem Tester signalisieren, dass ein bestimmtes Softwareentwicklungssystem und Version davon für das Testen bereitsteht.
-
Die Einzelheiten von einer oder mehreren Ausführungsformen der Erfindung sind in den begleitenden Zeichnungen dargelegt, die der Veranschaulichung dienen, sowie in der nachstehenden Beschreibung. Andere Merkmale, Aspekte und Vorteile der Erfindung werden aus der Beschreibung, den Zeichnungen und den Ansprüchen deutlich. Entsprechende Referenznummern und Kennzeichnungen in den verschiedenen Zeichnungen zeigen entsprechende Elemente an.
-
KURZBESCHREIBUNG DER ZEICHNUNGEN
-
1 ist ein Blockdiagramm, das ein Beispielsystem für Hosting und Publishing von Softwareentwicklungspaketen darstellt.
-
2 ist ein Flussdiagramm, das ein Beispielverfahren für Hosting und Publishing von Softwareentwicklungspaketen darstellt.
-
3 ist ein Blockdiagramm zur Veranschaulichung eines Beispielcomputergeräts.
-
4 ist ein Blockdiagramm, das ein Beispielsystem zur Generierung von Softwareentwicklungssystemen illustriert.
-
5a ist ein Blockdiagramm, das ein Beispiel von Abhängigkeiten von Softwareentwicklungssystemen darstellt.
-
5b ist ein Blockdiagramm, das ein Beispiel von Abhängigkeiten von Softwareentwicklungssystemen darstellt.
-
AUSFÜHRLICHE BESCHREIBUNG
-
Gemäß einer exemplarischen Ausführungsform kann es ein System für Hosting und Publishing von Softwareentwicklungspakete geben, das Konflikte zwischen Softwareentwicklungssystemen löst und Softwareentwicklungssysteme in einem gebräuchlichen Format auf einem einzelnen Host zur Nutzung von Entwicklern bereitstellt.
-
Mit einem exemplarischen automatisierten System können Entwickler Softwareentwicklungssysteme für eine bestimmte Softwareplattform an einem Ort und in einem gebräuchlichen Format erhalten. Das exemplarische System kann die Softwareentwicklungssysteme auf Kompatibilität mit anderen Softwareentwicklungssystemen testen, die auf die Plattform installiert werden und die Softwareentwicklungssysteme in einem gebräuchlichen Format, das eine konsistente Paketstruktur und konsistente Komponenten für Entwickler zur Nutzung in ihren Applikationen bereitstellt, bereitstellen.
-
Ein exemplarisches System kann verschiedene Softwareentwicklungssysteme von einem Einzelstandort bereitstellen, der alle verfügbaren Softwareentwicklungssysteme hostet. Ein Beispielsystem, wie in 1 gezeigt, kann Informationen von einem Anbieter eines Softwareentwicklungssystems einschließlich Artefakte (101) und Metadaten (102) in Bezug auf ein bestimmtes Softwareentwicklungssystem aufnehmen und in ein Format umwandeln, das für Nutzer nutzbar ist. In einigen Ausführungsformen umfassen exemplarische Artefakte Informationen in Bezug auf ein bestimmtes Softwareentwicklungssystem wie etwa Änderungsprotokolle, Lizenzdateien, Ressourcen, Mediendateien, Musterprojekte, Quelldateien, kompilierte Binärdateien, Bibliotheken, die in einem komprimierten Format wie eine Zip-Datei sein können. Exemplarische Metadaten können Namen des Softwareentwicklungssystems, Versionierungsinformationen, Abhängigkeiten des Softwareentwicklungssystems, Beschreibungen, was das Softwareentwicklungssystem ausführt, die Verfasser eines Softwareentwicklungssystems, Kontaktinformationen für Verfasser eines Softwareentwicklungssystems, Lizenzinformationen, die offizielle Website für ein Softwareentwicklungssystem, Plattformanforderungen für das Softwareentwicklungssystem, (wie etwa ein Betriebssystem und CPU-Architektur), Screenshots, Befehle, die vor dem Integrieren des Softwareentwicklungssystems ausgeführt werden müssen, Missbilligungsinformationen, Kompilierungs- und Projekteinstellungen, oder andere Details des Softwareentwicklungssystems sein. Diese Informationen können von Anbietern eines Softwareentwicklungssystems dem exemplarischen System in vielen unterschiedlichen Formaten bereitgestellt werden: im JSON-, YAML-, XML-Format, in einem allgemeinen domainspezifischen Sprachformat (DSL) Es gibt vielfache Verfahren für das Senden dieser Dateien an das exemplarische System einschließlich Kennzeichen in einem an die Öffentlichkeit gerichteten Managementsystem für Source-Steuerung und statischen Zip-Dateien, die über HTTP bereitgestellt werden.
-
Ein Beispielsystem kann Artefakte (101) und Metadaten (102) empfangen, die eine Version des Softwareentwicklungssystems beschreiben und diese Informationen in einem allgemeinen Datenspeicher, dem Host für ein Softwareentwicklungssystem (103) speichern. Dieser Host für ein Softwareentwicklungssystem (103) kann jede Version jedes empfangenen und unterstützten Softwareentwicklungssystems aufbewahren. Versionen können unendlich aufbewahrt werden. In einer Ausführungsform kann ein Beispielsystem das Prinzip „unterstützte Versionen” von Paketen haben. Unterstützte Versionen stellen Versionen eines Softwareentwicklungssystems dar, die die Entwickler eines Softwareentwicklungssystems aktiv unterstützen. Softwareentwicklungssysteme können ihre Metadaten aktualisieren, um anzuzeigen, dass ihre Metadaten ohne Ersatz veraltet sind oder veraltet zu Gunsten eines anderen Softwareentwicklungssystems, das benannt wird. Sobald die Entwickler eine Version nicht mehr unterstützen, kann ein exemplarisches System Pakete für nicht unterstützte Softwareentwicklungssysteme entfernen. Das System kann dann die Informationen zu einem Wandler (104) senden, der die empfangenen Informationen in ein Paket mit den notwendigen Tools für den Entwicklungsprozess umwandelt. Ein exemplarischer Wandler (104) kann die empfangenen Artefakte (101) und Metadaten (102) dazu nutzen, um zu erkennen, wie eine Version eines bestimmten Softwareentwicklungssystems in ein Paket umgewandelt wird. So kann beispielsweise ein Artefakt eine Build-Datei sein, die alle notwendigen Komponenten des Softwareentwicklungssystems und die Reihenfolge beschreibt, in der bestimmte Dateien in ein Paket aufgenommen werden sollen.
-
In einem Beispiel werden alle notwendigen Dateien und Konfigurationen in einem Skript beschrieben, welches in 4 veranschaulicht ist. Dieses Komponentenskript (402) kann alle Dateien, die Teil einer Version eines Softwareentwicklungssystems sind, aufnehmen und in eine standardmäßige Dateihierarchie platzieren. Das Skript kann eine standardmäßige Konfigurationsdatei wie etwa eine JSON-Datei verwenden, um alle notwendigen Dateien und Build-Konfigurationen aufzulisten. Die folgenden Schlüsseldaten können für die Erstellung einer Version eines Softwareentwicklungssystems notwendig sein: Name, öffentlicher Name, Version, Zusammenfassung, Beschreibung und Homepage. Name kann der Name der Komponente sein, der der Stammverzeichnisname der Hierarchie sein wird. Öffentlicher Name kann der öffentliche Name sein, den das Beispielsystem benutzt, um das Softwareentwicklungssystem Nutzern anzuzeigen. Version kann die Version des Softwareentwicklungssystems sein, das gerade erstellt wird. Zusammenfassung kann eine kurze Beschreibung des Softwareentwicklungssystems sein, das gerade erstellt wird. Beschreibung kann eine längere Beschreibung des Softwareentwicklungssystems sein. Homepage kann die Website-URL des Softwareentwicklungssystems mit Projektinformationen und Dokumentation sein.
-
Ein weiteres Skript (404) kann neue Build-Konfigurationen für neue Komponenten (403) generieren und ein Kennzeichen für die neue Version des Softwareentwicklungssystems aktualisieren. Dieses Skript (404) kann die Konfiguration, die in den Build-Dateien/Konfigurationen gespeichert ist, bei den neuen Komponentendateien (403) nutzen, um die entsprechenden Metadaten und Build-Regeln zu generieren. Ein weiteres Skript (406) kann ein Versionsverzeichnis nehmen und in eine Archivdatei kompilieren, beispielsweise eine Cocoa Pod-Zipdatei für Datenweitergabe (407). Ein exemplarischer Wandler (104) kann durch eine Reihe von Bedingungen ausgelöst werden, wie etwa ein ausdrückliches Signal von einem Anbieter des Softwareentwicklungssystems, eine Erhebung des Status des Hosts (103) für ein Softwareentwicklungssystem oder das Empfangen eines Signals vom Host (103) für ein Softwareentwicklungssystem hinsichtlich einer Veränderung. Daten im Hosts für ein Softwareentwicklungssystem kann im strukturieren Format sein, damit eine schnelles Prüfen des Softwareentwicklungssystems und Kombinationen von Versionen möglich ist. In einem exemplarischen System kann dieses Format eine Verzeichnisstruktur in einer Source-Steuerung des Formats des Softwareentwicklungssystems/der Version sein. Beim Erheben kann eine Liste von Paaren von Softwareentwicklungssystemen und Versionen generiert werden. Diese Liste kann mit einem Satz von Paaren, die bereits konvertiert wurden, verglichen werden, um die Versionen des Softwareentwicklungssystems zu bestimmen, die konvertiert werden sollen. In anderen Ausführungsformen kann das exemplarische System alles im Hosts für ein Softwareentwicklungssystem in einem bestimmten Zeitraum konvertieren.
-
Sobald die Umwandlung einer bestimmten Version eines Softwareentwicklungssystems fertig gestellt wurde, kann das Paket zu einem Staginghost (105) gebracht werden. Abhängigkeiten sollten zu diesem Zeitpunkt geprüft werden. Das exemplarische System überprüft, um sicherzustellen, dass alle Abhängigkeiten existieren und die richtigen Versionen der Abhängigkeiten verfügbar sind. Falls die Abhängigkeiten nicht existieren und die richtigen Versionen nicht verfügbar sind, verbleibt das Paket beim Staginghost (105), bis die Abhängigkeiten verfügbar und korrigiert sind. Konflikte unter Softwareentwicklungssystemen sollten zu diesem Zeitpunkt auch gelöst werden. Mehrfache Softwareentwicklungssysteme können möglicherweise aufbereitet werden, wobei jedoch Abhängigkeiten zuerst aufbereitet werden. Konfliktlösung kann ein manueller Prozess zu diesem Zeitpunkt sein, da dies sehr wahrscheinlich durch einen logischen Fehler verursacht wird, der nicht mittels eines Programms behoben werden kann. Ein Beispielsystem kann die Eigentümer über Konflikte unter Softwareentwicklungssystemen mit so vielen Informationen über den Fehler, wie soweit möglich ist, benachrichtigen.
-
Ein Tester (106) kann zur Weiterleitung der Pakete vom Staginghost (105) zum Pakethost (107) verwendet werden. In einem Beispielsystem kann ein Tester (106) die derzeit aufbereiteten Pakete holen und diese testen. Dieser Tester (106) kann durch den Wandler (104), den Staginghost (105), einen Anbieter eines Softwareentwicklungssystems, oder über einen Erhebungsmechanismus ausgelöst werden. Gemäß exemplarischen Ausführungsformen wird nach Beendigung der Umwandlung der Standort des neuen Pakets im Staginghost entweder durch den Wandler (104) oder dem Staginghost (105) zum Tester gesendet. In anderen Ausführungsformen kann es ein Befehlszeilentool oder einen anderen Weg des gegenseitigen Beeinflussens geben, sodass Anbieter des Softwareentwicklungssystems dem Tester (106) signalisieren können, dass ein bestimmtes Softwareentwicklungssystem und Version davon beim Staginghost bereitsteht, und Testen benötigt. Testen kann das Erstellen einer Applikation mit aufbereiteten Paketen und relevanten verfügbaren Paketen umfassen, um sicherzustellen, dass es keine Build-Probleme gibt. Der Service kann auch die Ausführung von besser entwickelten Integrationstests unterstützen, d. h. sicherstellen, dass die Applikationsfunktionalität, die von unterschiedlichen Softwareentwicklungssystemen abhängt, funktioniert. Ein exemplarisches System kann einen aus Komponenten bestehenden Satz von Tests bereitstellen. Dies können auch Voreinreichungstests, Integrationstests, Installationen vor Verpackung auf Hostinfrastrukturinstanzen, die Quellenarchive und Dateien [] bedienen und Validierungen für Build-Regeln sein. Wenn eine Version eines Softwareentwicklungssystems erstellt oder aktualisiert wird, kann das Konfigurationsskript validiert werden, um sicherzustellen, dass es gültige Parameter mit den folgenden Eigenschaften enthält: richtige öffentliche Namen, richtig ausgewiesene Abhängigkeiten; kürzere Zusammenfassungen als die Beschreibungen; eine spezifische Version einer Mindest-Plattform und eine gültige Homepage. Des Weiteren können die Bibliotheken für spezifische Architekturen validiert werden. Veränderungen der Umweltspezifikationen für ein Softwareentwicklungssystem können geprüft werden, um zu bestätigen, dass die aktualisierte Umweltspezifikation installierbar und validiert ist. So kann beispielsweise die Validierung eine Voreinreichungsprüfung umfassen, um zu garantieren, dass alle spezifischen Pakete von Dateien, die eine Version haben, gespeichert sind und ein Zugriff vom Beispielsystem existiert, um zu bestätigen, dass die Kollektion der spezifischen Pakete von Dateien eine gültige/konsistente Kollektion ist und eine Testinstallation auf einer örtlichen Maschine erfolgt, um festzustellen, ob ein Softwareentwicklungssystem installieren wird. Nachdem ein Softwareentwicklungssystem erfolgreich installiert wurde, können fortdauernde Integrationstests eingerichtet und mit Musterprojekten ausgeführt werden und Interoperabilitätstests, um festzustellen, ob die Kompatibilität unter Softwareentwicklungssystemen auf der gleichen Entwicklungsplattform installiert wird. Nachdem das Paket getestet wurde, kann es zum Pakethost (107) befördert werden. Zugriffssteuerungsinformationen können bereitgestellt werden, die steuern, wie das Paket zugreifbar werden soll. Der Pakethost (107) kann diese Zugriffssteuerungsinformationen erhalten, sodass der Pakethost (107) Pakete den entsprechenden Nutzern bereitstellen kann. Zugriffssteuerungsinformationen können als Teil der Metadaten bereitgestellt werden oder können vom Anbieter des Softwareentwicklungssystems signalisiert werden. In einer Ausführungsform können unterschiedliche Standorte innerhalb der Hostinfrastruktur die Zugriffskontrollliste für eine Paket bestimmen. Es können dem Anbieter des Softwareentwicklungssystems Tools bereitgestellt werden, um das Paket an den richtigen Standort für spezifische Zugriffskontrolllisten zu senden. So können beispielsweise Zugriffskontrollregeln implementiert werden, die IP-Adressen verwenden, um festzustellen, ob ein Nutzer oder eine Applikation auf ein spezifisches Softwareentwicklungssystem zugreifen kann. Es können private, halb-private und extern zugreifbare Pakete existieren. Wie in 1 gezeigt wird, können intern gehostete Pakete (108) privat, mit Frühzugriffsprogramm gehostete Pakete (109) halb-privat und öffentlich gehostete Pakete (110) extern zugreifbar für öffentliche Nutzer sein. Ein Paket, das zu zusätzlichen Nutzern/Applikationen gesendet werden kann, kann im Staginghost gecached sein, sodass es nicht zu späterer Zeit erneut in ein Paket umgewandelt werden muss.
-
Wie bereits erörtert wurde können Pakete in einem gebräuchlichen Format wie etwa Cocoa Pods und als unterstützte Zip-Dateien bereitgestellt werden, wie in 4 für Beispiel (407) gezeigt wird. Cocoa Pods sind Mechanismen für Bibliotheksverteilungen und Abhängigkeitslösungen, die jüngst sehr beliebt bei iOS-Entwicklern geworden sind. Mit diesen Mechanismen können in einem vereinfachten automatisierten Arbeitsfluss Bibliotheken und ihre Abhängigkeiten abgerufen werden. Sie erzwingen auch eine semantische Versionierung von Bibliotheken. Ein Entwickler verwendet Cocoa Pods und listet die Bibliotheken, die sie direkt nutzen wollen und verwandte Versionierungsinformationen in einer Podfile. Diese Datei kann von den Cocoa Pod-Tools genutzt werden, um Bibliotheken und ihre Abhängigkeiten abzurufen.
-
In einigen Ausführungsformen kann es keinen Staginghost geben. Abhängigkeitslösungen können im Host für ein Softwareentwicklungssystem gemacht werden. Softwareentwicklungssysteme können auch als Version gestapelt werden. Falls Softwareentwicklungssysteme gestapelt werden, kann das Prüfen der Abhängigkeit nicht im Wandler oder im Tester stattfinden. Anbieter können verantwortlich dafür sein, nur Sätze von neuen Softwareentwicklungssystemen abzusenden, die richtige Abhängigkeiten aufweisen. Mit Stapeln kann ein exemplarisches System vermeiden, dass Pakete im Staginghost sitzen und auf ihre Abhängigkeiten warten. Stattdessen müssen Pakete bereits ihre Abhängigkeiten eingebettet haben, oder werden mit ihren Abhängigkeiten gestapelt. Diese Voraussetzung kann etwas der Logik in einem exemplarischen System vereinfachen.
-
Ein exemplarisches Verfahren für Hosting und Publishing von Softwarepaketen beginnt mit dem Empfangen von Artefakten und Metadaten, die eine Version von einem Softwareentwicklungssystem (201) beschreiben. Die empfangenen Artefakte und Metadaten können dann in ein Paket (203) umgewandelt werden. Die Abhängigkeiten des Pakets können geprüft werden, um sicherzustellen, dass alle Abhängigkeiten verfügbar sind und ob Konflikte unter Softwareentwicklungssystemen existieren. (205). Dann kann das Paket getestet werden, um sicherzustellen, dass es keine Konflikte gibt, d. h. Build-Konflikte unter Softwareentwicklungssystemen. (207). Das Paket kann dann in einem gebräuchlichen Format für die angemessenen Nutzer bereitgestellt werden. (208) Die angemessenen Nutzer können bestimmt werden, indem mit dem Softwareentwicklungssystem verbundene Zugriffskontrollregeln geprüft werden.
-
Ein Beispielsystem kann vielen nützlichen Zwecken dienen. Wie in 5a gezeigt wird, kann es eine Applikation geben, mit der Nutzer einen Eintrag darüber machen, wo sie Interaktionen mit Leuten hatten, wie etwa ein Konzert. Die Applikation kann ConcertTracker (501a) genannt werden und benötigt Zugriff auf ein Landkarten-Softwareentwicklungssystem (502a) und ein Sozial-Softwareentwicklungssystem (503a) für Standortinformationen und Informationen über Freunde eines Nutzers. Mit dem ConcertTracker (501a) kann ein Nutzer Informationen mit den Freunden des Nutzers über das Sozial-Softwareentwicklungssystem (503a) teilen. Diese Softwareentwicklungssysteme (502a, 503a) können beide von einem dritten Softwareentwicklungssystem (504a1, 504a2) abhängen, mit dem Analytikinformationen berichtet werden können. Falls das Landkarten-Softwareentwicklungssystem (502a) aktuell die 6.x(504a1)-Version des Analytik-Softwareentwicklungssystems und das Sozial-Softwareentwicklungssystem (503a) die 7.x(504a2)-Version des Analytik-Softwareentwicklungssystems nutzt, dann kann es keine gemeinsame Version des Softwareentwicklungssystems geben, die die für beide benötigten Programmierschnittstellen liefert. Des Weiteren können beide Softwareentwicklungssysteme (502a, 503a) die gleiche Open-Source-Bibliothek (505a1, 505a2) für Datenaufzeichnung für die Entwickler nutzen, falls etwa eine Applikation abstürzt. Falls die Bibliothek in jedem Softwareentwicklungssystem kompiliert ist, ohne die Symbole erneut zu benennen, dann kann das Erstellen einer Applikation, die von dem Landkarten-Softwareentwicklungssystem (502a) und dem Sozial-Softwareentwicklungssystem (503a) abhängt, wegen der doppelten Symbole scheitern. Um das Problem zu beseitigen, kann ein Beispielsystem, wie in 5b gezeigt, ein Paket erstellen, das die Bibliothek (505b) enthält und macht das Landkarten-Softwareentwicklungssystem (502b) und das Sozial-Softwareentwicklungssystem (503b) von dem erstellten Paket abhängig, sodass der Abhängigkeitsmanager nur eine Kopie der Open-Source-Bibliothek (505b) einholt.
-
3 ist ein Blockdiagramm auf hoher Ebene eines exemplarischen Computers (300), der für Hosting und Publishing von Softwarepaketen eingerichtet ist. In einer sehr grundlegenden Konfiguration (301) beinhaltet das Rechengerät (300) typischerweise einen oder mehrere Prozessoren (310) und einen Systemspeicher (320). Ein Speicherbus (330) kann für die Kommunikation zwischen dem Prozessor (310) und dem Systemspeicher (320) verwendet werden.
-
Je nach der gewünschten Konfiguration kann es sich bei dem Prozessor (310) um einen beliebigen Typ handeln, einschließlich unter anderem um einen Mikroprozessor (μP), einen Mikrocontroller (μC), einen digitalen Signalprozessor (DSP) oder eine Kombination dieser Prozessoren. Der Prozessor (310) kann ein- oder mehrstufiges Caching, zum Beispiel einen Cache der Stufe 1 (311) und einen der Stufe 2 (312), einen Prozessorkern (313) sowie Register (314) umfassen. Der Prozessorkern (313) kann eine arithmetische Logikeinheit, eine Gleitkommaeinheit, einen Digitalsignalverarbeitungskern oder eine beliebige Kombination davon umfassen. Eine Speichersteuerung (316) kann ebenfalls mit dem Prozessor (310) verwendet werden, oder in einigen Implementierungen kann die Speichersteuerung (315) ein interner Teil des Prozessors (310) sein.
-
Abhängig von der gewünschten Konfiguration kann der Systemspeicher (320) jeglichen Typs sein, einschließlich, jedoch nicht beschränkend auf flüchtige Speicher (wie RAM), nicht flüchtige Speicher (wie ROM, Flash-Speicher usw.) oder jegliche Kombination hiervon. Ein Systemspeicher (320) umfasst typischerweise ein Betriebssystem (321), eine oder mehrere Applikationen (322) und Programmdaten (324). Die Applikation (322) kann ein Verfahren für Hosting und Publishing von Softwarepaketen umfassen. Programmdaten (324) enthalten das Speichern von Anweisungen, die, wenn sie von der einen oder mehreren Verarbeitungsvorrichtungen ausgeführt werden, ein Verfahren für Hosting und Publishing von Softwarepaketen implementieren. (323). In einigen Ausführungsformen kann die Applikation (322) so eingerichtet werden, um mit Programmdaten (324) auf einem Betriebssystem (321) zu arbeiten.
-
Das Rechengerät (300) kann zusätzliche Merkmale oder Funktionalitäten und zusätzliche Schnittstellen aufweisen, um die Kommunikation zwischen der Grundkonfiguration (301) und allen erforderlichen Geräten und Schnittstellen zu erleichtern.
-
Der Systemspeicher (320) ist ein Beispiel eines Computerspeichermediums. Computerspeichermedien umfassen Folgendes, ohne jedoch darauf beschränkt zu sein: RAM, ROM, EEPROM, Flash-Speicher oder eine andere Speichertechnologie, CD-ROM, DVD oder einen anderen optischen Speicher, Magnetkassette, Magnetband, Magnetdiskspeicher oder andere Magnetspeichergeräte sowie weitere Medien, die zur Speicherung der gewünschten Daten benutzt werden können und auf die das Computergerät (300) zugreift. Jedes derartige Rechenspeichermedium kann Teil des Geräts (300) sein.
-
Die Rechengerät (300) kann als ein Teil eines Mobilgeräts mit kleinem Formfaktor, wie beispielsweise eines Mobiltelefons, eines Smartphones, eines PDA (Minicomputer), eines persönlichen Mediaplayers, eines Tablet-Computer (Tablet), eines drahtlosen Webgeräts, eines persönlichen Headset-Geräts, eines anwendungsspezifischen Geräts oder eines Hybrid-Geräts implementieren werden, dass eine der oben genannten Funktionen umfasst. Das Rechengerät (300) kann auch als ein Personalcomputer implementiert werden, der Konfigurationen von tragbaren Rechnern und nicht tragbare Rechnern umfasst.
-
Die vorangegangene detaillierte Beschreibung legt verschiedene Ausführungsformen der Geräte und/oder Prozesse über die Nutzung von Blockdiagrammen, Flowcharts und/oder Beispiele dar. Insoweit wie solche Blockdiagramme, Flowcharts und/oder Beispiele eine oder mehrere Funktionen und/oder Operationen beinhalten, versteht es sich in der Fachwelt, das jede Funktion und/oder Operation mit solchen Blockdiagrammen, Flowcharts oder Beispielen implementiert werden können, individuell und/oder kollektiv, durch ein weites Angebot von Hardware, Software, Firmware der irgendeiner virtuellen Kombination davon. In einer Ausführung können verschiedene Bestandteile des hier beschriebenen Themas über anwendungsspezifische, integrierte Schaltkreise (ASICs), feldprogrammierbare Gate-Arrays (FPGAs), digitale Signalprozessoren (DSPs), sonstige integrierte Formate oder als Webservice enthalten. Dennoch werden die Fachkundigen feststellen, dass einige Aspekte der hier dargelegten Ausführungen, teilweise oder gänzlich, ebenso in integrierten Kreisläufen implementiert werden können, als ein oder mehrere Computerprogramme, die auf einem oder mehreren Computern ausgeführt werden, als ein oder mehrere Programme, die auf einem oder mehreren Prozessoren ausgeführt werden, als Firmware oder irgend eine Kombination davon; und dass ein Entwurf der Schaltkreise und/oder des Schreibens des Codes für die Software und/oder Firmware unter Berücksichtigung der vorliegenden Veröffentlichung der Fachwelt kundig ist. Außerdem werden Fachleute verstehen, dass die Mechanismen dieses hier beschriebenen Gegenstands in der Lage sind, als ein Programmprodukt in einer Vielzahl von Formen verteilt zu werden, und dass eine veranschaulichende Ausführungsform des hier beschriebenen Gegenstands unabhängig von der besonderen Art des nicht-flüchtigen signalführenden Mediums gilt, das für die tatsächliche Verteilung verwendet wird. Beispiele für ein nicht transitorisches Signal tragenden Mediums umfassen, ohne Einschränkung darauf, Folgendes: Floppy Disk, Festplattenlaufwerk, CD (Compact Disc), DVD (Digital Video Disk), digitales Band, Computerspeicher usw.; sowie ein Medium des Übertragungstyps, wie beispielsweise ein digitales und/oder analoges Kommunikationsmedium. (z. B. ein Glasfaserkabel, ein Wellenleiter, eine kabelgebundene Kommunikationsverbindung, eine kabellose Kommunikationsverbindung usw.)
-
Was die Nutzung von im Wesentlichen allen Mehrzahl- und/oder Einzahlbegriffen hierin betrifft, können die Experten je nach Eignung für den Kontext und/oder die Anwendung die Mehrzahlform zur Einzahlform und umgekehrt bilden. Die verschiedenen Singular-/Plural-Permutationen können hierin ausdrücklich aus Gründen der Klarheit dargelegt.
-
Folglich wurden bestimmte Ausführungsformen des Gegenstands beschrieben. Weitere Ausführungsformen gehören zum Umfang der folgenden Ansprüche. In einigen Fällen können die in den Ansprüchen beschriebenen Handlungen in einer anderen Reihenfolge ausgeführt werden und dennoch erwünschte Ergebnisse erzielen. Zusätzlich erfordern die in den beigefügten Figuren dargestellten Prozesse nicht notwendigerweise die bestimmte gezeigte Reihenfolge oder aufeinander folgende Reihenfolge, um erwünschte Ergebnisse zu erzielen. In bestimmten Implementierungen können Multitasking und eine Parallelbearbeitung vorteilhaft sein.
