DE112016002003T5 - INFRASTRUCTURE FOR POSING AND PUBLISHING SOFTWARE PACKAGES - Google Patents

Abstract

It discloses a system and method for hosting and publishing software packages. An exemplary method includes: receiving and storing artifacts associated with a software development kit and metadata describing a version of the software development kit (201). The received artifacts and metadata can be converted into a package for the Software Development Kit (203). The package can then be prepared and the dependencies of the package can be checked to ensure that the dependencies of the package exist and there are no conflicts with another rendered package (205). The currently parsed packets may then be tested to determine if there are any incompatibilities of the parsed packets with each other, and access control information may be used to provide the currently parsed packets to the appropriate users (207, 208).

Description

GENERAL PRIOR ART

In recent years, software engineers have focused on building applications on a variety of platforms, such as iOS, Android, Windows Phone, BlackBerry, and Firefox OS. These applications often use software development kits (SDKs) that provide users with access to data and functionality such as maps, e-mail, messages, and social networking information. A software development kit (SDK) may include a set of software development tools, libraries, documentation, header files, and templates that can be used to develop applications for a particular development platform with specific functionality specified in the SDK. SDKs can include application programming interfaces (APIs) so that software developers can have controlled access to processes and data from other applications or services, such as web services.

For example, an SDK provider may develop a map service and provide a map API to allow software developers to access the functionality of the map service. The Map SDK may include sample code, libraries, and documentation about how card functionality should be used. The Map API may contain information about the map service including procedures to obtain: directions to a location, travel distance between locations, travel time between locations, and elevation of a location. When a software developer develops an application for a fast food restaurant, the software developer may want to use the map API to allow a user to retrieve directions to the restaurant from the user's current location. The developer does not need to write specific code for maps to obtain the directions, but instead can use the map API to access the functionality of the map web service and obtain directions.

Typically, each SDK development team has an end-to-end release process that is completely independent of other SDK development teams. These separate release processes can lead to various problems. For example, individual SDKs can be provided in a variety of formats, resulting in inconsistent package structures and components available to developers. Developers then need to know how to handle each particular format. Another problem is the minimal, if any, compatibility check of SDKs among themselves. Because each SDK development team releases its own SDK, each team only tests its own SDK, without considering other SDKs that can be used on the same development platform. Failure to test SDKs among themselves can lead to binary incompatibilities between developed SDKs because SDKs may be dependent on the same dependency but use different versions of the dependency. Another problem arises because there is currently no way to provide consistent documentation about an SDK, including how to use a specific SDK in a development project. Furthermore, there is no coordination of external messaging among exposed SDKs for a particular software platform.

As the inventors have realized, there should be an automated system that provides an end-to-end release process for SDKs so that SDKs can be released in conjunction with other SDKs.

SUMMARY

This specification describes technologies that affect the hosting and publishing of software packages.

In general, aspects of the subject matter described in this specification may be embodied in computer-implemented methods and systems. An exemplary system includes one or more processing devices and one or more storage devices that store instructions that, when executed by the one or more processing devices, cause the one or more processing devices to implement an example method. An exemplary method includes: receiving and storing artifacts associated with a software development kit and metadata describing the version of the software development kit; Converting the received artifacts and metadata into a package for the Software Development Kit; Parsing the package and checking all dependencies of the package to ensure that the dependencies of the package exist and there are no dependency conflicts with another parsed package; Test the packages currently being rendered to see if there are any incompatibilities of the rendered packages with each other, and use access control information to provide the currently processed packages in a common format for the appropriate users.

Another exemplary system for hosting and publishing software packages includes: an SDK host that receives and stores artifacts associated with a software development kit and metadata that describes the version of the software development kit; a converter that converts the received artifacts and metadata into a software development kit package; a staging host that parses the package and checks all dependencies to ensure that the dependencies of the package exist and that there are no dependency conflicts with any other parsed package; a tester that retrieves and tests the packages currently being processed to determine if there are any incompatibilities between the processed packages; a package host that receives the currently processed packages from the tester and uses access control information to provide the currently processed packages in a common format for appropriate users.

These and other embodiments may optionally include one or more of the following features. Artifacts can include: change logs, license files, resources, media files, sample projects, source files, compiled binaries, libraries, and other information related to a specific SDK. Artifacts can be received in a compressed format. Metadata may include: the name of the SDK, versioning information, SDK dependencies, descriptions of the function that an SDK meets, the authors of an SDK, contact information for SDK authors, licensing information, the official website for an SDK, SDK platform requirements, screenshots, Commands that need to be executed before integrating the SDK, disapproval information, compilation and project settings, or other details of the SDK. Metadata can be received in JSON, YAML, XML format, or in a custom domain-specific language format. Metadata can be received through tags in a publicly accessible source control management system and as static zip files provided over HTTP. Artifacts and metadata can only be saved for supported versions of an SDK. A conversion process may be triggered under a condition such as an explicit signal from the SDK provider, an elevation of the status of the SDK host, or a receipt of a signal from the SDK host for a change. A command-line tool or other means of interacting may allow SDK offerers to signal that a specific SDK and version of it is ready for testing.

The details of one or more embodiments of the invention are set forth in the accompanying drawings, which are given by way of illustration only, and in the description which follows. Other features, aspects and advantages of the invention will become apparent from the description, the drawings and the claims. Like reference numbers and labels in the various drawings refer to like elements.

BRIEF DESCRIPTION OF THE DRAWINGS

1 Figure 12 is a block diagram illustrating an exemplary system for hosting and publishing software development kits.

2 Figure 13 is a flowchart illustrating an exemplary method of hosting and publishing software development kits.

3 FIG. 10 is a block diagram illustrating an exemplary computing device. FIG.

4 Figure 13 is a block diagram illustrating an exemplary system for generating SDKs.

5a Figure 12 is a block diagram illustrating an example of SDK dependencies.

5b Figure 12 is a block diagram illustrating an example of SDK dependencies.

DETAILED DESCRIPTION

According to an exemplary embodiment, there may be a system for hosting and publishing software development kits that resolves conflicts between SDKs and provides SDKs in a common format on a single host page for developers to use.

An exemplary automated system may allow developers to obtain SDKs for a particular software platform in a single location and in a common format. The exemplary system may test the SDKs for compatibility with other SDKs deployed on the platform and provide the SDKs in a common format that includes a consistent package structure and provides developers with consistent components for use in their applications.

An example system can provide various SDKs from a single site that hosts all available SDKs. An exemplary system, as in 1 can show information from an SDK provider, including artifacts ( 101 ) and metadata ( 102 ), in the context of a particular SDK record and the information provided in a Convert format that is useful for users. In some embodiments, exemplary artifacts include information associated with a particular SDK, such as change logs, license files, resources, media files, sample projects, source files, compiled binaries, and libraries, which may be in a compressed format such as a zip file. Exemplary metadata can include the name of the SDK, versioning information, SDK dependencies, descriptions of the function that an SDK meets, the authors of an SDK, contact information for SDK authors, licensing information, the official website for an SDK, SDK platform requirements (such as operating system and CPU architecture), screenshots, commands that need to be executed before integrating the SDK, disapproval information, compilation and project settings, or other details of the SDK. This information may be provided by SDK developers for the exemplary system in a variety of different formats, including: JSON, YAML, XML, or a custom domain-specific language format (DSL). There may be a variety of methods for sending these files to an exemplary system, including tags in a publicly accessible source control management system and static zip files provided over HTTP.

An exemplary system can detect artifacts ( 101 ) and metadata ( 102 ) that describe a version of an SDK, and receive that information in a common data store, the SDK host ( 103 ) to save. This SDK host ( 103 ) can keep any version of any received and supported SDK. Versions can be stored indefinitely. In one embodiment, an exemplary system may have the "supported version" principle of packets. Supported versions represent versions of an SDK that the SDK developers actively support. SDKs can update their metadata to indicate that their metadata is obsolete without replacement or obsolete in favor of another SDK that is named. Once the developers no longer support a version, an example system can remove packages for the unsupported SDKs. The system can then send the information to a converter ( 104 ), where the received information is converted into a package containing the tools necessary for the development process. An exemplary converter ( 104 ) can receive the received artifacts ( 101 ) and metadata ( 102 ) to see how to convert a version of a particular SDK into a package. For example, one of the artifacts may be a build file that describes all of the required components of the SDK and the order in which special files are to be included in a package.

In one example, all necessary files and configurations may be described in a script, as in FIG 4 shown. This component script ( 402 ) can capture all files that are part of an SDK version and place them in a standard directory hierarchy. The script can use a standard configuration file, such as a JSON file, to list all necessary files and build configurations. The following key data may be required to create an SDK version: name, public name, version, abstract, description, and homepage. Name can be the name of the component, which will be the root directory name of the hierarchy. Public name can be the public name that the example system will use to display the SDK to users. Version can be the version of the SDK that is being created. Summary can be a brief description of the SDK being created. Description may be a longer description of the SDK. Homepage can be the website URL of the SDK with project information and documentation.

An additional script ( 404 ) can create new build configurations for new components ( 403 ) and update a tag for the new SDK version. This script ( 404 ) can save the configuration (s) stored in the build files in the new component files ( 403 ) to generate the appropriate metadata and build rules. Another script ( 406 ) can take a version directory and compile it into an archive file, such as a CocoaPod zip file for distribution ( 407 ). An exemplary converter ( 104 ) can be triggered by a number of conditions, including an explicit signal from the SDK provider, a survey of the status of the SDK host ( 103 ) or receiving a signal from the SDK host ( 103 ) with regard to a change. Data in the SDK host can be in a structured format that allows for quick checking of SDK and version combinations. In an exemplary system, this format may be a directory structure in source control of the SDK / version format. When querying, a list of SDK and version pairs can be generated. This list can be compared to the set of pairs that have already been converted to determine SDK / versions to be converted. In other embodiments, the exemplary system may transform everything in the SDK host based on a particular schedule.

Once the conversion of a particular version of an SDK has been completed, the package can be delivered to a staging host ( 105 ). Dependencies can be checked at this time. An exemplary system checks to make sure that all dependencies exist and the right versions of dependencies are available. If the dependencies do not exist or the correct version is not available, the package remains with the staging host ( 105 ) until the dependencies are available and corrected. Conflicts among the SDKs can also be resolved at this time. Multiple SDKs may be able to be rendered, but dependencies are treated first. Conflict resolution can be a manual process at this time, as it is most likely caused by a logical error that can not be fixed programmatically. An exemplary system can notify the owner of conflicting SDKs with as much information about the error as possible.

A tester ( 106 ) can be used to propagate packets from the staging host ( 105 ) to the parcel post ( 107 ) be used. In an exemplary system, a tester ( 106 ) retrieve the currently processed packages and test them. This tester ( 106 ) can by the converter ( 104 ), the staging host ( 105 ), an SDK provider, or a polling mechanism. In some embodiments, after completion of the conversion, the location of the new packet in the staging host is determined either by the converter ( 104 ) or the staging host ( 105 ) sent to the tester. In other embodiments, there may be a command-line tool or other interaction facility that allows SDK providers to provide the tester ( 106 ) to signal that a special SDK and version of it is present in the staging host and needs to be tested. Testing can include building an application with rendered packages and the relevant packages available to make sure that there are no build issues. The service can also support the execution of more sophisticated integration tests, that is, ensure that the application functionality that depends on different SDKs works. An exemplary system may provide a component set of tests. These may include pre-submission tests, integration tests, pre-packaging operations on host infrastructure instances that serve source archives and files [], and build rule validations. When an SDK version is created or updated, the configuration script can be validated to ensure that it can contain valid parameters with the following properties: correct public names, correct dependencies; shorter summaries than the description; a specified minimum version of a platform; and a valid homepage. Furthermore, the libraries can be validated for specific architectures. Changes to the environmental specifications for an SDK can be checked to confirm that the updated environment specification is executable and validated. For example, the validation may include a pre-submission check to guarantee that all specified packages of files that are versioned are stored and accessed by the exemplary system, confirm that the collection of the specified packages of files is a valid one. contain a consistent collection, and a test installation on a local machine can be performed to determine if the SDK will be executed. After an SDK has been successfully completed, continuous integration testing can be set up and performed with sample projects and interoperability tests to establish compatibility between the SDKs running on the same development platform. Once a package has been tested, it can be used to package 107 ). Access control information may be provided that controls how the package is to be accessed. The package host ( 107 ), this access control information can be provided so that the package host ( 107 ) Can provide packages for the appropriate users. Access control information may be provided as part of the metadata or may be signaled by the SDK provider. In one embodiment, different locations within the hosting infrastructure may determine the access control (ACL) for a packet. Tools can be provided to the SDK provider to send a package to the correct location for specific ACLs. For example, access control rules that use IP addresses can be implemented to determine if a user or application can access a specific SDK. Private, semi-private and externally accessible packages may exist. As in 1 illustrates internally hosted packets ( 108 ) private, packages hosted with early access program ( 109 ) semi-private and publicly hosted packages ( 110 ) be externally accessible to public users. A packet that can be sent to additional users / applications can be cached in the staging host so that it does not need to be re-packetized at a later time.

As discussed above, packets may be provided in a common format such as CocoaPods and as supported zip files, such as in 4 for example ( 407 ). CocoaPods are library distribution and dependency resolution mechanisms that have recently become popular among iOS developers. These mechanisms allow one Simplified automated workflow for retrieving libraries and their dependencies. In addition, they force a semantic versioning of libraries. A developer using CocoaPods captures the direct-use libraries and related versioning information in a podfile. This file can be used by the CocoaPod tools to retrieve the libraries and their dependencies.

In some embodiments, there may not be a staging host. The dependency resolution can be done in the SDK host. In addition, SDKs can be stacked as a version. When SDKs are stacked, the dependency check does not necessarily have to be done in the converter or in the tester. Providers may be responsible for sending only sets of new SDKs that have proper dependencies. Stacking can help an exemplary system avoid packages from being in the staging host and waiting for dependencies. Instead, packages must either have dependencies already embedded or be stacked with their dependencies. This requirement may simplify some of the logic in an exemplary system.

An exemplary method for hosting and publishing software packages begins by receiving artifacts and metadata that is a version of an SDK ( 201 ). The received artifacts and metadata can then be put into a package ( 203 ) being transformed. The dependencies of the package can be checked to see if all dependencies are available or if there are conflicts with other SDKs. ( 205 ). Then the package can be tested to make sure that there are no conflicts, ie build conflicts, between the SDKs. ( 207 ). The package can then be provided in a common format for the appropriate users. ( 208 ) The appropriate users can be determined by checking access control rules associated with the SDK.

An exemplary system can serve many useful purposes. Such as in 5a There may be an application that allows users to create an entry about where they had interactions with people, such as at a concert. The application can use ConcertTracker ( 501 ) and access to a map SDK ( 502a ) and a social SDK ( 503a ) to obtain location information and information about a user's friends. ConcertTracker ( 501 ) can also enable a user to use the social SDK ( 503a ) Sharing information with the user's friends. These SDKs ( 502a . 503a ) can both be from a third SDK ( 504a1 . 504a2 ) with which analytics information can be reported. If the map SDK ( 502a ) currently version 6.x ( 504a1 ) of the Analytics SDK, and the Social SDK ( 503a ) version 7.x ( 504a2 ) of the Analytics SDK, then there may not be a common version of the SDK that provides the APIs needed for both. Furthermore, both SDKs ( 502a . 503a ) the same open-source library ( 505a1 . 505a2 ) for recording information for the developer, e.g. For example, when an application crashes. If the library is compiled into each SDK without renaming the icons, then creating an application that can be used by the map SDK ( 502a ) and the social SDK ( 503a ), due to the double symbols fail. To solve this problem, an exemplary system, as in 5b shown, create a package that the library ( 505b ) and ensure that both the map SDK ( 502b ) as well as the social SDK ( 503b ) depend on the created package, so the dependency manager will only have one copy of the open source library ( 505b ).

3 is a high-level block diagram of an exemplary computer ( 300 ), which is set up to host and publish software packages. In a very basic configuration ( 301 ) contains the computer device ( 300 ) typically one or more processors ( 310 ) and a system memory ( 320 ). A memory bus ( 330 ) can be used for communication between the processor ( 310 ) and the system memory ( 320 ) be used.

Depending on the desired configuration, the processor ( 310 ) may be of any type, including, but not limited to, a microprocessor (μP), a microcontroller (μC), a digital signal processor (DSP), or any combination thereof. The processor ( 310 ) one or more caching levels, for example a level 1 cache ( 311 ) and a level 2 cache ( 312 ), a processor core ( 313 ) and registers ( 314 ). The processor core ( 313 ) may include an arithmetic logic unit (ALU), a floating point unit (FPU), a digital signal processing core (DSP core), or any combination thereof. A memory controller ( 316 ) can also be used with the processor ( 310 ), or in some implementations, the memory controller ( 315 ) an internal part of the processor ( 310 ) be.

Depending on the desired configuration, the system memory ( 320 ) may be of any type, including but not limited to volatile memory (such as RAM), nonvolatile memory (such as ROM, flash memory, etc.), or a combination thereof. One System memory ( 320 ) typically includes an operating system ( 321 ), one or more applications ( 322 ) and program data ( 324 ). The application ( 322 ) may include a method for hosting and publishing software packages. Program data ( 324 ) include storing instructions that, when executed by the one or more processing devices, implement a method for hosting and publishing software packages. ( 323 ). In some embodiments, the application may ( 322 ) be designed with program data ( 324 ) on an operating system ( 321 ) to work.

The computer device ( 300 ) may have additional features or functionalities and additional interfaces to facilitate communication between the basic configuration ( 301 ) and all necessary equipment and interfaces.

The system memory ( 320 ) is an example of computer storage media. Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other storage technology, CD-ROM, Digital Versatile Disc (DVD) or other optical storage, magnetic cartridge, magnetic tape, magnetic disk storage, or other magnetic storage devices any other medium that can be used to store the desired information on the computer device 300 can be accessed. Any such computer storage medium may be part of the device ( 300 ) be.

The computer device ( 300 ) may be used as a part of a portable (or mobile) small form factor electronic device such as a mobile phone, a smartphone, a personal digital assistant (PDA), a personal media player, a tablet computer, a wireless web watch Device, a personal headset device, an application-specific device or a hybrid device, which includes any of the above functions. The computer device ( 300 ) may also be implemented as a personal computer, including laptop and non-laptop computer configurations.

The foregoing detailed description has set forth various embodiments of the devices and / or processes using block diagrams, flowcharts, and / or examples. To the extent that these block diagrams, flowcharts and / or examples contain one or more functions and / or operations, it will be apparent to those skilled in the art that any function and / or operation within the same block diagrams, flowcharts or examples may be considered individually and / or collectively wide range of hardware, software, firmware, or virtually any combination of them, can be implemented. In one embodiment, various portions of the subject matter described herein may be implemented via application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), other integrated formats, or as a web service. Nevertheless, those skilled in the art will recognize that some aspects of the embodiments disclosed herein, in whole or in part, also in integrated circuits, as one or more computer programs executing on one or more computers as one or more programs running on one or more computers In accordance with this disclosure, designing the circuits and / or writing the code to the software and / or firmware is well within the skill of those skilled in the art, and may be implemented as firmware or virtually any combination thereof. Moreover, those skilled in the art will appreciate that the mechanisms of the subject matter described herein may be distributed as a program product in a variety of forms, and that an illustrative embodiment of the subject matter described herein is independent of the particular type of nonvolatile signal carrying medium used to actually perform the distribution , applies. Examples of a nonvolatile signal carrying medium include, among others, recordable media such as a floppy disk, a hard disk drive, a compact disc (CD), a digital video disk (DVD), a digital tape, a computer memory, etc .; and a transmission medium, such as a digital and / or analog communication medium. (eg a fiber optic cable, a waveguide, a wired communication link, a wireless communication link, etc.)

With respect to the use of substantially all terms herein in the plural and / or singular, those skilled in the art may, depending on the context and / or application, infer from the plural to the singular and / or from the singular to the plural. The various singular / plural permutations may be expressly set forth herein for purposes of illustration.

Thus, certain embodiments of the subject matter have been described. Other embodiments are within the scope of the following claims. In some cases, the actions recited in the claims may be performed in a different order and still achieve desirable results. In addition, the processes illustrated in the attached figures do not necessarily require the particular order or sequential order shown to achieve desirable results. In certain implementations, multitasking and parallel processing may be beneficial.

Claims (16)

A system for hosting and publishing software packages, the system comprising: an SDK host ( 103 ) that receives and stores artifacts associated with a software development kit and metadata that describes a version of the software development kit; a converter ( 104 ), which converts the received artifacts and metadata into a package for the Software Development Kit; a staging host ( 105 ), which parses the package and checks all dependencies of the package to ensure that the dependencies of the package exist and there are no dependency conflicts with another parsed package that uses at least one dependency equal to that of the package; a tester ( 106 ), which retrieves and tests the packages currently being processed to determine if there are any incompatibilities between the processed packages; and a package ( 107 ), which receives the currently processed packets from the tester and uses access control information to provide the currently processed packets in a common format for the appropriate users. The system of claim 1, wherein artifacts include: change logs, license files, resources, media files, sample projects, source files, compiled binaries, libraries, and other information associated with a particular SDK. The system of claim 1, further comprising receiving artifacts in a compressed format. The system of claim 1, wherein the metadata includes: the name of the SDK, versioning information, SDK dependencies, descriptions of the function that satisfies an SDK, the authors of an SDK, contact information for SDK authors, license information, the official website for an SDK , SDK platform requirements, screenshots, commands that need to be executed before integrating the SDK, disapproval information, compilation and project settings, or other details of the SDK. The system of claim 1, further comprising receiving metadata in JSON, YAML, XML format, in a custom domain-specific language format or by tags in a publicly accessible source control management system and as static zip files provided via HTTP, includes. The system of claim 1, further comprising the SDK host storing only artifacts and metadata for supported versions of an SDK. The system of claim 1, further comprising triggering the transducer under a condition. The system of claim 7, wherein a condition is an explicit signal from the SDK provider, an elevation of the status of the SDK host, or receiving a signal from the SDK host for a change. The system of claim 1, further comprising a command-line tool or other interaction capability that allows SDK providers to signal the tester that a particular SDK and version thereof is present in the staging host and ready for testing. A computer-implemented method for hosting and publishing software packages, the method comprising: receiving and storing artifacts associated with a software development kit and metadata containing a version of the software development kit ( 201 ) describe; Convert the received artifacts and metadata into a software development kit package ( 203 ); Parsing the package and checking all dependencies of the package to ensure that the dependencies of the package exist and there are no dependency conflicts with another parsed package that uses a dependency equal to that of the package ( 205 ); Test the currently processed packages to see if there are any incompatibilities of the prepared packages ( 207 ) with each other; and using access control information to make the currently processed packets in a common format for the corresponding users ( 208 ). The method of claim 10, wherein the artifacts include: change logs, license files, resources, media files, sample projects, source files, compiled binaries, libraries, and other information associated with a particular SDK. The method of claim 10, wherein the metadata includes: the name of the SDK, versioning information, SDK dependencies, descriptions of the function that satisfies an SDK that SDK creator, contact information for SDK authors, licensing information, the official website for an SDK, SDK platform requirements, screenshots, commands that need to be executed before integrating the SDK, disapproval information, compilation and project settings, or other details of the SDK. The method of claim 10, further comprising receiving metadata in JSON, YAML, XML format, in a custom domain-specific language format or by tags in a publicly accessible source control management system and as static zip files provided via HTTP, includes. The method of claim 10, further comprising initiating the conversion process under one condition. The method of claim 14, wherein a condition is an explicit signal from the SDK provider. The method of claim 10, further comprising a command-line tool or other means of interacting that allows SDK providers to signal that a particular SDK and version thereof are ready for testing.

Images