Configuring alteration proposal functions in management system

Abstract

A method (400) includes receiving a configuration request (20) requesting configuration management of an underlying configuration package (160), the underlying configuration package describing an infrastructure (152) of an application. The method includes determining a plurality of packet functions for a base configuration packet (170). Each packet function of the plurality of packet functions extends functionality of the base configuration packet. The method includes determining a change proposal function for a base configuration package and a plurality of package functions (180). The alteration proposal function proposals one or more of the plurality of package functions to extend functionality of the base configuration package. The method includes transmitting a change proposal function to a user device (10), and receiving an approval (318) of the change proposal function from the user device. In response, the method includes configuring the base configuration package using one or more of the plurality of package functions proposed by the change proposal function.

Description

Technical Field

[0001] The present disclosure relates to a change proposal function in a configuration management system. Background Art

[0002] As manual operations are replaced by automation, application programming interfaces (APIs) describe and support a large part of computing. Configuration management involves securely creating and changing settings that describe the desired state of API-driven systems. These configurations can describe computing infrastructure or software versions and settings running on top of that infrastructure. The process for managing this configuration has traditionally been managed manually on a case-by-case basis with limited automation applications. Summary of the invention

[0003] One aspect of the present disclosure provides a computer-implemented method, which, when executed on data processing hardware, causes data processing hardware to perform operations, the operations comprising: receiving a configuration request for configuration management of a base configuration package, the base configuration package describing the infrastructure of an application. The operations comprise: determining a plurality of package functions for the base configuration package. Each of the plurality of package functions extends the functionality of the base configuration package. The operations comprise: determining a change proposal function for the base configuration package and the plurality of package functions. The change proposal function proposes that one or more of the plurality of package functions extend the functionality of the base configuration package. The operations comprise: transmitting the change proposal function to a user device, and receiving approval of the change proposal function from the user device. The operations comprise: in response to receiving approval of the change proposal function, configuring the base configuration package using one or more of the plurality of package functions proposed by the change proposal function.

[0004] Implementations of the present disclosure may include one or more of the following optional features. In some implementations, the infrastructure of the application includes a distributed computing system. In some examples, the change proposal function specifies an independent variable of one or more of the plurality of package functions proposed by the change proposal function. Optionally, the change proposal function restricts possible values ​​of the independent variable of one or more of the plurality of package functions proposed by the change proposal function.

[0005] In some implementations, the transmitted change proposal function causes the user device to display the transmitted change proposal function on a graphical user interface (GUI) executed on the user device. In some examples, approval of the change proposal function includes a change to the change proposal function. Optionally, determining the change proposal function includes applying a validation function to the change proposal function. The validation function tests each package function according to one or more rules.

[0006] In some implementations, determining the change proposal function includes: determining a corresponding score for each corresponding change proposal function in the plurality of change proposal functions, and selecting the change proposal function based on each corresponding score. In some examples, determining the change proposal function includes evaluating a plurality of historical configurations of the base configuration package using the model. In further examples, the plurality of historical configurations include metadata representing deployment behavior.

[0007] Another aspect of the present disclosure provides a system, which includes data processing hardware and memory hardware that communicates with the data processing hardware. The memory hardware stores instructions that are executed on the data processing hardware to cause the data processing hardware to perform operations. The operations include: receiving a configuration request for configuration management of a base configuration package that describes the infrastructure of an application. The operations include: determining multiple package functions for the base configuration package. Each package function in the multiple package functions extends the functionality of the base configuration package. The operations include: determining a change proposal function for the base configuration package and the multiple package functions. The change proposal function proposes one or more of the multiple package functions to extend the functionality of the base configuration package. The operations include: transmitting the change proposal function to a user device, and receiving approval of the change proposal function from the user device. The operations include: in response to receiving approval of the change proposal function, configuring the base configuration package using one or more of the multiple package functions proposed by the change proposal function.

[0008] Implementations of the present disclosure may include one or more of the following optional features. In some implementations, the infrastructure of the application includes a distributed computing system. In some examples, the change proposal function specifies an independent variable of one or more of the plurality of package functions proposed by the change proposal function. Optionally, the change proposal function restricts possible values ​​of the independent variable of one or more of the plurality of package functions proposed by the change proposal function.

[0009] In some implementations, the transmitted change proposal function causes the user device to display the transmitted change proposal function on a graphical user interface (GUI) executed on the user device. In some examples, approval of the change proposal function includes a change to the change proposal function. Optionally, determining the change proposal function includes applying a validation function to the change proposal function. The validation function tests each package function according to one or more rules.

[0010] In some implementations, determining the change proposal function includes: determining a corresponding score for each corresponding change proposal function in the plurality of change proposal functions, and selecting the change proposal function based on each corresponding score. In some examples, determining the change proposal function includes evaluating a plurality of historical configurations of the base configuration package using the model. In further examples, the plurality of historical configurations include metadata representing deployment behavior.

[0011] The details of one or more implementations of the present disclosure are set forth in the accompanying drawings and the description below. Other aspects, features, and advantages will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 is a schematic diagram of an example system for determining a change proposal function for a configuration management system.

[0013] Figure 2 yes Figure 1 Schematic diagram of a configuration controller for a determine change proposal function of an example system.

[0014] Figure 3 is a schematic diagram of a configuration controller that manages selection and execution of a change proposal function based on user input received at a graphical user interface (GUI) executing on a user device.

[0015] Figure 4 is a flow diagram of an example operational arrangement of a method for providing a change proposal function in a configuration management system.

[0016] Figure 5 is a schematic diagram of an example computing device that can be used to implement the systems and methods described herein.

[0017] Like reference numerals in the various drawings indicate like elements. DETAILED DESCRIPTION

[0018] Application programming interfaces (APIs) describe and support a large part of computing because manual operations are replaced by automation. Configuration management involves securely creating and changing settings that describe the desired state of API-driven systems. These configurations can describe computing infrastructure, software versions and settings running on top of the infrastructure, etc. The process for managing this configuration is traditionally managed manually on a case-by-case basis and has limited automated applications. In addition, limited automation is typically applied only to workflows, rather than to the construction or verification of the configuration itself. Manual configuration is often more expensive and leads to errors and oversights, which cause interruptions and make computing more expensive and less efficient overall.

[0019] Conventional tools for generating configurations are limited, and typically these tools are at best monolithic and based on templated configurations. These templated systems are difficult to maintain, especially in cases where the system must express a wide variety of configuration options, because every possible option is exposed in a "simplified" surface, which can result in an API with considerable complexity as well as lower quality and lower consistency. In other words, configurations are developed as a single unit, and composability is difficult. This leads to the "over-parameterization problem", and as a result these approaches are difficult to automate and optimize.

[0020] For example, users of traditional template-based platforms must carefully consider how they want to consume shared packages. Often, users "fork" upstream packages so that they can simplify the upstream package to suit their needs. In other words, packages or templates are considered starting points for writing different packages, rather than real opportunities for configuration collaboration and reuse. When users manually change upstream configuration packages, they are then responsible for ongoing maintenance and typically do not automatically receive improvements made to the upstream package. This, in turn, makes the upstream package less useful because there is no incentive to share or publish back. In other words, the monolithic nature of traditional configuration bundles acts as a barrier to effective collaboration because all changes must be made to this monolithic location, and all changes must be carefully made to be compatible with all other changes. Therefore, both the creation and maintenance or modification of traditional template-based platforms require time-consuming manual input by users.

[0021] Implementations herein relate to a configuration management system that separates configuration into three separate layers: a first layer that includes a base package of configurations; a second layer that includes functions that can extend the base package; and a third layer that includes proposed functions that can guide functions to be applied to the base package. That is, the proposed functions curate package functions to be applied to the base package configuration to provide user-guided and / or automated creation and modification of configurations for infrastructure. Thus, the configuration management system described herein reduces configuration time, complexity, and the potential for errors during infrastructure setup and modification.

[0022] refer to Figure 1In some implementations, the example configuration management system 100 includes a remote system 140 that communicates with one or more user devices 10 via a network 112. The remote system 140 can be a single computer, multiple computers, or a distributed computing system (e.g., a cloud environment) with scalable / elastic resources 142, which include computing resources 144 (e.g., data processing hardware) and / or storage resources 146 (e.g., memory hardware). The data storage area 150 (i.e., remote storage device) can be overlaid on the storage resources 146 to allow one or more of the clients (e.g., user devices 10) or computing resources 144 to scalably use the storage resources 146. The data storage area 150 can store one or more base packages 160, each of which has one or more package functions 170, 170a-n. The base configuration packages 160 and package functions 170 stored on the storage resources 146 of the remote system 140 can be executed on the computing resources 144 of the remote system 140. Each base package 160 describes a computing infrastructure 152 for an application or system. For example, one or more of the base packages 160 may configure or provide a cloud infrastructure 152, such as part of a containerized orchestration system (e.g., servers, virtual machines, load balancers, storage, processing, etc.). Each package function 170 can extend or define the functionality of a base package 160, and any number of package functions 170 may be applied to a base package 160 at a given time or iteration or instance of a base package 160. Thus, a base package 160 is defined or modified by one or more package functions 170 to configure, for example, an infrastructure 152 of a remote system 140. Any number of base packages 160 and package functions 170 may be stored at the data store 150 at any point in time.

[0023] The remote system 140 is configured to receive a configuration request 20 from a user device 10 associated with a corresponding user 12 via, for example, a network 112. The user device 10 may correspond to any computing device, such as a desktop workstation, a laptop workstation, or a mobile device (i.e., a smart phone). The user device 10 includes computing resources 18 (e.g., data processing hardware) and / or storage resources 16 (e.g., memory hardware). The configuration request 20 requests the remote system 140 to configure the base package 160 (e.g., identified by the request 20) using one or more of the package functions 170.

[0024] The remote system 140 executes a configuration controller 200. In response to receiving a configuration request 20, the configuration controller 200 determines and proposes (or optionally, automatically applies) changes to the base package 160 to satisfy the configuration request 20. Using the base package 160 and the associated package functions 170, the configuration controller 200 determines one or more change proposal functions 180. Each change proposal function 180 proposes one or more of the package functions 170 to extend the functionality of the base package 160. That is, each change proposal function 180 includes a selection of one or more of the package functions 170 to extend or alter the functionality of the base package 160. Each package function 170 may include one or more arguments 172, 172a-n, which are provided to the package function 170 to obtain a result. Each change proposal function 180 may specify or restrict the arguments of the package function 170. For example, the change proposal function 180 specifies a Boolean argument as true, or restricts an integer argument to a range between one and ten. In other words, the change proposal function 180 includes one or more package functions 170 to be applied to or incorporated by the base package 160 to adjust or change the functionality of the base package 160 to achieve the desired provisioning and / or configuration of the infrastructure 152 (e.g., remote system 140 or any other computing infrastructure). The change proposal function 180 can define parameters or arguments 172 included in the package functions 170 of the change proposal function 180 to further define the configuration according to the configuration request 20.

[0025] Compared to traditional template-based alternatives, base packages 160 are simplified because base packages 160 need only provide the lowest common denominator configuration of infrastructure 152, whereas traditional templates must provide every possible configuration. That is, because base packages 160 do not include all (or even any) alternative configurations of application infrastructure 152, base packages 160 themselves are maintained while one or more package functions 170 modify or extend the functionality of base packages 160. This creates a more automated and extensible development model in which different users 12 configuring independent data stores 150 on a shared remote system 140 can collaborate and consume only relevant aspects of the configuration.

[0026] For example, when the base package 160 does not include specialized adaptations (i.e., one or more package functions 170) necessary for configuration of a particular user (as defined by the configuration request 20), such as a privacy protocol required by a compliance scheme, the configuration controller 200 may determine and / or select a change proposal function 180 that includes one or more package functions 170 that, when integrated with the base package 160, incorporates the adaptations necessary to support the required protocol. Thus, the base package 160 is shared among the users 12 of the remote systems 140, with a unique selection or combination of package functions 170 modifying the base package 160 for an individual user 12. In this way, the configuration controller 200 maintains and updates the base package 160 as needed so that all users 12 can receive updates to the base package 160 without affecting the functionality of their application infrastructure 152.

[0027] Package functions 170 describe alternative and / or additional configurations and can express changes to base packages 160 in a straightforward, minimal, and natural manner. Package functions 170 may be stored at remote system 140 (e.g., stored at data store 150) and called by change proposal function 180 to extend / alter base packages 160 as needed. That is, a catalog 174 of package functions 170 may be stored at remote system 140 such that configuration controller 200 selects package functions 170 from catalog 174 to extend / alter base packages 160 when determining change proposal function 180. User 12 may write or otherwise generate package functions 170 to be stored at remote system 140 for subsequent use with base packages 160.

[0028] Each package function 170 includes one or more arguments 172 (i.e., parameters) that at least partially define the effect of the package function on the base package 160. When selected for use in a change proposal function 180 by the configuration controller 200, the one or more arguments 172 for the selected package function 170 may be adjusted or parameterized to satisfy the configuration request 20. That is, the change proposal function 180 specifies the arguments 172 of the package function 170 according to the request 20.

[0029] The directory 174 may be accessed by multiple users 12 using the remote system 140 such that each user 12 may access the same package functions 170. Optionally, a subset of the package functions 170 on the directory 174 may be accessible to a subset of the users 12, such as where a user 12 generates a package function 170 and configures the package function 170 to be accessible only to subscribers or users 12 on the local network 112. The user-generated package function 170 may also be made accessible to all users 12 on the remote system 140.

[0030] In determining or generating a change proposal function 180, the configuration controller 200 receives the request 20 and, based on the request 20, determines one or more package functions 170 that, alone or in combination, satisfy the request 20. For example, the configuration controller 200 selects a package function 170 based on the arguments 172 of the package function 170. As described in more detail below, the package functions 170 are configured (e.g., define the arguments 172) and ordered as needed by the change proposal function 180 to satisfy the request 20, and the change proposal function 180 is executed to apply the package function to the base package 160. Optionally, the change proposal function 180 proposes a direct change to the package function 170 (i.e., beyond the constraint arguments 172), but this can be modeled as a change proposal function 180 that allows patches to be applied to either the package function 170 or the base package 160.

[0031] Not all package functions 170 may be compatible with the instance of base package 160 operated or controlled by user 12. For example, some available package functions 170 do not allow base package 160 to provide output or functionality expected by configuration request 20, or package functions 170 are not compatible with protocols required by user 12 or network 112, or other package functions 170 that have modified base package 160. Therefore, in some implementations, change proposal function 180 only includes package functions 170 that are compatible with the current iteration of base package 160.

[0032] Reference now Figure 2 , the configuration controller 200 receives or obtains the request 20, the base package 160, and the package function 170 (or a representation of the package function in the form of a catalog 174), and the configuration controller 200 determines the change proposal function 180 based on the request 20, the base package 160, and / or the package function 170. In other words, the configuration controller 200 selects one or more package functions 170 to curate one or more change proposal functions 180 that, when applied to the base package 160, configure the base package 160 based on the request 20. The configuration controller 200 determines the package function 170 and the change proposal function 180 by determining compatible or approved or successful package functions 170 using the validation module 202. The configuration controller 200 uses the evaluation module 204 to score or rank the success and / or effectiveness of the package function 170 and the change proposal function.

[0033] That is, the configuration controller 200 includes a verification module 202 to determine from the catalog 174 the package functions 170 that can be applied to the base package 160 (i.e., the approved package functions 170A, 170Aa-n) and the package functions 170 that cannot be applied to the base package 160. For example, the verification module 202 generates a catalog of approved package functions 170A (i.e., the approved catalog 174A), where the approved catalog 174A includes individual package functions 170 or groups of individual package functions 170 that can be used to satisfy the request 20. The approved package functions 170A are determined based on the package functions 170 that are actively applied to the base package 160, the arguments 172 of those package functions 170, the request 20, the local network protocol, etc.

[0034] The configuration controller 200 may pick or select one or more of the approved package functions 170A (or a combination of approved package functions 170A) because the package functions 170A operationally satisfy the request 20 and do not violate any rules associated with the base package 160 or the data store 150. For example, when an existing package function 170 requires that data shared on a remote system 140 running the base package 160 remain encrypted, the verification module 202 only accepts or approves the package functions 170 that satisfy the request 20 and maintain the encryption requirement (or the verification module 202 vetoes all package functions 170 that would allow unencrypted data to be shared, and then evaluates the remaining package functions 170 to determine those package functions that operationally satisfy the request 20). Thus, in some examples, at least some of the change proposal functions 180 are proposed to the user 12 only when the package functions 170 determined by the change proposal function are compatible with the base package 160 and / or the remote system 140 and when the package functions 170 satisfy the request 20.

[0035] In some implementations, the configuration controller 200 operates the evaluation module 204 to determine or generate a score 206, 206a-n for each package function 170 or each approved package function 170A. Optionally, the evaluation module 204 evaluates the determined change proposal function 180 and determines a score 206 for each change proposal function 180. The score 206 is associated with the corresponding package function 170 or change proposal function 180 to assist in evaluating and selecting the determined change proposal function 180. The determined score 206 is generated based on any suitable metric, such as the computational complexity of the package function 170, the number of package functions 170 in the change proposal function 180, the ability of the change proposal function 180 to satisfy the configuration request 20, the degree to which the change proposal function 180 conforms to the base package 160, the extensibility of the base package 160 after applying the corresponding change proposal function 180 (i.e., the ease with which additional package functions 170 can be applied), etc.

[0036] Based on the approved package functions 170A determined by the validation module 202 and the scores 206 determined by the evaluation module 204, the change proposal function builder 208 of the configuration controller 200 builds or determines one or more change proposal functions 180. The determined change proposal functions 180 can be communicated to the user 12 for approval and / or executed to modify the base package 160. The change proposal function builder 208 can determine the change proposal function 180 based on various factors. For example, the builder 208 determines the change proposal function 180 having a score 206 that satisfies a threshold score (e.g., is above or below a threshold score), the builder 208 determines the change proposal function 180 having the most (or conversely, the fewest) package functions 170 that satisfy the request 20, and so on. The builder 208 can communicate with the validation module 202 while determining the change proposal function 180 to ensure that the determined change proposal function satisfies the request 20, and communicate with the evaluation module 204 to score the combination of the package function 170 and the change proposal function 180. Because the builder 208 remains in communication with the validation module 202 , the validation module 202 is able to determine the compatibility of the change proposal function 180 before the change proposal function 180 is implemented with the base package 160 .

[0037] When validating or evaluating a potential package function 170, the configuration controller 200 may parameterize or define one or more arguments 172 of the package function 170, and base the result (i.e., the approved package function 170A or the score 206) on only those defined arguments 172. In this way, the configuration controller 200 automates defining the arguments 172 so that when proposing the package function 170 to the user 12, the user 12 does not need to manually define the arguments 172. Furthermore, in some examples, the configuration controller 200 defines the arguments 172 in a manner that optimizes the score 206 or satisfies the request 20. In some implementations, the configuration controller 200 proposes a change proposal function 180 to the user 12 only if the configuration controller 200 defines the arguments 172 in one or more specific ways during construction of the change proposal function 180.

[0038] Optionally, in determining the change proposal function 180, the configuration controller 200 considers metadata representing the historical configuration 160H of the base package 160. That is, in some implementations, the change proposal function 180 is determined based on the historical base packages 160H previously used by the user 12 submitting the request 20 and / or any other user 12 who previously used the same or similar base package 160. For example, the historical base package 160H identifies a package function 170 that is preferred by the user 12 or is known to have a high success rate when implemented with the base package 160 (e.g., when used by other users 12). The historical base package 160H may be stored on the remote system 140 and accessed by the configuration controller 200 when determining the change proposal function 180.

[0039] Continue to refer Figure 2 , the verification module 202 can consider the package functions 170 of the catalog 174 to determine an approved package function 170A that is compatible with the request 20, the base package 160, and any other considerations. As shown, the configuration controller 200 determines a first approved package function 170Aa defined by a corresponding first argument 172a and a second approved package function 170Ab defined by a corresponding second argument 172b. The defined arguments 172 of the package function 170 can be requirements to determine that the package function 170 is compatible with the change proposal function 180.

[0040] Here, only the approved package function 170A is processed by the evaluation module 204 to determine the corresponding score 206, but the entire catalog 174 of package functions 170 may be scored to determine the change proposal function 180. The first score 206a associated with the first approved package function 170Aa and the second score 206b associated with the second approved package function 170Ab identify the ability of the package function 170 to satisfy the request 20. Based on the approved catalog 174A and the scores 206 associated with the package functions 170, the change proposal function builder 208 determines one or more change proposal functions 180 to propose to the user 12. In this example, the change proposal function 180 includes only the first approved package function 170Aa defined by the first argument 172a and having the associated first score 206a, but the change proposal function 180 may include any number of package functions 170, or the change proposal function builder 208 may propose any number of change proposal functions 180. The determined change proposal function 180 may be managed by the package management system 300 of the configuration controller 200 for proposing implementation of the change proposal function 180 to the user 12 , processing user input regarding the proposed change proposal function 180 , and / or managing execution of the approved change proposal function 180 to apply the package function 170 to the base package 160 .

[0041] Thus, in some examples, the configuration controller 200 applies a validation function to determine whether a proposed change (i.e., a particular package function 170 or a change proposal function 180) is acceptable according to "internal" (e.g., remote system 140) rules. In addition, the evaluation module 204 evaluates whether the proposed change (i.e., a particular package function 170 or a change proposal function 180) is beneficial to the goals of the request 20 (or better than the existing configuration), or evaluates the change proposal function 180 to determine the optimal change proposal function 180. For example, a request 20 is received to generate instances of a base package 160 in multiple geographies across the remote system 140, and the evaluation module 204 generates a score 206 based on the financial cost of executing the instances using different change proposal functions 180.

[0042] refer to Figure 3 In some implementations, the configuration controller 200 determines the change proposal function 180 at the change proposal function builder 208, and the package management system 300 receives the change proposal function 180 to manage the proposal of the change proposal function 180 to the user 12, the execution of the approved change proposal function 180, and / or the request for new, modified, and additional change proposal functions 180. Thus, the package management system 300 manages when and how the base package 160 is modified by the change proposal function 180 based on, for example, user input or the package function 170 of the pending change proposal function 180. In other words, the package management system 300 manages configuration packages in various life cycle states (e.g., draft, under review, and approved packages), including the execution of the change proposal function 180. The package management system 300 can manage multiple change proposal functions 180, 180a-n simultaneously.

[0043] As shown, the package management system 300 receives change proposal functions 180 and categorizes these change proposal functions into one or more queues via the selection manager 302. For example, the selection manager 302 tracks the change proposal functions 180 currently determined by the change proposal function builder 208 or edited by the user 12 in the in-progress queue 306. Thus, the in-progress queue 306 tracks change proposal functions 180 that are not completed or in progress or otherwise cannot be applied to the base package 160 (i.e., unacceptable change proposal functions 180U, 180Ua-n). In some implementations, the unacceptable change proposal functions 180U include change proposal functions 180 determined by the verification module 202 to be incompatible with the request 20 or the base package 160.

[0044] The selection manager 302 manages the change proposal functions 180 that are completed and ready for review by the user 12 (i.e., reviewable change proposal functions 180R, 180Ra-n) in a review queue 308. The reviewable change proposal functions 180R can be approved for implementation with the base package 160 (i.e., approved change proposal functions 180A, 180Aa-n), or rejected for implementation with the base package (i.e., rejected change proposal functions 180D, 180Da-n). Approved change proposal functions 180A are sorted in an approved queue 310, and rejected change proposal functions 180D are sorted in a rejected queue 312.

[0045] The approved change proposal functions 180A may be communicated to the execution manager 304 for implementation with the base package 160. That is, once the change proposal functions 180 are approved, the execution manager 304 may pull the approved change proposal functions 180A for merging with the base package 160. The execution manager 304 may implement the approved change proposal functions 180A one at a time in a given order defined by the approved queue 310, or the execution manager 304 may pull multiple groups of approved change proposal functions 180A for implementation simultaneously. For example, the execution manager 304 may pull all approved change proposal functions 180A present in the approved queue 310 at defined time intervals or once a threshold number of approved change proposal functions 180A are present in the approved queue 310.

[0046] The reviewable change proposal function 180R is approved by the user 12 (such as via user input at a graphical user interface (GUI) 314 executed by the user device 10), or the reviewable change proposal function 180R may be automatically approved by the selection manager 302. The selection manager 302 may distinguish between reviewable change proposal functions 180R that must be approved by the user 12 (or more than one user 12) and those reviewable change proposal functions that may be automatically approved, such as based on the request 20. For example, the request 20 may require that a change to the base package 160 be completed in the most efficient manner. Once the configuration controller 200 determines that the change proposal function 180 has an associated score 206 identifying it as the most efficient and / or successful change proposal function 180, the selection manager 302 may automatically submit the change proposal function 180 to the execution manager 304 for implementation with the base package 160. When request 20 specifies that the determined effectiveness of change proposal function 180 requires approval by user 12 prior to implementation, change proposal function 180 will be communicated to user 12 , who must approve change proposal function 180 before submitting it to execution manager 304 .

[0047] An unacceptable change proposal function 180U that the verification module 202 determines to be incompatible with the request 20 may be reconsidered by the verification module 202 so that the change proposal function 180 may be classified as a reviewable change proposal function 180R in the event that a change to the base package 160 allows the change proposal function 180 to be implemented with the base package 160. Thus, the selection manager 302 may communicate the change proposal function 180 to the verification module 202 to determine, for example, whether the unacceptable change proposal function 180U has been made compatible, or to verify the compatibility of an approved change proposal function 180A as a check before being implemented with the base package 160.

[0048] The change proposal functions 180 may be sorted in a queue and retrieved by the selection manager 302 in any suitable order (such as for proposal to the user 12 or for queuing for execution by the execution manager 304). For example, the change proposal functions 180 may be sorted based on the scores 206 associated with the change proposal functions 180 or based on an implementation order set by the user 12. Accordingly, the selection manager 302 communicates with the evaluation module 204 to determine and verify the scores 206 associated with the change proposal functions 180. For example, the user 12 may provide input at the GUI to allow automatic approval of all change proposal functions 180 having at least a threshold score 206.

[0049] Additionally or alternatively, the selection manager 302 generates a request 20 for a new, additional, or modified change proposal function 180 for determination by the change proposal function builder 208. The request 20 generated by the selection manager 302 may be in addition to any request 20 received from a user, and may be prompted by additional user input (such as at the GUI 314) in response to receiving a request 20 from a user, and / or prompted by approval or execution of a previous change proposal function 180. As discussed above, the request 20 may result in the determination of one or more change proposal functions 180 for one or more existing base packages 160 and / or the creation of one or more new base packages 160 with or without package functions 170.

[0050] When the request 20 that triggers the change proposal function 180 is user-prompted, the selection manager 302 may communicate one or more change proposal functions 180 to the user 12 via the GUI 314 for selection or approval by the user 12. For example, the selection manager 302 receives a request 20 from the user 12 requesting a change to the base package 160. If the selection manager 302 determines that no change proposal function 180 in the review queue 308 (or any of the other queues) satisfies the request 20, the selection manager 302 may generate a request 20 to determine a change proposal request that will satisfy the request 20. Conversely, if the configuration request 20 from the user 12 requests a change to a configuration that is already set to occur based on a queued change proposal function 180, the selection manager 302 may ignore the request 20 or give priority to the change proposal function 180 that is set to satisfy the request 20. In other words, the selection manager 302 determines whether the input received from the user 12 requires the configuration controller 200 to determine a change proposal function 180.

[0051] When submitting input to generate a configuration request 20, the user 12 need not be specific to or even know the package functions 170 or change proposal functions 180 that may be applied to the base package 160. In other words, the package functions 170 and change proposal functions 180 may not be easily interpretable or identifiable, and the user 12 may trigger the determination of an appropriate change proposal function 180 without specifically identifying the necessary components and without having the skills or ability to create or parse the package functions 170. Instead, the user 12 may input the desired result of the change proposal function 180 (i.e., the desired end state of the base package 160), and the configuration controller 200 determines the change proposal function 180 necessary to achieve the desired result. Similarly, the change proposal function 180 may be determined and presented in a manner suitable for interpretation and application to the base package 160 by the user 12. For example, the change proposal function 180 may be determined using a domain specific language (DSL), which optionally uses templates to simplify the task of creating the change proposal function 180 without the ability or resources to manually code.

[0052] In some implementations, the configuration request 20 defines arguments 172 or specifies an output or desired end state of the infrastructure 152. In such implementations, the configuration request 20 does not directly select a package function 170 or a specific approval change proposal function 180. Instead, the defined arguments 172 or desired end state of the configuration request 20 instructs the configuration controller 200 to determine the change proposal function 180 by selecting a package function 170 that satisfies the request 20. For example, the configuration request 20 may require that a first user group of the data store 150 should only have access to a first subset of data stored on the remote system 140, and a second user group should only have access to a second subset of data. Rather than specifying the location of the data subset on the remote system 140 and manually applying security protocols to those locations, the configuration request 20 may simply define the categories of the data subsets, and the configuration controller 200 may select a package function 170 that is capable of determining the location of the data subsets and assigning access permissions to the corresponding user groups. The change proposal function 180 may also intuitively or automatically add a package function 170 that updates the access permissions of a user when the user is added to the system or moved between groups, such as based on standard practices or known protocols that such a switch does not require administrator approval. Similarly, if the base package 160 includes a package function 170 in a data subset that contains sensitive information that requires prior approval for access, then the package function in the new package function 170 that has access approval capabilities can be selected.

[0053] In some implementations, approval or implementation of one or more change proposal functions 180 triggers approval, implementation, or creation of requests 20 for additional change proposal functions 180. When the triggered change proposal function 180 applies to the same instance of the base package 160 as the triggering change proposal function 180, the subsequently determined change proposal function 180 may be constructive (i.e., intended to build upon the package function 170 of the first determined change proposal function 180) or alternative (i.e., intended to replace, substitute, or further define the package function 170 of the first determined change proposal function 180). For example, a first change proposal function 180 generates requests 20 for subsequent change proposal functions 180, which may be proposed to the user 12 simultaneously and collectively, wherein the first change proposal function 180 addresses the initial request 20 of the user 12, and the subsequent change proposal function 180 is a recommendation for additional configuration changes. Optionally, subsequent change proposal functions 180 may be determined and executed based on any user's approval of a similar or previous change proposal function 180, without requiring approval by the user 12.

[0054] In some implementations, approval or implementation of a change proposal function 180 for a first instance of a base package 160 triggers approval or implementation of a change proposal function 180 that is the same or similar to a second existing instance of a base package 160. For example, a user 12 may operate similar base packages 160 on a remote system 140, with separate instances responsible for different geographic regions. When the user 12 approves implementation of a change proposal function 180 for a base package 160 for one geographic region, the selection manager 302 recommends or implements the same or similar change proposal functions 180 for other base packages 160 for other geographic regions, where the required components (such as the arguments 172) of the additional change proposal functions 180 are customized for the specific base package 160.

[0055] In some implementations, approval or implementation of a change proposal function 180 for a first instance of a base package 160 triggers creation of a second instance of the base package, and optionally, triggers implementation or approval of the same or similar change proposal function 180 for the second created instance of the base package 160. In other words, the approved or executed change proposal function 180 may also assist in instance creation, wherein the user 12 may be prompted to allow creation of another instance of the base package 160 and include a package function 170 specific to the pending instance selected or generated by the change proposal function 180. For example, an instance class of a base package 160 may be generally associated with one or more other instance classes of the base package 160, such as creating separate instances of a base package 160 in development, stage, and production settings, wherein, for example, the base package 160 and package function 170 are repeated between instances, but with differently defined arguments 172. Thus, when the selection manager 302 recognizes that if the request 20 generates a first type instance of the base package 160 configured in a first manner, the user 12 will also generate a second type instance of the base package 160 configured in a second manner, in response to determining that the user 12 has already created the first instance, the selection manager 302 can determine a change proposal function 180 having one or more package functions 170 to be applied to the second instance of the base package 160, and prompt the user 12 to approve or deny the creation of the second instance.

[0056] Generating and / or executing a change proposal function 180 that is beyond the scope of the original request 20 may be referred to as speculative execution. There is no limit to how extensive speculative execution may be, or how finely detailed the speculative execution may be. In other words, the determination of the change proposal function 180 may result in an extensive chain of change proposal functions 180 with package functions 170, which have defined arguments 172, all of which are collectively expressed in an almost infinite number of ways. Speculative execution may make proposals based on a configuration corpus and previous changes and proposals (including metadata about whether users have pushed those changes, whether those changes were ultimately approved for deployment, and how those changes performed in real-world environments) using historical statistics, artificial intelligence (AI), machine learning (ML), etc. In other words, when determining whether a change proposal function 180 triggers a request 20 for an additional change proposal function, the selection manager 302 may consider historical base packages 160, other active base packages 160 on the remote system 140, and trends and trajectories such as those determined using AI or ML.

[0057] Because speculative execution may generate an undesirable or unmanageable number of proposed change functions 180 for the user 12 or the selection manager 302 to consider, the selection manager 302 may limit the determined proposed change functions 180 in terms of number, complexity, and / or the degree to which they will alter the underlying functions. For example, the selection manager 302 may only propose proposed change functions 180 that have a score 206 above a threshold, or only propose a configurable number (e.g., three, five, ten, etc.) of proposed change functions 180 that have the highest scores 206.

[0058] Furthermore, because the change proposal function 180 is sometimes automatically generated or does not satisfy the request 20, the user 12 may choose to reject or deny the change proposal function 180, or the user 12 may manually adjust the change proposal function 180 (such as by redefining the arguments 172 of the package function 170). Furthermore, multiple change proposal functions 180 may be presented to the user 12, where only one or a subset of the change proposal functions 180 need to be implemented. For example, acceptance and implementation of a first change proposal function 180 may reject implementation of a second change proposal function 180 and trigger the proposal or implementation of a third change proposal function 180.

[0059] Before the change proposal function 180 is applied to the base package 160, the user 12 may be prompted to approve or deny or modify the change proposal function 180. In some implementations, the configuration controller 200 determines multiple change proposal functions 180 that each satisfy the request 20 in a different manner. For example, a first change proposal function 180a includes a first package function 170a having a first argument 172a, and a second change proposal function 180b includes a second package function 170b having a second argument 172b. Both change proposal functions 180a, 180b satisfy the request 20, but have different outcomes or future trajectories for the base package 160. Thus, in these examples, the user 12 is prompted to choose between the first change proposal function 180a and the second change proposal function 180b.

[0060] In some examples, the configuration controller 200 transmits the change proposal functions 180 to the user device 10. The user device 10 displays the change proposal functions 180 to the user 12 (e.g., via the GUI 314 executed on the user device 10). The configuration controller 200 may receive a selection 22 from the user device 10 selecting one or more of the change proposal functions 180. Using the selected change proposal functions 180, the configuration controller 200 may configure the base package 160 using the package functions 170 used by the change proposal functions 180 selected by the user 12. In other implementations, the configuration controller 200 automatically selects one or more of the change proposal functions 180 without input from the user 12. For example, the configuration controller 200 scores each change proposal function 180 (e.g., via the historical configuration of the base package 160) and selects one or more of the change proposal functions 180 that meet a threshold.

[0061] The selection manager 302 communicates the change proposal function 180 to the user 12 via a GUI 314 executed on the user device 10. The GUI 314 allows the user 12 to visualize the change proposal function 180, such as via a description of the changes to the base package 160 that would occur if the change proposal function 180 were implemented, or other interpretable media, such as a graphical icon, a readable code, etc. The GUI 314 receives various user inputs and communicates the request 20 and the selections 22 to the configuration controller 200 based on the user inputs. For example, the user 12 approves the presented change proposal function 180 via an approve input 318, and rejects or rejects the presented change proposal function 180 via a reject input 320. The user 12 may edit the change proposal function 180 (such as by defining the arguments 172 of the package function 170), or generate a request 20 via an edit input 322 at the GUI 314. Additionally, user 12 may scroll through options presented by package management system 300 via scroll inputs, such as next input 324 and previous input 326 .

[0062] Thus, a user 12 of the system will typically be presented with a change proposal function 180 in the GUI 314, and can choose to proceed with one or more of the change proposal functions 180, or can modify them before proceeding. They can also completely ignore or veto the change proposal function 180. The abstraction with this additional step allows the change proposal function 180 to be more speculative. That is, there are few cases where the configuration controller 200 should always perform a certain action, and now, with speculative execution, automation can be used in wider and more obscure areas of general configuration management.

[0063] Where a traditional template-based system would require the user 12 to manually enter values ​​for the arguments 172, the change proposal function 180 can propose calls to the package function 170 with some or all of the arguments 172 specified (or at least bounded or narrowed). The change proposal function 180 can propose multiple applications of the same package function 170, such as for development, stage, and production environments. This allows for more automation and less manual labor. Confidence in the change proposal function 180 as an automatically generated rather than a human-driven proposal can also be increased. There can be confidence that proposals have been consistently applied across all packages, not just to packages picked by a human operator, that rules can be codified without requiring constant interpretation, and that there are no human errors (e.g., typos, mistakes, or oversights) when creating changes.

[0064] Figure 44 is a flow chart of an exemplary arrangement of operations of a method 400 for providing a change proposal function in a configuration management system. The computer-implemented method, when executed by data processing hardware, causes the data processing hardware to perform operations, including: at step 402, receiving a configuration request 20 requesting configuration management of a base configuration package 160, the base configuration package describing an infrastructure 152 of an application. The operations include: at step 404, determining a plurality of package functions 170 for the base package 160. Each package function 170 in the plurality of package functions 170 extends the functionality of the base package 160. The operations include: at step 406, determining a change proposal function 180 for the base package 160 and the plurality of package functions 170. The change proposal function 180 proposes one or more of the plurality of package functions 170 to extend the functionality of the base package 160. The operations include: at step 408, transmitting the change proposal function to a user device 10, and at step 410, receiving approval of the change proposal function 180 from the user device 10. The operations further include, at step 412 , configuring the base package 160 using one or more of the plurality of package functions 170 proposed by the change proposal function 180 in response to receiving the approval.

[0065] Figure 5 is a schematic diagram of an example computing device 500 that can be used to implement the systems and methods described in this document. Computing device 500 is intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The components shown here, their connections and relationships, and their functions are intended to be exemplary only, and are not intended to limit implementations of the inventions described and / or claimed in this document.

[0066] The computing device 500 includes a processor 510, a memory 520, a storage device 530, a high-speed interface / controller 540 connected to the memory 520 and a high-speed expansion port 550, and a low-speed interface / controller 560 connected to a low-speed bus 570 and the storage device 530. Each of the components 510, 520, 530, 540, 550, and 560 is interconnected using various buses and can be installed on a common motherboard or installed in other ways as appropriate. The processor 510 can process instructions for execution within the computing device 500, including instructions stored in the memory 520 or on the storage device 530, to display graphical information of a graphical user interface (GUI) on an external input / output device (such as a display 580 coupled to the high-speed interface 540). In other implementations, multiple processors and / or multiple buses and multiple memories and multiple types of memories can be used as appropriate. In addition, multiple computing devices 500 can be connected, each of which provides a portion of the necessary operations (for example, as a server group, a blade server group, or a multi-processor system).

[0067] Memory 520 stores information non-temporarily within computing device 500. Memory 520 may be a computer-readable medium, a volatile memory unit, or a non-volatile memory unit. Non-temporary memory 520 may be a physical device for temporarily or permanently storing programs (e.g., instruction sequences) or data (e.g., program state information) for use by computing device 500. Examples of non-volatile memory include, but are not limited to, flash memory and read-only memory (ROM) / programmable read-only memory (PROM) / erasable programmable read-only memory (EPROM) / electronically erasable programmable read-only memory (EEPROM) (e.g., typically used for firmware, such as bootloaders). Examples of volatile memory include, but are not limited to, random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), phase change memory (PCM), and disk or tape.

[0068] Storage device 530 is capable of providing mass storage for computing device 500. In some implementations, storage device 530 is a computer-readable medium. In various different implementations, storage device 530 may be a floppy disk device, a hard disk device, an optical disk device, or a tape device, a flash memory or other similar solid-state memory device, or an array of devices (including devices in a storage area network or other configuration). In additional implementations, a computer program product is tangibly embodied in an information carrier. The computer program product includes instructions that, when executed, perform one or more methods, such as those described above. The information carrier is a computer or machine-readable medium, such as memory 520, storage device 530, or memory on processor 510.

[0069] The high-speed controller 540 manages bandwidth-intensive operations of the computing device 500, while the low-speed controller 560 manages less bandwidth-intensive operations. Such a division of responsibilities is exemplary only. In some implementations, the high-speed controller 540 is coupled to the memory 520, the display 580 (e.g., through a graphics processor or accelerator), and a high-speed expansion port 550 that can accept various expansion cards (not shown). In some implementations, the low-speed controller 560 is coupled to the storage device 530 and the low-speed expansion port 590. The low-speed expansion port 590, which can include various communication ports (e.g., USB, Bluetooth, Ethernet, wireless Ethernet), can be coupled to one or more input / output devices, such as a keyboard, a pointing device, a scanner, or a networking device, such as a switch or a router, for example, through a network adapter.

[0070] As shown, computing device 500 may be implemented in a variety of different forms. For example, computing device may be implemented as a standard server 500a or multiple times in a group of such servers 500a, as a laptop computer 500b, or as part of a rack server system 500c.

[0071] Various implementations of the systems and techniques described herein can be implemented in digital electronic and / or optical circuit systems, integrated circuit systems, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system that includes at least one programmable processor that can be special-purpose or general-purpose and can be coupled to receive data and instructions from and send data and instructions to a storage system, at least one input device, and at least one output device.

[0072] A software application (i.e., software resource) may refer to computer software that enables a computing device to perform tasks. In some examples, a software application may be referred to as an "application," "app," or "program." Example applications include, but are not limited to, system diagnostic applications, system management applications, system maintenance applications, word processing applications, spreadsheet applications, messaging applications, media streaming applications, social networking applications, and gaming applications.

[0073] These computer programs (also referred to as programs, software, software applications, or code) include machine instructions for a programmable processor and may be implemented in high-level procedural and / or object-oriented programming languages ​​and / or assembly / machine languages. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, non-transitory computer-readable medium, apparatus, and / or device (e.g., disk, optical disk, memory, programmable logic device (PLD)) for providing machine instructions and / or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal for providing machine instructions and / or data to a programmable processor.

[0074] The processes and logic flows described in this specification can be performed by one or more programmable processors (also referred to as data processing hardware), which execute one or more computer programs to perform functions by operating on input data and generating outputs. The processes and logic flows can also be performed by a dedicated logic circuit system, such as an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit). For example, processors suitable for executing computer programs include general-purpose and special-purpose microprocessors, and any one or more processors of any kind of digital computer. Typically, the processor will receive instructions and data from a read-only memory or a random access memory or both. The basic elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include one or more mass storage devices for storing data, such as a magnetic disk, a magneto-optical disk, or an optical disk, or be operably coupled to receive data from one or more mass storage devices or to transfer data to one or more mass storage devices or both. However, a computer does not have to have such a device. Computer-readable media suitable for storing computer program instructions and data include all forms of nonvolatile memory, media, and memory devices, including, for example, semiconductor memory devices (e.g., EPROM, EEPROM, and flash memory devices), magnetic disks (e.g., internal hard disks or removable disks), magneto-optical disks, and CD ROM and DVD-ROM disks. The processor and memory may be supplemented by, or incorporated in, special purpose logic circuitry.

[0075] To provide interaction with a user, one or more aspects of the present disclosure may be implemented on a computer having a display device (e.g., a CRT (cathode ray tube), LCD (liquid crystal display) monitor) or a touch screen for displaying information to the user, and optionally a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the computer. Other types of devices may also be used to provide interaction with the user; for example, the feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input from the user may be received in any form, including sound, voice, or tactile input. In addition, the computer may interact with the user by sending documents to and receiving documents from a device used by the user; for example, by sending a web page to a web browser on a user's client device in response to a request received from the web browser.

[0076] A variety of implementations have been described. However, it should be understood that various modifications may be made without departing from the spirit and scope of the present disclosure. Therefore, other implementations are within the scope of the appended claims.

Claims

1. A computer-implemented method (400) performed by data processing hardware (144) to cause the data processing hardware (144) to perform an operation, characterized in that: The operations include: Receiving a configuration request (20) requesting configuration management of a base configuration package (160) describing an infrastructure (152) of an application; Determining a plurality of package functions (170) for the basic configuration package (160), each package function (170) in the plurality of package functions (170) extending the functionality of the basic configuration package (160); Determining a change proposal function (180) for the base configuration package (160) and the plurality of package functions (170), the change proposal function (180) proposing one or more of the plurality of package functions (170) to extend the functionality of the base configuration package (160); transmitting the change proposal function (180) to a user device (10); receiving an approval (318) of the change proposal function (180) from the user device (10); and In response to receiving the approval (318) of the change proposal function (180), the base configuration package (160) is configured using the one or more of the plurality of package functions (170) proposed by the change proposal function (180).

2. The method (400) according to claim 1, characterized in that: The infrastructure (152) of the application includes a distributed computing system (140).

3. The method (400) according to claim 1 or claim 2, characterized in that: The change proposal function (180) specifies arguments (172) of the one or more of the plurality of package functions (170) proposed by the change proposal function (180).

4. The method (400) according to any one of claims 1 to 3, characterized in that: The change proposal function (180) restricts possible values ​​of the arguments (172) of the one or more of the plurality of package functions (170) proposed by the change proposal function (180).

5. The method (400) according to any one of claims 1 to 4, characterized in that: The transmitted change proposal function (180) causes the user device (10) to display the transmitted change proposal function (180) on a graphical user interface (GUI) (314) executed on the user device (10).

6. The method (400) according to any one of claims 1 to 5, characterized in that: The approval (318) of the change proposal function (180) includes changes to the change proposal function (180).

7. The method (400) according to any one of claims 1 to 6, characterized in that: Determining the change proposal function (180) includes applying a validation function to the change proposal function (180), the validation function testing each package function (170) against one or more rules.

8. The method (400) according to any one of claims 1 to 7, characterized in that: Determining the change proposal function (180) includes: determining a respective score (206) for each respective change proposal function (180) in the plurality of change proposal functions (180); and The change proposal function (180) is selected based on each respective score (206).

9. The method (400) according to any one of claims 1 to 8, characterized in that: Determining the change proposal function (180) includes evaluating a plurality of historical configurations (160H) of the base configuration package (160) using a model.

10. The method (400) of claim 9, characterized in that: The plurality of historical configurations (160H) include metadata representing deployment behavior.

11. A system (100), characterized in that: The system comprises: data processing hardware (144); and Memory hardware (146), the memory hardware in communication with the data processing hardware (144), the memory hardware (146) storing instructions, the instructions being executed on the data processing hardware (144) to cause the data processing hardware (144) to perform operations, the operations comprising: Receiving a configuration request (20) requesting configuration management of a base configuration package (160) describing an infrastructure (152) of an application; Determining a plurality of package functions (170) for the basic configuration package (160), each package function (170) in the plurality of package functions (170) extending the functionality of the basic configuration package (160); Determining a change proposal function (180) for the base configuration package (160) and the plurality of package functions (170), the change proposal function (180) proposing one or more of the plurality of package functions (170) to extend the functionality of the base configuration package (160); transmitting the change proposal function (180) to a user device (10); receiving an approval (318) of the change proposal function (180) from the user device (10); and In response to receiving the approval (318) of the change proposal function (180), the base configuration package (160) is configured using the one or more of the plurality of package functions (170) proposed by the change proposal function (180).

12. The system (100) according to claim 11, characterized in that The infrastructure (152) of the application includes a distributed computing system (140).

13. The system (100) of claim 11 or claim 12, characterized in that The change proposal function (180) specifies arguments (172) of the one or more of the plurality of package functions (170) proposed by the change proposal function (180).

14. The system (100) according to any one of claims 11 to 13, characterized in that The change proposal function (180) restricts possible values ​​of the arguments (172) of the one or more of the plurality of package functions (170) proposed by the change proposal function (180).

15. The system (100) according to any one of claims 11 to 14, characterized in that The transmitted change proposal function (180) causes the user device (10) to display the transmitted change proposal function (180) on a graphical user interface (GUI) (314) executed on the user device (10).

16. The system (100) according to any one of claims 11 to 15, characterized in that The approval (318) of the change proposal function (180) includes changes to the change proposal function (180).

17. The system (100) according to any one of claims 11 to 16, characterized in that Determining the change proposal function (180) includes applying a validation function to the change proposal function (180), the validation function testing each package function (170) against one or more rules.

18. The system (100) according to any one of claims 11 to 17, characterized in that Determining the change proposal function (180) includes: determining a respective score (206) for each respective change proposal function (180) in the plurality of change proposal functions (180); and The change proposal function (180) is selected based on each respective score (206).

19. The system (100) according to any one of claims 11 to 18, characterized in that Determining the change proposal function (180) includes evaluating a plurality of historical configurations (160H) of the base configuration package (160) using a model.

20. The system (100) of claim 19, wherein: The plurality of historical configurations (160H) include metadata representing deployment behavior.

Images