Abstract: A method implemented by at least one server for pushing managed package upgrades comprises receiving a dependency graph from an operating entity via an API call that expresses relationships between a set of software packages. A subscriber set is ingested for subscribers of the software packages via an API call to the operating entity that owns the software packages. A per-subscriber dependency graph is constructed expressing relationships between the individual subscriber's delivery operations. The set of packages is delivered based on dependency order of the per-subscriber dependency graph, while applying one or more rules including: i) push schedule rules that allow the first operating entity to specify time-based gates for the deliveries; ii) subscriber exclusion rules that allow the operating entity to exclude specific subscribers; iii) rules for automatic retries of failed operations; and iv) rules to chunk the push upgrade operations.

Abstract: A method implemented by at least one server for pushing managed package upgrades comprises receiving a dependency graph from an operating entity via an API call that expresses relationships between a set of software packages. A subscriber set is ingested for subscribers of the software packages via an API call to the operating entity that owns the software packages. A per-subscriber dependency graph is constructed expressing relationships between the individual subscriber's delivery operations. The set of packages is delivered based on dependency order of the per-subscriber dependency graph, while applying one or more rules including: i) push schedule rules that allow the first operating entity to specify time-based gates for the deliveries; ii) subscriber exclusion rules that allow the operating entity to exclude specific subscribers; iii) rules for automatic retries of failed operations; and iv) rules to chunk the push upgrade operations.

Abstract: Methods, systems, and devices supporting in-memory software package installation and testing are described. Some systems (e.g., a multi-tenant cloud computing platform) may support installation of software packages, where each package may be defined by a set of metadata. If a tenant selects to install a package, the system may test the package for conflicts between the package and the tenant's production environment. The system may automatically detect additional packages linked to the package based on dependencies defined in the metadata and may temporarily install the one or more packages in-memory at one or more servers. The system may pull a subset of data from the tenant's production environment into the in-memory testing environment based on a metadata testing file in order to support running tests defined by the metadata testing file. The system may test the package(s) in-memory at the server(s) for any conflicts using the metadata testing file.

Abstract: Methods, systems, and devices supporting in-memory software package installation and testing are described. Some systems (e.g., a multi-tenant cloud computing platform) may support installation of software packages, where each package may be defined by a set of metadata. If a tenant selects to install a package, the system may test the package for conflicts between the package and the tenant's production environment. The system may automatically detect additional packages linked to the package based on dependencies defined in the metadata and may temporarily install the one or more packages in-memory at one or more servers. The system may pull a subset of data from the tenant's production environment into the in-memory testing environment based on a metadata testing file in order to support running tests defined by the metadata testing file. The system may test the package(s) in-memory at the server(s) for any conflicts using the metadata testing file.