Configuration change control for computing environments

Abstract

A solution for balancing speed and risk by managing configuration changes includes: receiving a second configuration item for replacing a first configuration item in an exposure group; receiving an exposure state, wherein the exposure state indicates an exposure tree, the exposure tree including a first configuration item branch and a second configuration item branch; determining, based at least on the exposure state: a first portion of the exposure group to continue the first configuration item, and a second portion of the exposure group to receive the second configuration item; deploying the second configuration item to the second portion of the exposure group according to the exposure state; receiving an updated exposure state from a central orchestrator; and deploying the second configuration item according to the updated exposure state. In some examples, the exposure tree is a hierarchical binary tree. Exemplary configuration items include software application versions.

Description

Background Art

[0001] Organizations that manage large numbers of computing assets or serve large numbers of users, or provide configuration items such as software, data, and models face a trade-off between the speed of roll-out of updated (replaced) configuration items and the risk that the updated configuration items contain vulnerabilities or other problematic defects. If the replacement performs poorly, it is often necessary to limit exposure. For example, if a new configuration item will cause serious problems for individual users, then exposing all users immediately may lead to large-scale outages in certain scenarios. Therefore, there is a need to balance the speed of rollout with risk management. This occurs in a variety of environments, including locally installed software, data sets, and machine learning (ML) models, as well as software as a service (SaaS) and platform as a service (PaaS) arrangements. Summary of the invention

[0002] The disclosed examples are described in detail below with reference to the accompanying drawings listed below. The following summary is provided to illustrate some examples disclosed herein. However, this is not meant to limit all examples to any specific configuration or sequence of operations.

[0003] Some aspects disclosed herein are directed to a solution for managing configuration changes, including: receiving a second configuration item for replacing a first configuration item in an exposure group; receiving an exposure state, wherein the exposure state indicates an exposure tree, the exposure tree including a first configuration item branch and a second configuration item branch; for the exposure group, determining at least based on the exposure state: a first portion of the exposure group to continue the first configuration item, and a second portion of the exposure group to receive the second configuration item; deploying the second configuration item to the second portion of the exposure group based on the exposure state; receiving an updated exposure state from a central orchestrator based at least on a first triggering event; and deploying the second configuration item based on the updated exposure state. In some examples, the exposure tree is a hierarchical binary tree. Exemplary configuration items include software application versions. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] The disclosed examples are described in detail below with reference to the accompanying drawings listed below:

[0005] Figure 1 illustrates an arrangement for advantageously employing configuration change control for managed nodes (e.g., computing assets);

[0006] Figure 2 An exemplary collection of exposomes is illustrated;

[0007] Figure 3 The diagram shows Figure 1 The arrangement of Figure 2 Exemplary stages of traffic movement operations performed by a representative group of;

[0008] Figure 4 The diagram shows how Figure 1 An exemplary exposure tree of various stages of a configuration item rollout executed by a layout;

[0009] Figure 5 The diagram shows how Figure 1 An exemplary hierarchical exposure tree of various stages of a configuration item rollout executed by a layout;

[0010] Figure 6 It also shows how Figure 1 An exemplary hierarchical exposure tree of various stages of a configuration item rollout executed by a layout;

[0011] Fig. 7A and Figure 7B Pseudo-code in an exemplary file is shown for managing Figure 1 Configuration changes performed by the arrangement of

[0012] Figure 8 The diagram shows Figure 1 An exemplary message passing sequence performed within an arrangement of;

[0013] Fig. 9 is a flow chart illustrating how Figure 1 Exemplary operations involved in configuration change control performed by an arrangement of;

[0014] Fig.10 is another flow chart illustrating how Figure 1 exemplary operations involved in configuration change control performed by an arrangement of

[0015] Fig.11 is a block diagram of an example computing environment suitable for implementing some of the various examples disclosed herein.

[0016] Corresponding reference numerals indicate corresponding parts throughout the drawings. DETAILED DESCRIPTION

[0017] Various examples will be described in detail with reference to the accompanying drawings. Throughout the drawings, the same reference numerals will be used to refer to the same or similar parts where possible. Throughout this disclosure, references to specific examples and implementations are provided for illustrative purposes only, but are not intended to be limiting of all examples unless otherwise indicated.

[0018] A solution for balancing rollout speed and risk management when managing configuration changes in multiple environments is disclosed, the multiple environments being locally installed software, data sets, and machine learning (ML) and artificial intelligence (AL) models (collectively referred to as ML models), as well as software as a service (SaaS) and platform as a service (PaaS) arrangements. Aspects of the present disclosure include: receiving a second configuration item to replace a first configuration item in an exposure group; receiving an exposure state, wherein the exposure state indicates an exposure tree, the exposure tree including a first configuration item branch and a second configuration item branch; for the exposure group, determining at least based on the exposure state: a first portion of the exposure group to continue the first configuration item, and a second portion of the exposure group to receive the second configuration item; deploying the second configuration item to the second portion of the exposure group according to the exposure state; receiving an updated exposure state from a central orchestrator based at least on a first triggering event; and deploying the second configuration item according to the updated exposure state. In some examples, the exposure tree is a hierarchical binary tree.

[0019] Aspects of the present disclosure operate in an unconventional manner to improve configuration change control by gradually exposing changes (configuration changes, code updates, etc.) to an exposure group in a sequence of stages, where exposure is abstracted as a tree with different branches, which deploy (or maintain) a first configuration item or a second (replacement) configuration item that will eventually completely replace the first configuration item. That is, the rollout produces a gradual exposure within the exposure group to minimize the risk introduced by the second (replacement) configuration item. In some examples, individual tenants can customize the rollout speed seen by their managed nodes (e.g., the user's computing assets). Therefore, in an exemplary scenario where a newer software application version will replace a previous version, some nodes within the exposure group continue to utilize the previous version, while an increasing percentage of nodes receive the newer version. In some examples, when a vulnerability that requires quick fix engineering (QFE) is found in a previous version or a newer version, the QFE version is also distributed in the second layer of the relevant branch until the QFE version replaces the version with the vulnerability in the branch.

[0020] Aspects of the present disclosure can be generalized to other configuration management tasks for various large-scale operations of managed nodes (such as managed computing assets). In addition to software, other configuration items can also be managed according to the disclosure of this article, including data sets, data formatting and arrangement, documents, ML models, hardware, storage devices, and other management assets. Aspects of the present disclosure limit the scope of impact of changes in order to manage risks intelligently. The baking time between deployment increases of replacement configuration items allows vulnerability reports to be returned to the developer so that the vulnerabilities can be fixed during the rollout.

[0021] Figure 1An arrangement 100 is illustrated that advantageously employs configuration change control for managed nodes (e.g., computing assets, such as managed nodes 150a-150d and other nodes). In some examples, managed nodes 150a-150d represent physical assets. In some examples, managed nodes 150a-150d represent intangible assets, such as user accounts, user sessions, or user groups (e.g., so that the configuration is specific to the user, session, or group and is independent of the specific physical computing device being operated). In some examples, managed nodes 150a-150d represent users, user groups, and / or sessions in a SaaS environment, rather than physical hardware devices. Arrangement 100 includes a gradually exposed service 102 that serves a tenant environment 120 and another tenant environment 120a. Another gradually exposed service 102a processes (serves) tenant environments 120b and 120c. Gradually exposed services 102 and 102a operate similarly, as do tenant environments 120-120c (which manage other managed nodes not shown). In some examples, the operations described for gradually exposing service 102 are performed by Fig.11 The computing device 1100 (alone or as a cloud resource 1128 (also Fig. 9 ) is performed by computing device 1100 (alone or as part of cloud resources 1128). In some examples, the operations described for tenant environment 120 are performed by computing device 1100 (alone or as part of cloud resources 1128). In some examples, managed nodes 150a-150d each include computing device 1100. In some examples, tenant environments 120-120c poll a local (or otherwise allocated) progressive exposure service, such as one of progressive exposure services 102 and 102a. It should be understood that different numbers and arrangements of progressive exposure services and tenant environments can be used in different versions of arrangement 100.

[0022] Developer 110 generates configuration items within distribution node 112, shown as V1 (113), V1' (114) (V1 primary), V2 (115), and V2' (116) (V2 primary). In some examples, the configuration items each include a software application version. In some examples, the configuration items include data sets, ML models, and / or other items for managing configuration thereof. Figure 1 In the example shown in , configuration item V2 is scheduled to replace configuration item V1. In some examples, distribution node 112 is not a separate node (eg, cloud resource 1128), but is located in one or more of developer 110, progressive exposure service 102, and tenant environment 120.

[0023] Gradually exposing service 102 includes central orchestrator 104, which provides current exposure state 140 to tenant environment 120. Central orchestrator 104 updates exposure state 140 based on at least a triggering event, such as a signal from timer 106 or a message from developer 110 that a new configuration item is available within distribution node 112. The exposure state (e.g., exposure state 140) indicates a first configuration item branch and a second configuration item branch. In some examples, exposure state 140 indicates a binary tree including branches, the branches indicating: a first set including configuration items and empty placeholders; or a second set including first configuration item branch weights and second configuration item branch weights. Additional Details About Exposure State About Figures 3 to 6 is provided.

[0024] Tenant orchestrator 124 within tenant environment 120 polls progressive exposure service 102 (e.g., central orchestrator 104 within progressive exposure service 102) to obtain a current exposure state, and receives exposure state 140 to replace previous exposure state 140z. Thus, exposure state 140 is an updated exposure state relative to exposure state 140z. At a later time, the newer exposure state will become the updated exposure state relative to exposure state 140. In some examples, tenant orchestrator 124 polls central orchestrator 104 in response to a triggering event, such as a signal from timer 126 or a message that a new configuration item is available within distribution node 112. In some examples, progressive exposure client (GE client) 122 within tenant orchestrator 124 manages communications with progressive exposure service 102, such as communications with central orchestrator 104. In some examples, GE client 122 is a distributed component running on multiple different computing devices. In some examples, multiple instances of GE client 122 operate based on the latest exposure state 140 obtained from the gradual exposure service 102, and with the latest state, each GE client 122 is able to operate "offline" (e.g., between communication events with the gradual exposure service 102) to make local determinations and branch allocations as needed. Therefore, even if the gradual exposure service 102 becomes unavailable, the instances of GE client 122 can still operate without degradation, except for the loss of the ability to update to a more recent exposure state in a timely manner.

[0025] Some examples of tenant environment 120 also include a local data repository 128 that stores local copies of configuration items V1, V1', V2, and V2' for deployment to managed nodes 150a-150d. In some examples, deployment includes installation of a software application package, which involves multiple steps and processes on managed nodes 150a-150d. In some examples, deployment is a simpler procedure, such as distribution. In some examples, a tenant orchestrator 124 within tenant environment 120 notifies a managed node (e.g., one of managed nodes 150a-150d) which version has been assigned (see Figure 8 ), and the managed node obtains the assigned configuration item (e.g., one of V1, V1', V2, and V2') from the distribution node 112. In some examples, the deployment is a simpler procedure, such as storing a calculated configuration value based on the current exposure state 140 of the current exposure group in a memory within a computing device (e.g., one of the managed nodes 150a-150d). Once in memory, the calculated configuration value can be used by other pieces of software running on the same machine to affect their behavior. An example of such usage is a "feature flag" or "feature control bit" (FCB), which are used as control indications of the functionality of a SaaS application and can be dynamically turned on or off, such as coordinated by the gradual exposure service 102.

[0026] When one of managed nodes 150a-150d communicates with tenant orchestrator 124 regarding a configuration action (e.g., a request to install an assigned software version), using group definition 130 and node data 132, tenant orchestrator 124 is able to uniquely identify a particular managed node (e.g., managed node 150a). In some examples, node data 132 is a physical file with persistence. However, in some examples, node data 132 is ephemeral and exists only for the duration of, for example, an incoming HTTP request processed on some computing device. In such examples, node data 132 is dynamically extracted from the content of the incoming HTTP request and no longer exists thereafter. In some examples, tenant environment 120 manages multiple exposure groups. Brief Turning Towards Figure 2 , an exemplary set 200 of exposure groups is illustrated. These exposure groups represent a collection of managed nodes, and include a superset Group 1 (202) and individual groups within Group 1: Group 2 (204), Group 3 (206), Group 4 (208), and Group 5 (210). Different groups may represent nodes located in different geographic regions, computing assets assigned to different user categories (e.g., management, operations, sales, and engineering), or some other grouping criteria. The rollout steps described herein may be applied globally to Group 1 (which includes Groups 2 to 5), or independently at different rates within each of Groups 2 to 5.

[0027] The allocation logic 134 performs the actual allocation of the first or second configuration item to each of the managed nodes 150a-150d based at least on data associated with each of the managed nodes 150a-150d. The node data 132 includes an identification of information specific to one of the managed nodes 150a-150d, such as a processor serial number or an assigned name or identification number. Because some instances of the exposure state 140 include a branch weight that indicates which portion of the managed nodes (managed by the tenant environment 120) will receive the first configuration item branch weight relative to the second configuration item, the branch weight can be used as a percentage. One solution for allocating various managed nodes to one or other branches is to apply a deterministic mathematical hash function to the data of the node data 132 from a particular managed node (e.g., managed node 150a), and compare the hash value to a threshold. A deterministic operation (e.g., a hash value) is performed on the data associated with each member of the exposure group (e.g., data from the node data 132) to generate a member value. In some examples, additional data that may vary with exposure state is combined with data associated with each member of the exposure group so that the assignment is pseudo-random (e.g., appears random, but is based on a deterministic process). In some examples, the member values ​​are scaled (or the threshold is scaled) so that the threshold falls within a range of possible member values ​​at a position within the range so that a uniform probability distribution of possible member values ​​produces an assignment percentage that is approximately equal to the corresponding branch weight.

[0028] As a more specific example, the branch weight is 50% for each branch. The data associated with the managed node 150a is combined with the timestamp (or some other appropriate data) of the launch, and the combination is hashed. The hash function produces a set of bytes, and the first byte ranges from 00 to hexadecimal FF (corresponding to decimal value 256). Because the range is 0-256, the threshold is set to 128 (i.e. 50% of 256). If the first byte of the hash value is less than 128 (decimal value), the managed node is assigned the first configuration item. However, if the first byte of the hash value is 128 (decimal value) or higher, the managed node is assigned the second configuration item. For different branch weights, different thresholds can be set. In some examples, the range of known member values ​​is not uniform, so the threshold is set based on a more complex formula. As long as the expected probability distribution of member values ​​is known, the threshold can be determined. Some examples use different allocation processes. In some examples, the logic required for the allocation process (such as hash functions and threshold setting operations) is within the allocation logic 134.

[0029] In some examples, deployment component 136 deploys configuration items according to allocations from allocation logic 134, which in turn is allocated according to exposure state 140. In some examples, managed nodes 150a-150d receive their allocations from tenant orchestrator 124 and handle deployment themselves. In some examples, the allocations have a monotonic nature, meaning that as the exposure percentage increases (e.g., from zero to 100), node allocations can only go from V1 to V2 or always remain at V2, and not backwards. Similarly, as the exposure percentage decreases (e.g., rolling back from 100 to 0), node allocations can change from V2 to V1 or always remain at V1, but not the other way around.

[0030] During the rollout, problems may arise that require correction. For example, a vulnerability may be found in configuration item V1 or V2. To facilitate the required corrective measures, the collected data 138 stores data related to the performance of configuration items V1 and V2 during the rollout. In some examples, the collected data 138 is forwarded to the gradual exposure service 102 to be processed by the measurement analysis component 142 to generate measurement data 144. The vulnerability report 146 and the measurement data 144 are forwarded to the developer 110 to determine whether corrective actions such as QFE, hot fix, patch or rollback are warranted. Other possible corrective actions include: fast forward (FF) and interruption. If there is a problem in configuration item V1 but not in configuration item V2, the FF corrective action solves the problem by speeding up the rollout of configuration item V2 so that the node / user interrupts the use of configuration item V1 more quickly. In some scenarios, the FF corrective action solves any problem faster than a QFE or patch. Interruption is used to prevent additional nodes / users from receiving configuration item V2 while the developer analyzes the situation and determines the best course of action.

[0031] If a problem is reported for configuration item V1, the QFE is configuration item V1', and if a problem is reported for configuration item V2, the QFE is configuration item V2'. Concurrent deployment of configuration item V1' and / or configuration item V2' with configuration items V1 and V2 Figure 5 and Figure 6 Various triggering events are used to update the exposure state, including a new release or rollout by a developer 110, reaching the bake time of a timer event (for one of timers 106 and 126), or metric data 144 meeting some criteria.

[0032] Figure 3 The diagram shows a method of arranging 100 such as Figure 22. Exemplary stages 302 and 304 of a traffic movement operation 300 performed by a representative group of group 2. At stage 302, the gradually exposing service 102 has provided a first exposure state 140a, which has a first configuration item branch weight of 100 for the first configuration item V1 and a second configuration item branch weight of 0 (zero) for the second configuration item V2. The dynamic open set 310 of managed nodes will be configured when requests arrive. In some examples, incoming requests are not the only trigger for branch assignment. In some examples, HTTP requests or other push models act as triggers. Some examples use pull requests (e.g., reading entries from a file and processing each entry individually) as triggers in pull model implementations.

[0033] In some examples, the scope of set 310 is not known in advance, and set 310 grows in real time as new users begin using the service or new sessions are generated. In some examples, set 310 is not stored in memory as an identifiable data set, but simply represents a conceptual set of managed nodes that have been assigned or will be assigned - even if the assignments are not enumerated or recorded. In some examples, if some managed nodes are inactive, set 310 does not include the entire exposure group. Because the branch weights at stage 302 are {V1 (100), V2 (0)}, all (100%) managed nodes are assigned V1. Exposure tree 322 does not fork. For stage 304, a state change (state transition) occurs, which increases V2 to 20 (20%), which is reflected in the updated exposure state 140b. For the updated exposure state 140b, at stage 304, the branch weights are {V1 (80), V2 (20)}. Thus, 80% (the first portion) of the set 310 holds configuration item V1, and 20% (the second portion) is assigned configuration item V2, as shown in the forked exposure tree 324. The forked exposure tree 324 is a binary tree because it has two branches: V1 and V2. In some examples, the scope (or bounds) of the dynamic open set 310 and the portion are not known in advance, but are dynamic when the managed node needs to allocate (e.g., when a new user session is generated). That is, the allocation to configuration item V1 or configuration item V2 is dynamic because the incoming request grows the set 310. Thus, for example, the first set of 100 requests arrives, and the set 310 is 100, where branch V1 has 80 and branch V2 has 20. Over time, additional requests arrive, growing the set 310, and thus the portions (branches V1 and V2) grow dynamically.

[0034] Each exposure group (e.g. Figure 2Groups 2 to 5 of ) are associated with an exposure pipeline, which consists of stages (e.g., stage 302 and stage 304). Stages can depend on other stages or run simultaneously. A stage (or exposure stage) is a unit of execution and, in some examples, consists of multiple steps. A stage is a logical unit of execution entity in a pipeline, and steps run consecutively to complete a stage. During execution, the pipeline can pass through various stages. Exemplary stages include:

[0035] a) Not Started: This state occurs when an instance of the pipeline has been created but has not yet started executing.

[0036] b) Running: This state indicates that the pipeline is currently running (executing).

[0037] c) Cancelled: This state indicates that the pipeline has been canceled and cannot be resumed.

[0038] d) Stopped: This state indicates that the pipeline has stopped and no stages in the pipeline are being executed.

[0039] e) Error: This status indicates that the pipeline is in an error state and requires investigation.

[0040] f) Complete: This state indicates the completion of the pipeline.

[0041] Central orchestrator 104 provides pacing and control for rollout by launching instances of the pipeline, and executes the gradual rollout strategy indicated by the pipeline template. In some examples, central orchestrator 104 begins rollout by creating a dependency graph of stages as indicated by the pipeline template. Central orchestrator 104 then analyzes the steps in a given stage, and executes those steps sequentially within the given stage. If a request to attach a second layer (child stage) is provided to central orchestrator 104, then if the second layer indicates that the first layer (parent stage) is dependent on the completion of the second layer, then orchestrator 104 interrupts the first layer until the second layer completes its execution. In conjunction with Figure 6 Describe the scenario. The central orchestrator 104 ensures that another instance of the pipeline is not queued unless the pipeline has been set up to allow concurrent execution. In the case of parallel pipeline execution, the central orchestrator 104 ensures that the execution of the various steps of the pipeline remains in order. The central orchestrator 104 provides state changes (state transitions) of the various stages in the pipeline as well as the overall status of the pipeline.

[0042] Figure 4An exemplary exposure tree in pipeline 400 is illustrated at various stages 402-412 of configuration item rollout as performed by arrangement 100. At stage 402, initial exposure state 140c indicates branch weights {V1(100), null}, which is configuration item V1 and an empty placeholder. This gives a non-forking exposure tree 422. A state change occurs, bringing pipeline 400 to stage 404, where exposure state 140d indicates branch weights {V1(100), V2(0)}. This is a first configuration item branch weight of 100 and a second configuration item branch weight of 0 (zero), and still indicates a non-forking exposure tree 422. In stages 402 and 404, all (100%) managed nodes are receiving (or holding) configuration item V1.

[0043] Another state change occurs, bringing pipeline 400 to stage 406, where exposure state 140e indicates branch weights {V1(80), V2(20)}. This is a promotion for configuration item V2, indicating that the first configuration item branch weight is 80 and the second configuration item branch weight is 20. This indicates a bifurcated exposure tree 426, where 80% of the managed nodes (the first portion) receive (or hold) configuration item V1, and configuration item V2 is being deployed to the remaining 20% ​​(the second portion). For stage 408, another state change promotes configuration item V2 to 50, so that exposure state 140f indicates branch weights {V1(50), V2(50)}. This produces exposure tree 428, where configuration item V2 is deployed to half of the managed nodes. In some examples, the pseudo-random assignment process uses data that maintains member values ​​so that for a stable rollout, if a node has been assigned configuration item V2 at an earlier stage, it will continue to hold configuration item V2.

[0044] For stage 410, another state change promotes configuration item V2 to 100, so that exposure state 140g indicates branch weight {V1(0), V2(100)}. This produces a non-branching exposure tree 430, in which configuration item V2 is deployed to all managed nodes under the management of tenant environment 120. Note that other tenant environments (e.g., Figure 1 Tenant environments 120b and 102c) may have faster or slower rollouts, and therefore some may still be using configuration item V1. The final state change brings pipeline 400 to stage 412, where exposed state 140h indicates branch weight {V2(100), null}. Pipeline 400 is now complete. At this point, configuration item V2 has completely replaced configuration item V1 and now remains to be replaced by a future configuration item in an iteration of pipeline 400.

[0045] Figure 5An exemplary hierarchical exposure tree at various stages of a pipeline 500 for configuration item rollout is illustrated. In pipeline 500, there is a QFE for configuration item V1, which produces an updated configuration item V1' and produces a hierarchical exposure tree. At stage 502, exposure state 140j indicates branch weights {V1(50), V2(50)}. This gives a binary exposure tree 522. The V1 branch of tree 522 is a set 520 of management nodes for the second layer. Exposure state 540a indicates branch weights {V1(100), V1'(0)}, so initially, the second layer is a non-branching tree 5222. Exposure state 540a is the configuration item branch exposure state. A state change occurs at the second layer, bringing pipeline 500 to stage 504. The first layer is still in exposed state 140j, but the second layer now has exposed state 540b, which indicates the branch weights {V1(50), V1'(50)}. Exposed state 540b is also a configuration item branch exposed state. This produces a bifurcated tree 5242, in which half of the set 520 (part of the exposed group) holds configuration item V1, and the other half of the set 520 (the other part of the exposed group) receives the deployment of the updated configuration item V1'. This is an example of a hierarchical binary tree, because the tree 522 at the first layer is binary, and the tree 5242 at the second layer (branching from one side of the tree 522) is also binary. At stage 504, half of the set 310 receives configuration item V2, one quarter (half of the half) holds configuration item V1, and one quarter receives the updated configuration item V1'.

[0046] In the example shown, two state changes occur next, one for each tier, bringing pipeline 500 to stage 506. Exposed state 140j is replaced by exposed state 140k, which indicates branch weights {V1(25), V2(75)}, which produces bifurcated tree 526. Set 520 now has only one-quarter of set 310, down from one-half (it had one-half at stage 504). Exposed state 540b is replaced by exposed state 540c, which indicates branch weights {V1(0), V1'(100)}, which produces unbranched tree 5262. At stage 506, three-quarters of set 310 receive configuration item V2, and one-quarter of set 310 (now all of set 520) receives updated configuration item V1'.

[0047] For stage 508, another state change replaces exposed state 140k with exposed state 140m, which indicates branch weights {V1'(25), V2(75)}. The actual result is the same as stage 506, where three-quarters of the set 310 receive configuration item V2 and one-quarter of the set 310 receives the updated configuration item V1'. The main difference is nominal. At stage 508, pipeline 500 has been collapsed to only a single layer with bifurcating tree 528. Another state change brings pipeline 500 to stage 510, where exposed state 140n indicates branch weights {V1'(0), V2(100)}. This produces a non-bifurcating tree 530, where all of the set 310 receives configuration item V2. The final illustrated stage 512 results from a state change to exposed state 140p, which indicates branch weights {V2(100), null}. At this point, configuration item V2 has replaced configuration item V1 and the temporarily deployed updated configuration item V1'.

[0048] For pipeline 500, initiating a QFE rollout for updated configuration item V1' does not interrupt the rollout of configuration item V2. This is because if no vulnerability is identified in configuration item V2, the gradual exposure of configuration item V2 should continue normally.

[0049] Figure 6 Also illustrated are exemplary hierarchical exposure trees at various stages of a configuration item rollout as performed by arrangement 100. In pipeline 600, there is a QFE for configuration item V2, which produces an updated configuration item V2', and also produces a hierarchical exposure tree. Compared to pipeline 500, for pipeline 600, initiating the QFE rollout of configuration item V2' does interrupt the rollout of configuration item V2. This is because, if a vulnerability is identified in configuration item V2, the gradual exposure of configuration item V2 should be interrupted to contain the problem until a solution (QFE-updated configuration item V2') becomes available. Therefore, in some examples, the deployment of configuration item V2 is interrupted until the updated configuration item V2' is received, and then the deployment of the second configuration item V2 is resumed.

[0050] At stage 602, exposure state 140q indicates branch weights {V1(50), V2(50)}. This gives a binary exposure tree 622. The V2 branch of tree 622 is the set 620 of managed nodes for the second tier. Exposure state 640a indicates branch weights {V2(100), V2'(0)}, so initially, the second tier is a non-branching tree 6222. Exposure state 640a is the configuration item branch exposure state. A state change occurs at the second tier, bringing pipeline 600 to stage 604. The first tier is still in exposure state 140q, but the second tier now has exposure state 640b indicating branch weights {V2(50), V2'(50)}. This results in a bifurcated tree 6242, where half of set 620 receives configuration item V2, and the other half of set 620 receives a deployment that updates configuration item V2'. This is another example of a hierarchical binary tree, as tree 622 at the first level is binary, and tree 6242 at the second level (branching from one side of tree 622) is also binary. At stage 604, half of set 310 holds configuration item V1, a quarter (half of the half, a portion of set 310) receives configuration item V2, and a quarter (the other portion) receives updated configuration item V2'.

[0051] In the example shown, only one state change occurs next, bringing pipeline 600 to stage 606. The first layer is interrupted and therefore remains in exposed state 140k. Exposed state 640b is replaced by exposed state 640c, which indicates branch weights {V2(0), V2'(100)}, which produces a non-branching tree 6262. Exposed state 640b is also a configuration item branch exposed state. At stage 606, half (a portion) of set 310 retains configuration item V1, and half of set 310 (the other portion that now includes all of set 620) receives the updated configuration item V2'. Configuration item V2 is now completely replaced and is no longer deployed.

[0052] For stage 608, another state change replaces exposed state 140q with exposed state 140s, which indicates branch weights {V1(50), V2'(50)}. The actual result is the same as stage 606, with half of set 310 receiving updated configuration item V2' and half of set 310 receiving configuration item V1. The main difference is nominal. At stage 608, pipeline 600 has been collapsed to only a single layer with bifurcating tree 628. Another state change brings pipeline 600 to stage 610, where exposed state 140t indicates branch weights {V1(0), V2'(100)}. This produces a non-bifurcating tree 630, where all of set 310 receives updated configuration item V2'. The final illustrated stage 612 results from a state change to exposed state 140u, which indicates branch weights {V2'(100), null}. At this point, the updated configuration item V2' has replaced the configuration item V1 and the temporarily deployed configuration item V2.

[0053] Back to Figure 1 , arrangement 100 provides a solution for managing configuration change control. In operation, aspects of arrangement 100 receive a second configuration item V2 to replace a first configuration item V1 in an exposure group; receive an exposure state 140 from a central orchestrator 104, wherein the exposure state 140 indicates an exposure tree including a first configuration item branch and a second configuration item branch; determine, for the exposure group, at least based on the exposure state 140: a first portion of the exposure group to continue the first configuration item V1, and a second portion of the exposure group to receive the second configuration item V2; deploy the second configuration item V2 to the second portion of the exposure group according to the exposure state; receive an updated exposure state (e.g., exposure state 140a) from the central orchestrator 104 based on at least a first trigger event; and deploy the second configuration item V2 according to the updated exposure state.

[0054] In some examples, the first configuration item and the second configuration item each include a software application version. In some examples, the operation includes: providing the exposure state 140 (or a subsequent exposure state) at the central orchestrator 104; and updating the exposure state at the central orchestrator 104 based on at least a second triggering event. In some examples, the exposure state indication includes a binary tree of branches, the branch indications including: a first set of configuration items and empty placeholders; or a second set of first configuration item branch weights and second configuration item branch weights. In some examples, determining the first portion of the exposure group and the second portion of the exposure group includes: determining a threshold based on at least the first configuration item branch weight or the second configuration item branch weight; performing a deterministic operation on data associated with each member of the exposure group to generate a member value; for at least one member of the exposure group, comparing the threshold to the member value; and assigning at least one member of the exposure group to the first portion of the exposure group or the second portion of the exposure group based on at least the comparison.

[0055] In some examples, the operation includes: generating a hierarchical exposure tree by further branching the first configuration item branch or the second configuration item branch. In some examples, further branching the first configuration item branch includes: receiving an updated first configuration item V1' to replace the first configuration item V1; receiving a first configuration item branch exposure state, wherein the first configuration item branch exposure state indicates an exposure tree branch, the exposure tree branch including the original first configuration item branch and the updated first configuration item branch; determining at least based on the exposure state: a third portion of the exposure group to continue the first configuration item V1, and a fourth portion of the exposure group to receive the updated first configuration item V1'; and deploying the updated first configuration item V1' to the fourth portion of the exposure group according to the first configuration item branch exposure state and the exposure state.

[0056] In some examples, further branching the second configuration item branch includes: receiving an updated second configuration item V2' to replace the second configuration item V2; receiving a second configuration item branch exposure state, wherein the second configuration item branch exposure state indicates an exposure tree branch, the exposure tree branch including the original second configuration item branch and the updated second configuration item branch; determining at least based on the exposure state: the fifth portion of the exposure group to continue the second configuration item V2, and the sixth portion of the exposure group to receive the updated second configuration item V2'; deploying the second configuration item V2 to the fifth portion of the exposure group based on the second configuration item branch exposure state and the exposure state; and deploying the updated second configuration item V2' to the sixth portion of the exposure group based on the second configuration item branch exposure state and the exposure state. In some examples, the operation includes: interrupting the deployment of the second configuration item V2 based at least on a third trigger event; and resuming the deployment of the second configuration item V2 based at least on receiving the updated second configuration item V2'.

[0057] Fig. 7Aand Figure 7B Pseudo-code of an exemplary JavaScript Object Notation (JSON) configuration file 700 is shown for managing configuration changes as performed by arrangement 100 . Fig. 7A and Figure 7B should be considered a continuous list, where Figure 7B Section 700b follows Fig. 7A In the example shown, file 700 defines a pipeline for deploying a configuration item named "TestApplication" to an exposure group named "Group2" in two geographic regions: western_us (western United States) and eastern_us (eastern United States). The gradual exposure type is a ramp percentage, with Figure 5 and Figure 6 There are three different branch weights: {0, 100}; {50, 50} and {100, 0}. In some examples, a large number of different branch weights are used, for example: {0, 100}; {25, 75}; {50, 50}; {75, 25} and {100, 0}; or {0, 100}; {20, 80}; {40, 60}; {60, 40}; {80, 20} and {100, 0}.

[0058] The exposure pivot can be defined by the tenant, and in the example shown, it is set to the environment ID. When polling the central orchestrator 104, the tenant orchestrator provides its exposure pivot to identify its request for the current exposure state. This is because the gradual exposure service 102 can serve multiple tenant environments (e.g., tenant environments 120 and 102a) and multiple tiers (e.g., exposure states 140k and 540c). Other aspects of the file 700 indicate that the wait time for each state is one hour (3600 seconds), and that performance data is collected (e.g., collected data 138) for analysis and to generate metrics data 144.

[0059] Figure 8 An exemplary messaging sequence 800 performed within arrangement 100 is illustrated. Developer 110 sends message 802 to central orchestrator 104 to start a pipeline (e.g., to start a new rollout). Central orchestrator 104 begins coordination of the new pipeline with message 804 to tenant orchestrator 124. Central orchestrator 104 and tenant orchestrator 124 establish timers for triggering state changes and polling for state changes. Developer 110 also begins sending a series of pipeline status messages 806a-806f to central orchestrator 104 to indicate to central orchestrator 104 whether the rollout is proceeding normally, whether the pipeline is interrupted for QFE, or whether a QFE configuration item is available and will be added to the pipeline.

[0060] Tenant orchestrator 124 begins polling central orchestrator 104 for state changes using messages 808a-808e, and receives the current exposure state from central orchestrator 104. Managed node 150a sends configuration action message 810a to tenant orchestrator 124, requesting a configuration management operation, such as deploying a new configuration item or verifying that an existing configuration item at managed node 150a is the currently assigned configuration item. Tenant orchestrator 124 determines the configuration item to be assigned to managed node 150a in process 812a, and sends message 814a to notify managed node 150a of the assigned configuration item. In some scenarios, message 814a assigns the new configuration item to managed node 150a. Managed node 150b sends configuration action message 810b to tenant orchestrator 124, requesting a configuration management operation. Tenant orchestrator 124 determines the configuration items to be assigned to managed node 150b in process 812b and sends message 814b to notify managed node 150b of the assigned configuration items.

[0061] When the exposed status indicates that the pipeline is complete, tenant orchestrator 124 sends message 810 to developer 110 and message 812 to tenant orchestrator 124 indicating that the pipeline is complete. Developer 110 then interrupts a series of pipeline status messages, and tenant orchestrator 124 interrupts polling central orchestrator 104 for status changes.

[0062] Fig. 9 900 is a flowchart illustrating exemplary operations involved in configuration change control as performed by arrangement 100. In some examples, the operations described with respect to flowchart 900 are performed by Fig.11 1100 is executed by the computing device 1100. Flowchart 900 starts at operation 902, where the developer generates a second configuration item to replace the first configuration item in the exposure group. The push is used as a trigger event. Operation 904 includes: receiving a second configuration item to replace the first configuration item in the exposure group. In some examples, the first configuration item and the second configuration item both include software application versions. Operation 906 includes providing an exposure state at a central orchestrator, wherein the exposure state indicates a binary exposure tree including a first configuration item branch and a second configuration item branch. In some examples, the branch indicates: a first set including configuration items and empty placeholders, or a second set including a first configuration item branch weight and a second configuration item branch weight.

[0063] Operation 906 repeats with respect to a triggering event, such as a timer event. Operation 906 also repeats when triggered on metric data from operation 926. In a subsequent pass, operation 906 includes: updating the exposure state at the central orchestrator based on at least the first triggering event. The flowchart returns to operation 906 at multiple points, such as deciding an option of operation 930, and when operations 932 and 950 are completed. Flowchart 900 also ends when operation 906 reaches a completion state for the pipeline. However, if completion has not yet been reached, flowchart 900 proceeds to operation 908.

[0064] Operation 908 includes receiving an exposure state from a central orchestrator. Operation 908 is also repeated with respect to a triggering event, such as a second timer event or some other event. In a subsequent transfer, operation 908 includes: receiving an updated exposure state from a central orchestrator based at least on a second triggering event. Operation 910 includes: determining, for an exposure group, at least based on the exposure state: a first portion of the exposure group to continue with a first configuration item, and a second portion of the exposure group to receive a second configuration item. In some examples, operation 910 includes operations 912-918. In operation 912, a branch weight is determined from the exposure state. Operation 914 includes: determining a threshold based at least on the first configuration item branch weight or the second configuration item branch weight. Operation 916 includes: performing a deterministic operation on data associated with each member of the exposure group to generate a member value, and operation 918 includes: for at least one member of the exposure group, comparing the threshold to the member value. Operation 920 includes: at least based on the comparison, assigning at least one member of the exposure group to the first portion of the exposure group or the second portion of the exposure group. Then, operation 922 includes: deploying the second configuration item to a second portion of the exposure group according to the exposure status. In a subsequent pass, operation 922 includes deploying the second configuration item according to the updated exposure status.

[0065] Performance data indicative of rollout stability is collected in operation 924 and received by an analysis node, such as a progressive exposure service or another node. In operation 926, a metric analysis is performed on the collected data. The metric data may indicate sufficient stability to proceed to the next exposure state. If so, flowchart 900 returns to operation 906, in which an exposure state change is triggered on the metric data. However, if there are any performance issues, such as vulnerabilities, a vulnerability report is received in operation 928. Decision operation 930 determines whether a QFE is required. If not, flowchart 900 returns to operation 906. There are two QFE possibilities: the first configuration item requires a QFE, and / or the second configuration item requires a QFE.

[0066] If the first configuration item requires a QFE, operation 932 includes generating a hierarchical exposure tree by further branching the first configuration item branch. In some examples, operation 932 includes operations 934-942. Operation 934 includes receiving an updated first configuration item to replace the first configuration item. Operation 936 includes receiving a first configuration item branch exposure state. In some examples, the first configuration item branch exposure state indicates an exposure tree branch including an original first configuration item branch and an updated first configuration item branch. In operation 938, an allocation is determined, similar to that in operation 910, but for a second tier. For example, operation 938 includes determining, based at least on the exposure state: a third portion of the exposure group to continue the first configuration item, and a fourth portion of the exposure group to receive the updated first configuration item. Operation 940 includes: deploying the updated first configuration item to a fourth portion of the exposure group according to the first configuration item branch exposure state. The state of the second layer pipeline is exhausted, so that the second layer pipeline is completed in operation 942. Flowchart 900 then returns to operation 906.

[0067] If the second configuration item requires a QFE, operation 950 includes generating a hierarchical exposure tree by further branching the second configuration item branch. In some examples, operation 950 includes operations 952-966. Operation 952 includes: interrupting deployment of the second configuration item based on at least a third triggering event. In some examples, the third triggering event is a vulnerability report received in operation 928. Operation 954 includes receiving an updated second configuration item to replace the second configuration item, and operation 956 includes: resuming deployment of the second configuration item based on at least receiving the updated second configuration item.

[0068] Operation 958 includes receiving a second configuration item branch exposure state. In some examples, the second configuration item branch exposure state indicates an exposure tree branch including an original second configuration item branch and an updated second configuration item branch. In operation 960, an allocation is determined, similar to that in operation 910, but for the second tier. For example, operation 960 includes determining, based at least on the exposure state: a fifth portion of the exposure group to continue the second configuration item, and a sixth portion of the exposure group to receive the updated second configuration item. Operation 962 includes: deploying the second configuration item to the fifth portion of the exposure group according to the second configuration item branch exposure state. Operation 964 includes: deploying the updated second configuration item to the sixth portion of the exposure group according to the second configuration item branch exposure state. The state of the second layer pipeline is exhausted, so that the second layer pipeline is completed in operation 966. Flowchart 900 then returns to operation 906.

[0069] Fig.10 1000 is a flowchart illustrating exemplary operations involved in configuration change control as performed by arrangement 100. In some examples, the operations described with respect to flowchart 1000 are performed by Fig.111100 is executed by a computing device 1100. Flowchart 1000 begins at operation 1002, which includes receiving a second configuration item to replace a first configuration item in an exposure group. Operation 1004 includes receiving an exposure state from a central orchestrator, wherein the exposure state indicates an exposure tree including a first configuration item branch and a second configuration item branch. Operation 1006 includes: for the exposure group, determining, based at least on the exposure state: a first portion of the exposure group to continue with the first configuration item, and a second portion of the exposure group to receive the second configuration item.

[0070] Operation 1008 includes: deploying a second configuration item to a second portion of the exposure group based on the exposure status. Operation 1010 includes: receiving an updated exposure status from a central orchestrator based at least on the first triggering event. Operation 1012 includes: deploying a second configuration item based on the updated exposure status.

[0071] Additional Examples

[0072] Some aspects and examples disclosed herein are directed to a system for managing configuration changes, comprising: a processor; and a computer-readable medium storing instructions, which, when executed by the processor, are operable to: receive a second configuration item to replace a first configuration item in an exposure group; receive an exposure state from a central orchestrator, wherein the exposure state indicates an exposure tree, the exposure tree comprising a first configuration item branch and a second configuration item branch; for the exposure group, determine, based at least on the exposure state: a first portion of the exposure group to continue with the first configuration item, and a second portion of the exposure group to receive the second configuration item; deploy the second configuration item to the second portion of the exposure group based on the exposure state; receive an updated exposure state from the central orchestrator based at least on a first trigger event; and deploy the second configuration item based on the updated exposure state.

[0073] Additional aspects and examples disclosed herein are directed to a method of configuration change control, comprising: receiving a second configuration item to replace a first configuration item in an exposure group; receiving an exposure state from a central orchestrator, wherein the exposure state indicates an exposure tree, the exposure tree including a first configuration item branch and a second configuration item branch; determining, for the exposure group, based at least on the exposure state: a first portion of the exposure group to continue with the first configuration item, and a second portion of the exposure group to receive the second configuration item; deploying the second configuration item to the second portion of the exposure group based on the exposure state; receiving an updated exposure state from the central orchestrator based at least on a first trigger event; and deploying the second configuration item based on the updated exposure state.

[0074] Additional aspects and examples disclosed herein are directed to one or more computer storage devices having computer executable instructions for configuration change control stored thereon, which when executed by a computer cause the computer to perform operations, the operations comprising: receiving a second configuration item to replace a first configuration item in an exposure group, wherein the first configuration item and the second configuration item both comprise software application versions; providing an exposure status at a central orchestrator, wherein the exposure status indicates a binary exposure tree, the binary exposure tree comprising a first configuration item branch and a second configuration item branch, the branch indicating: a first set comprising configuration items and empty placeholders, or a second set comprising a first configuration item branch weight and a second configuration item branch weight; receiving the exposure status from the central orchestrator; and determining, for the exposure group, based at least on the exposure status: a first portion of the exposure group to continue with the first configuration item, and a second part of the exposure group to receive a second configuration item, wherein determining the first part of the exposure group and the second part of the exposure group includes: determining a threshold based at least on the first configuration item branch weight or the second configuration item branch weight; performing a deterministic operation on data associated with each member of the exposure group to generate a member value; comparing the threshold with the member value for at least one member of the exposure group; and assigning at least one member of the exposure group to the first part of the exposure group or the second part of the exposure group based at least on the comparison; deploying the second configuration item to the second part of the exposure group based on the exposure status; updating the exposure status at the central orchestrator based at least on the first trigger event; receiving the updated exposure status from the central orchestrator based at least on the second trigger event; and deploying the second configuration item based on the updated exposure status.

[0075] As an alternative or in addition to other examples described herein, examples include any combination of the following:

[0076] - Both the first configuration item and the second configuration item include a software application version;

[0077] -Provide exposure status at the central orchestrator;

[0078] -updating the exposure status at the central orchestrator based on at least the second triggering event;

[0079] - an exposure status indication comprising a binary tree of branches, the branch indicating: a first set including configuration items and empty placeholders; or a second set including a first configuration item branch weight and a second configuration item branch weight;

[0080] - determining a first portion of the exposure group and a second portion of the exposure group comprises: determining a threshold value based on at least the first configuration item branch weight or the second configuration item branch weight; performing a deterministic operation on data associated with each member of the exposure group to generate a member value; comparing the threshold value to the member value for at least one member of the exposure group; and assigning the at least one member of the exposure group to the first portion of the exposure group or the second portion of the exposure group based at least on the comparison;

[0081] -determining a threshold value based on at least the first configuration item branch weight or the second configuration item branch weight;

[0082] - performing a deterministic operation on the data associated with each member of the exposure group to generate a member value;

[0083] - for at least one member of the exposure group, comparing the threshold value to the member value;

[0084] - assigning at least one member of the exposure group to the first portion of the exposure group or to the second portion of the exposure group based at least on the comparison;

[0085] - generating a hierarchical exposure tree by further branching the first configuration item branch or the second configuration item branch;

[0086] -Further branching the first configuration item branch includes: receiving an updated first configuration item for replacing the first configuration item; receiving a first configuration item branch exposure status, wherein the first configuration item branch exposure status indicates an exposure tree branch, and the exposure tree branch includes an original first configuration item branch and an updated first configuration item branch; based at least on the exposure status, determining: a third part of the exposure group to continue the first configuration item, and a fourth part of the exposure group to receive the updated first configuration item; and deploying the updated first configuration item to the fourth part of the exposure group based on the first configuration item branch exposure status and the exposure status.

[0087] - receiving an updated first configuration item for replacing the first configuration item;

[0088] - receiving a first configuration item branch exposure state, wherein the first configuration item branch exposure state indicates an exposure tree branch, and the exposure tree branch includes an original first configuration item branch and an updated first configuration item branch;

[0089] - based at least on the exposure status, determining: a third portion of the exposure group to continue the first configuration item, and a fourth portion of the exposure group to receive an updated first configuration item;

[0090] -deploy the updated first configuration item to the fourth part of the exposure group according to the first configuration item branch exposure status and the exposure status;

[0091] -Further branching the second configuration item branch includes: receiving an updated second configuration item for replacing the second configuration item; receiving a second configuration item branch exposure state, wherein the second configuration item branch exposure state indicates an exposure tree branch, the exposure tree branch including an original second configuration item branch and an updated second configuration item branch; based at least on the exposure state, determining: a fifth portion of the exposure group to continue with the second configuration item, and a sixth portion of the exposure group to receive the updated second configuration item; deploying the second configuration item to the fifth portion of the exposure group based on the second configuration item branch exposure state and the exposure state; and deploying the updated second configuration item to the sixth portion of the exposure group based on the second configuration item branch exposure state and the exposure state;

[0092] - receiving an updated second configuration item for replacing the second configuration item;

[0093] - receiving a second configuration item branch exposure state, wherein the second configuration item branch exposure state indicates an exposure tree branch, and the exposure tree branch includes an original second configuration item branch and an updated second configuration item branch;

[0094] - Based on at least the exposure status, determine:

[0095] - The fifth part of the exposure group, to continue the second configuration item, and

[0096] - a sixth part of the exposure group to receive an updated second configuration item;

[0097] -deploy the second configuration item to a fifth part of the exposure group according to the second configuration item branch exposure status and the exposure status; and

[0098] -Deploy the updated second configuration item to the sixth part of the exposure group according to the exposure status and exposure status of the second configuration item branch;

[0099] - based on at least a third triggering event, interrupting the deployment of the second configuration item;

[0100] - based at least on receiving the updated second configuration item, resuming deployment of the second configuration item.

[0101] Although aspects of the disclosure have been described in terms of various examples and their associated operations, those skilled in the art will appreciate that combinations of operations from any number of the different examples are also within the scope of aspects of the disclosure.

[0102] Example operating environment

[0103] Fig.111 is a block diagram of an example computing device 1100 for implementing aspects disclosed herein, and is generally designated as computing device 1100. Computing device 1100 is only an example of a suitable computing environment, and is not intended to imply any limitation on the scope of use or functionality of the examples disclosed herein. Computing device 1100 should also not be interpreted as having any dependency or requirement on any one component / module or combination of components / modules described. The examples disclosed herein can be described in the general context of computer code or machine-usable instructions, including computer executable instructions executed by a computer or other machine (such as a personal data assistant or other handheld device), such as program components. Typically, program components (including routines, programs, objects, components, data structures, etc.) refer to codes that perform specific tasks or implement specific abstract data types. The disclosed examples can be practiced in various system configurations, including personal computers, laptop computers, smart phones, mobile tablets, handheld devices, consumer electronics, professional computing devices, etc. When tasks are performed by remote processing devices linked through a communication network, the disclosed examples can also be practiced in a distributed computing environment.

[0104] The computing device 1100 includes a bus 1110 that directly or indirectly couples the following devices: computer storage memory 1112, one or more processors 1114, one or more presentation components 1116, I / O ports 1118, I / O components 1120, power supply 1122, and network components 1124. Although the computing device 1100 is depicted as a seemingly single device, multiple computing devices 1100 can work together and share the depicted device resources. For example, the memory 1112 can be distributed across multiple devices, and the (multiple) processors 1114 can be housed with different devices.

[0105] Bus 1110 represents what may be one or more buses (such as an address bus, a data bus, or a combination thereof). Although shown with lines for clarity, Fig.11 , depicting various components may be accomplished using alternative representations. For example, in some examples, presentation components such as display devices are I / O components, and some examples of processors have their own memory. No distinction is made between categories such as "workstation," "server," "laptop," "handheld device," etc., as all are expected to be in the Fig.11and within the scope of references to "computing device" herein. Memory 1112 may take the form of computer storage media referenced below and is operable to provide storage of computer-readable instructions, data structures, program modules, and other data for computing device 1100. In some examples, memory 1112 stores one or more of: an operating system, a general-purpose application platform, or other program modules and program data. Thus, memory 1112 is capable of storing and accessing data 1112a and instructions 1112b, which are executable by processor 1114 and are configured to implement various operations disclosed herein.

[0106] In some examples, memory 1112 includes computer storage media in the form of volatile and / or nonvolatile memory, removable or non-removable memory, data disks in a virtual environment, or a combination thereof. Memory 1112 may include any number of memories associated with or accessible by computing device 1100. Memory 1112 may be internal to computing device 1100 (e.g., Fig.11 ), external to computing device 1100 (not shown), or both (not shown). Examples of memory 1112 include, but are not limited to, random access memory (RAM); read-only memory (ROM); electronically erasable programmable read-only memory (EEPROM); flash memory or other memory technology; CD-ROM, digital versatile disk (DVD) or other optical or holographic media; cassettes, magnetic tape, disk storage or other magnetic storage devices; memory wired to an analog computing device; or any other medium for encoding the desired information and accessed by computing device 1100. Additionally or alternatively, memory 1112 may be distributed across multiple computing devices 1100, for example, in a virtualized environment where instruction processing is performed on multiple devices 1100. For purposes of this disclosure, "computer storage media," "computer storage memory," "memory," and "memory device" are synonymous terms for computer storage memory 1112, and none of these terms include carrier waves or propagating signaling.

[0107] (Multiple) processors 1114 may include any number of processing units that read data from various entities (such as memory 1112 or I / O components 1120). Specifically, (multiple) processors 1114 are programmed to execute computer executable instructions to implement aspects of the present disclosure. Instructions can be executed by a processor, by multiple processors within the computing device 1100, or by a processor external to the client computing device 1100. In some examples, (multiple) processors 1114 are programmed to execute instructions, such as those illustrated in the flowcharts discussed below and depicted in the accompanying drawings. In addition, in some examples, (multiple) processors 1114 represent implementations of simulation techniques for performing the operations described herein. For example, operations can be performed by a simulated client computing device 1100 and / or a digital client computing device 1100. (Multiple) presentation components 1116 present data indications to a user or other device. Exemplary presentation components include display devices, speakers, printing components, vibration components, etc. Those skilled in the art will understand and appreciate that computer data may be presented in a variety of ways, such as visually in a graphical user interface (GUI), audibly through a speaker, wirelessly between computing devices 1100, across a wired connection, or otherwise. I / O ports 1118 allow computing device 1100 to be logically coupled to other devices including I / O components 1120, some of which may be built-in. Example I / O components 1120 include, for example, but are not limited to, microphones, joysticks, game controllers, satellite dishes, scanners, printers, wireless devices, and the like.

[0108] The computing device 1100 can operate in a networked environment using logical connections to one or more remote computers via a network component 1124. In some examples, the network component 1124 includes a network interface card and / or computer executable instructions (e.g., a driver) for operating a network interface card. Communications between the computing device 1100 and other devices can be conducted over any wired or wireless connection using any protocol or mechanism. In some examples, the network component 1124 can be operable to communicate wirelessly using short-range communication technologies (e.g., near field communication (NFC), Bluetooth TM The network component 1124 communicates with the cloud resources 1128 across the network 1130 via wireless communication links 1126 and / or wired communication links 1126a. Various different examples of communication links 1126 and 1126a include wireless connections, wired connections, and / or dedicated links, and in some examples, at least a portion is routed through the Internet.

[0109] Although described in conjunction with the example computing device 1100, the examples of the present disclosure can be implemented using many other general or special computing system environments, configurations, or devices. Examples of well-known computing systems, environments, and / or configurations that may be suitable for use with aspects of the present disclosure include, but are not limited to, smartphones, mobile tablets, mobile computing devices, personal computers, server computers, handheld or laptop devices, multiprocessor systems, game consoles, microprocessor-based systems, set-top boxes, programmable consumer electronics, mobile phones, mobile computing and / or communication devices in wearable or accessory form factors (e.g., watches, glasses, headphones, or earpieces), network PCs, minicomputers, mainframe computers, distributed computing environments including any of the above systems or devices, virtual reality (VR) devices, augmented reality (AR) devices, mixed display (MR) devices, holographic devices, etc. Such systems or devices can accept input from a user (including from an input device such as a keyboard or pointing device) in any manner via gesture input, proximity input (such as by hovering), and / or via voice input.

[0110] Examples of the present disclosure may be described in the general context of computer executable instructions such as program modules executed by one or more computers or other devices in software, firmware, hardware or a combination thereof. Computer executable instructions may be organized into one or more computer executable components or modules. Typically, program modules include, but are not limited to, routines, programs, objects, components, and data structures that perform specific tasks or implement specific abstract data types. Aspects of the present disclosure may be implemented using any number and organization of such components or modules. For example, aspects of the present disclosure are not limited to specific computer executable instructions or specific components or modules shown in the figures and described herein. Other examples of the present disclosure may include different computer executable instructions or components with more or less functionality than that shown and described herein. In an example involving a general-purpose computer, when configured to execute instructions described herein, aspects of the present disclosure convert the general-purpose computer into a special-purpose computing device.

[0111] As an example and not limitation, computer-readable media include computer storage media and communication media. Computer storage media include volatile and non-volatile memory, removable and non-removable memory implemented in any method or technology for storing information such as computer-readable instructions, data structures, program modules, etc. Computer storage media are tangible media and are mutually exclusive with communication media. Computer storage media are implemented in hardware and exclude carriers and propagation signals. For the purposes of this disclosure, computer storage media themselves are not signals. Exemplary computer storage media include hard disks, flash drives, solid-state memories, phase change random access memories (PRAM), static random access memories (SRAM), dynamic random access memories (DRAM), other types of random access memories (RAM), read-only memories (ROM), electrically erasable programmable read-only memories (EEPROM), flash memory or other memory technologies, compact disk read-only memories (CD-ROM), digital versatile disks (DVD) or other optical storage, cassettes, tapes, disk storage devices or other magnetic storage devices, or any other non-transmission media that can be used to store information for access by a computing device. In contrast, communication media typically embodies computer readable instructions, data structures, program modules, etc. in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media.

[0112] The execution (execution) or the order of execution (performance) of the operation in the example of the present disclosure shown and described herein is not necessary, and can be executed in different sequential ways in various examples.For example, it is expected that before, simultaneously or afterwards another operation, executing (executing) or performing (performing) a specific operation is within the scope of the various aspects of the present disclosure.When introducing the elements of various aspects of the present disclosure or its examples, the articles "one", "one", "the" and "said" are intended to represent one or more elements in the element.The terms "comprising", "including" and "having" are intended to be inclusive, and mean that there may be additional elements in addition to the listed elements.The term "exemplary" is intended to mean "an example of...". The phrase "one or more of the following: A, B and C" means "at least one of A and / or at least one of B and / or at least one of C".

[0113] Having described various aspects of the disclosure in detail, it will be apparent that modifications and variations are possible without departing from the scope of various aspects of the disclosure as defined in the appended claims. As various changes may be made to the above-described constructions, products and methods without departing from the scope of various aspects of the disclosure, it is intended that all matter contained in the above description and shown in the accompanying drawings shall be interpreted as illustrative rather than in a limiting sense.

Claims

1. A system for managing configuration changes, the system comprising: processor; as well as A computer readable medium storing instructions that, when executed by the processor, are operable to: receiving a second configuration item for replacing the first configuration item in the exposure group; receiving an exposure status from a central orchestrator, wherein the exposure status indicates an exposure tree, the exposure tree comprising a first configuration item branch and a second configuration item branch; For the exposure group, based at least on the exposure status, determine: a first portion of the exposure group to continue the first configuration item, and a second portion of the exposure group to receive the second configuration item; deploying the second configuration item to the second part of the exposure group according to the exposure status; receiving an updated exposure status from the central orchestrator based on at least a first triggering event; as well as The second configuration item is deployed according to the updated exposure status. 2 . The system according to claim 1 , wherein the first configuration item and the second configuration item each comprise a software application version.

3. The system of claim 1, wherein the instructions are further operable to: providing the exposure status at the central orchestrator; and Based on at least a second triggering event, the exposure status is updated at the central orchestrator.

4. The system of claim 1 , wherein the exposure status indication comprises a branched binary tree, the branch indications: The first set, including configuration items and empty placeholders, or The second set includes the first configuration item branch weight and the second configuration item branch weight.

5. The system of claim 4, wherein determining the first portion of the exposure group and the second portion of the exposure group comprises: Determining a threshold based at least on the first configuration item branch weight or the second configuration item branch weight; performing a deterministic operation on data associated with each member of the exposure group to generate a member value; for at least one member of the exposure group, comparing the threshold to the member value; as well as Based at least on the comparison, the at least one member of the exposure group is monotonically assigned to the first portion of the exposure group or the second portion of the exposure group.

6. The system of claim 1, wherein the instructions are further operable to: A hierarchical exposure tree is generated by further branching the first configuration item branch or the second configuration item branch.

7. The system according to claim 6, wherein further branching the first configuration item branch comprises: receiving an updated first configuration item for replacing the first configuration item; receiving a first configuration item branch exposure state, wherein the first configuration item branch exposure state indicates: an exposure tree branch including an original first configuration item branch and an updated first configuration item branch; Based at least on the exposure status, determine: a third portion of the exposure group, continuing with the first configuration item, and a fourth portion of the exposure group to receive the updated first configuration item; as well as The updated first configuration item is deployed to the fourth part of the exposure group according to the first configuration item branch exposure state and the exposure state.

8. The system according to claim 6, wherein further branching the second configuration item branch comprises: receiving an updated second configuration item for replacing the second configuration item; receiving a second configuration item branch exposure state, wherein the second configuration item branch exposure state indicates an exposure tree branch including an original second configuration item branch and an updated second configuration item branch; Based at least on the exposure status, determine: a fifth portion of the exposure group to continue the second configuration item, and a sixth portion of the exposure group to receive the updated second configuration item; deploying the second configuration item to the fifth part of the exposure group according to the second configuration item branch exposure state and the exposure state; as well as Deploy the updated second configuration item to the sixth part of the exposure group according to the second configuration item branch exposure state and the exposure state.

9. The system of claim 8, wherein the instructions are further operable to: Based at least on a third triggering event, interrupting the deployment of the second configuration item; and Based at least on receiving the updated second configuration item, deployment of the second configuration item is resumed.

10. A method for configuration change control, the method comprising: receiving a second configuration item for replacing the first configuration item in the exposure group; receiving an exposure status from a central orchestrator, wherein the exposure status indicates an exposure tree, the exposure tree comprising a first configuration item branch and a second configuration item branch; For the exposure group, based at least on the exposure status, determine: a first portion of the exposure group to continue the first configuration item, and a second portion of the exposure group to receive the second configuration item; deploying the second configuration item to the second part of the exposure group according to the exposure status; receiving an updated exposure status from the central orchestrator based on at least a first triggering event; as well as The second configuration item is deployed according to the updated exposure status. The method according to claim 10 , wherein the first configuration item and the second configuration item each comprise a software application version.

12. The method according to claim 10, further comprising: providing the exposure status at the central orchestrator; as well as Based on at least a second triggering event, the exposure status is updated at the central orchestrator.

13. The method of claim 10, wherein the exposure status indication comprises a branched binary tree, the branch indications: The first set, including configuration items and empty placeholders, or The second set includes the first configuration item branch weight and the second configuration item branch weight.

14. The method of claim 13, wherein determining the first portion of the exposure group and the second portion of the exposure group comprises: Determining a threshold based at least on the first configuration item branch weight or the second configuration item branch weight; performing a deterministic operation on data associated with each member of the exposure group to generate a member value; for at least one member of the exposure group, comparing the threshold to the member value; as well as Based at least on the comparison, the at least one member of the exposure group is assigned to the first portion of the exposure group or the second portion of the exposure group.

15. The method according to claim 10, further comprising: A hierarchical exposure tree is generated by further branching the first configuration item branch or the second configuration item branch.

16. The method according to claim 15, wherein further branching the first configuration item branch comprises: receiving an updated first configuration item for replacing the first configuration item; receiving a first configuration item branch exposure state, wherein the first configuration item branch exposure state indicates: an exposure tree branch including an original first configuration item branch and an updated first configuration item branch; Based at least on the exposure status, determine: a third portion of the exposure group, continuing with the first configuration item, and a fourth portion of the exposure group to receive the updated first configuration item; as well as Deploy the updated first configuration item to the fourth part of the exposure group according to the first configuration item branch exposure status.

17. The method according to claim 15, wherein further branching the second configuration item branch comprises: receiving an updated second configuration item for replacing the second configuration item; receiving a second configuration item branch exposure state, wherein the second configuration item branch exposure state indicates an exposure tree branch including an original second configuration item branch and an updated second configuration item branch; Based at least on the exposure status, determine: a fifth portion of the exposure group to continue the second configuration item, and a sixth portion of the exposure group to receive the updated second configuration item; Deploying the second configuration item to the fifth part of the exposure group according to the exposure status of the second configuration item branch; as well as Deploy the updated second configuration item to the sixth part of the exposure group according to the exposure status of the second configuration item branch.

18. The method according to claim 17, further comprising: interrupting the deployment of the second configuration item based at least on a third triggering event; as well as Based at least on receiving the updated second configuration item, deployment of the second configuration item is resumed.

19. A computer storage device having stored thereon computer executable instructions for configuration change control, the computer executable instructions, when executed by a computer, causing the computer to perform operations comprising: receiving a second configuration item for replacing a first configuration item in an exposure group, wherein the first configuration item and the second configuration item both include software application versions; An exposure status is provided at a central orchestrator, wherein the exposure status indicates a binary exposure tree, the binary exposure tree including a first configuration item branch and a second configuration item branch, the branches indicating: The first set, including configuration items and empty placeholders, or The second set includes the first configuration item branch weight and the second configuration item branch weight; receiving the exposure status from the central orchestrator; For the exposure group, based at least on the exposure status, determine: a first portion of the exposure group to continue the first configuration item, and determining the first portion of the exposure group and the second portion of the exposure group to receive the second configuration item, wherein determining the first portion of the exposure group and the second portion of the exposure group comprises: Determining a threshold based at least on the first configuration item branch weight or the second configuration item branch weight; performing a deterministic operation on data associated with each member of the exposure group to generate a member value; for each member of the exposure group, comparing the threshold to the member value; and monotonically assigning each member of the exposure group to the first portion of the exposure group or the second portion of the exposure group based at least on the comparison; deploying the second configuration item to the second part of the exposure group according to the exposure status; updating the exposure status at the central orchestrator based on at least a first triggering event; receiving an updated exposure status from the central orchestrator based on at least a second triggering event; and The second configuration item is deployed according to the updated exposure status.

20. The computer storage device of claim 19, wherein the operations further comprise: By further branching the first configuration item branch or the second configuration item branch, a hierarchical exposure tree is generated, Further branching the first configuration item branch includes: receiving an updated first configuration item for replacing the first configuration item; receiving a first configuration item branch exposure state, wherein the first configuration item branch exposure state indicates: an exposure tree branch including an original first configuration item branch and an updated first configuration item branch; Based at least on the exposure status, determine: a third portion of the exposure group, continuing with the first configuration item, and a fourth portion of the exposure group to receive the updated first configuration item; and deploying the updated first configuration item to the fourth part of the exposure group according to the first configuration item branch exposure state; Further branching the second configuration item branch includes: interrupting the deployment of the second configuration item based at least on a third triggering event; receiving an updated second configuration item for replacing the second configuration item; Resuming deployment of the second configuration item based at least on receiving the updated second configuration item; receiving a second configuration item branch exposure state, wherein the second configuration item branch exposure state indicates: an exposure tree branch including an original second configuration item branch and an updated second configuration item branch; Based at least on the exposure status, determine: a fifth portion of the exposure group to continue the second configuration item, and a sixth portion of the exposure group to receive the updated second configuration item; deploying the second configuration item to the fifth part of the exposure group according to the exposure status of the second configuration item branch; and Deploy the updated second configuration item to the sixth part of the exposure group according to the exposure status of the second configuration item branch.

Images