Feature lifecycle management cockpit for hybrid cloud and edge systems

Abstract

Methods, systems, and computer-readable storage media are provided for: a customer cockpit receiving a switch notification, the switch notification indicating to activate an edge feature of an edge component of a hybrid software deployment, the switch notification being received during an execution process of the edge component; the customer cockpit determining that the process has ended, and in response triggering an edge controller to switch the edge feature to an activated state within the edge component; a provider cockpit receiving an edge confirmation of the edge component, the edge confirmation confirming that the edge feature is in the activated state, and in response at least in part to receiving the edge confirmation, the provider cockpit triggering a tenant controller to switch a tenant feature to an activated state within a tenant component of the hybrid software deployment.

Description

Technical Field

[0001] Embodiments of this disclosure relate to a feature management system for providing consistent control over the rollout and adoption management of software features for software products deployed in hybrid deployments (i.e., cloud-based components and field (edge) components). More specifically, the feature management system of this disclosure provides a feature management cockpit that includes a vendor view (vendor cockpit) and a customer view (customer cockpit) to manage the lifecycle of software features in hybrid deployments. Background Technology

[0002] Software systems are provided by software vendors to enable businesses to operate. Software systems can include a variety of applications that provide functionality for performing business operations. In some cases, software vendors provide software systems as off-site applications running in a cloud computing environment, which may be referred to as cloud-based applications (e.g., applications provided in so-called Software as a Service (SaaS) deployments). In other cases, software vendors provide software systems as on-premises applications executed by the enterprise (e.g., applications provided in so-called edge deployments). In still other cases, software systems are provided in hybrid deployments, which include both edge (on-premises) deployments (e.g., satellite components deployed to data centers run by the enterprise) and cloud deployments (e.g., central components provided by the software vendor for cloud services).

[0003] Hybrid deployments (i.e., edge and cloud) are often used when specific components need to be close to the enterprise (e.g., in enterprise facilities near machines in a factory) to minimize latency and data volume transmitted over the network, for example. However, some components are still executed as cloud-based services (e.g., components associated with processes deployed across different sites or integrated with other cloud-based processes). In the context of a hybrid deployment, an exemplary setup may include a combination of a lessee for a cloud-based (SaaS) product in production, a lessee for the same cloud-based product for testing, and several instances of a field (edge) component (used in production) deployed to a customer's site (e.g., in a data center, in a factory), with instances deployed on-site for testing for each type of field component. In this exemplary setup, the production field component is connected to the cloud lessee used for production, and the test field component is connected to the cloud lessee used for testing.

[0004] However, hybrid deployments present numerous technical challenges, particularly in the area of ​​managing the lifecycle of features as software evolves over time. For example, when adding features to software, features can be selectively toggled (i.e., turned on / off). Exemplary issues include distributed toggle processes, where feature toggle processing for edge deployments is not centrally handled by the software vendor but rather by the enterprise (customer) according to its own schedule. Another exemplary technical issue is the faster availability of new features in cloud-based components compared to slower availability in edge components. Yet another exemplary technical issue is the rapid removal of feature toggles (e.g., to clean up the codebase) once all customers have toggled (i.e., activated the underlying feature). A further exemplary technical issue is that customers desire to enable new features, including testing, in a controlled manner according to their own schedule. Summary of the Invention

[0005] Embodiments of this disclosure relate to a feature management system for providing consistent control over the rollout and adoption management of software features for software products deployed in hybrid deployments (i.e., cloud-based components and field (edge) components). More specifically, the feature management system of this disclosure provides a feature management cockpit that includes a vendor view (vendor cockpit) and a customer view (customer cockpit) to manage the lifecycle of software features in hybrid deployments.

[0006] In some implementations, the actions include: the customer cabin receiving a handover notification indicating the activation of an edge feature of the hybrid software-deployed edge component, the handover notification being received during the edge component's execution process; the customer cabin determining that the process has ended, and in response, triggering an edge controller to switch the edge feature to an active state within the edge component; the vendor cabin receiving an edge confirmation from the edge component confirming that the edge feature is in an active state, and at least partially in response to receiving the edge confirmation, the vendor cabin triggering a lessee controller to switch the lessee feature to an active state within the lessee component of the hybrid software deployment. Other implementations of this aspect include actions configured to perform these methods, corresponding systems, apparatus, and computer programs encoded on a computer storage device.

[0007] These and other implementations may optionally include one or more of the following features: Actions further include: the customer cabin receiving a lessee confirmation from a lessee component, confirming that the lessee feature is active; at least partially in response to receiving the lessee confirmation, enabling the edge component to perform a process using an edge feature at least partially; Actions further include: removing a feature switch corresponding to the edge feature from the edge component after the edge feature is active, the feature switch including computer-executable code executed to change the edge feature to an active state; Actions further include: removing a feature switch corresponding to the lessee feature from the lessee component after the lessee feature is active, the feature switch including computer-executable code executed to change the edge feature to an active state; Actions further include: removing a feature switch corresponding to the lessee feature from the lessee component after the lessee feature is active, the feature switch including computer-executable code executed to change the edge feature to an active state. The action includes executing computer-executable code to bring a tenant feature to an active state; triggering an edge controller to bring the edge feature to an active state before the deadline; the action also includes determining that a problem has occurred after bringing the edge feature to an active state, and in response, bringing the feature to an inactive state; and the action also includes the vendor cabin publishing data indicating an update to the hybrid software deployment, the data including the version of the edge component, the edge feature, and the feature deadline of the edge feature, the feature deadline indicating the deadline for activating the edge feature, and each of a plurality of customer cabins including the customer cabin receiving the data indicating an update to the hybrid software deployment.

[0008] This disclosure also provides a computer-readable storage medium coupled to one or more processors and storing instructions thereon that, when executed by the one or more processors, cause the one or more processors to perform operations according to an embodiment of the method provided herein.

[0009] This disclosure also provides a system for implementing the methods provided herein. The system includes one or more processors and a computer-readable storage medium coupled to and storing instructions thereon that, when executed by the one or more processors, cause the one or more processors to perform operations according to an embodiment of the methods provided herein.

[0010] It should be understood that the methods according to this disclosure may include any combination of the aspects and features described herein. That is, the methods according to this disclosure are not limited to the combinations of aspects and features specifically described herein, but include any combination of the provided aspects and features.

[0011] Details of one or more embodiments of this disclosure are set forth in the accompanying drawings and the following description. Other features and advantages of this disclosure will become apparent from the detailed description, the drawings, and the claims. Attached Figure Description

[0012] Figure 1An exemplary architecture capable of being used to implement embodiments of this disclosure is described.

[0013] Figure 2 A conceptual overview diagram of a feature management system according to an embodiment of the present disclosure is depicted.

[0014] Figure 3 A conceptual overview diagram depicting the organization of metadata.

[0015] Figure 4 An exemplary timeline representing a switching process is depicted according to an embodiment of this disclosure.

[0016] Figure 5 Exemplary processes that can be performed according to embodiments of this disclosure are described.

[0017] Figure 6 This is a schematic diagram of an exemplary computer system capable of performing embodiments of the present disclosure.

[0018] Similar reference symbols in the accompanying drawings denote similar elements. Detailed Implementation

[0019] Embodiments of this disclosure relate to a feature management system for providing consistent control over the rollout and adoption management of software features for software products deployed in a hybrid deployment (i.e., cloud-based components and field (edge) components). More specifically, the feature management system of this disclosure provides a feature management cabin including a vendor view (vendor cabin) and a customer view (customer cabin) to manage the lifecycle of software features in a hybrid deployment. Embodiments may include the following actions: the customer cabin receives a switchover notification indicating that an edge feature of the edge component of the hybrid software deployment should be activated, the switchover notification being received during the edge component's execution process; the customer cabin determines that the process has ended and, in response, triggers an edge controller to switch the edge feature to an active state within the edge component; the vendor cabin receives an edge confirmation from the edge component confirming that the edge feature is in an active state, and, at least partially in response to receiving the edge confirmation, the vendor cabin triggers a lessee controller to switch a lessee feature to an active state within a lessee component of the hybrid software deployment.

[0020] To provide further context for the embodiments of this disclosure, and as described above, software systems can be provided by software vendors to enable enterprises to operate. Software systems can include various applications that provide functionality for performing enterprise operations. In some instances, software vendors provide software systems as off-site applications running in a cloud computing environment, which may be referred to as cloud-based applications (e.g., applications provided in so-called Software as a Service (SaaS) deployments). In some instances, software vendors provide software systems as on-premises applications executed by the enterprise (e.g., applications provided in so-called edge deployments). In some instances, software systems are provided in hybrid deployments that include both edge (on-premises) deployments (e.g., satellite components deployed to data centers run by the enterprise) and cloud deployments (e.g., central components provided by the software vendor for cloud services).

[0021] Hybrid deployments (i.e., edge and cloud) are often used when specific components need to be close to an enterprise (e.g., near a machine in a factory or within an enterprise facility) to minimize latency and data volume transmitted over a network, for example. However, some components are still executed as cloud-based services (e.g., components associated with processes deployed across different sites or integrated with other cloud-based processes). In the context of a hybrid deployment, an exemplary setup may include a combination of a lessee for a cloud-based (SaaS) product in production, a lessee for the same cloud-based product for testing, and several instances of a field (edge) component (used in production) deployed to a customer's site (e.g., in a data center, in a factory), with instances deployed on-site for testing for each type of field component. In this exemplary setup, the production field component is connected to the cloud lessee used for production, and the test field component is connected to the cloud lessee used for testing.

[0022] Typically, cloud provisioning (e.g., production and test tenants in the example setup) is managed by the software vendor. Software version updates may be pushed out by the vendor at a higher frequency (e.g., daily). This means that software version changes are completed according to a schedule defined by the software vendor. On the other hand, field components are typically managed by the enterprise (customer). For example, the software version change schedule is defined by the enterprise, typically at a lower frequency (e.g., weekly, monthly). This is especially true if software updates require production downtime or otherwise cause a functional degradation. Therefore, in a hybrid deployment, there exists a combination of components that are partly managed by the enterprise and partly by the software vendor at different frequencies.

[0023] In an ideal world, software changes are compatible between different versions, deployments require no downtime, and deployments never fail. Furthermore, management overhead is minimal. However, in reality, software changes can involve downtime. This is especially true for edge components, which are deployed at the edge due to low latency and high data volume connectivity from remote locations (e.g., factories). In such cases, the coveted "zero downtime" may not be achievable (e.g., the need for rapid response with high call rates increases the complexity of delivering "zero downtime" version changes). Therefore, component version changes must typically be coordinated with a lower usage cycle or a cycle where latency has less impact at that location. Additionally, software features introduced by the new software version require testing and additional configuration before being rolled out (switched over) (e.g., activated). Therefore, testing and configuration need to be coordinated with feature switching between field components and cloud tenants.

[0024] Therefore, several technical challenges arise in the context of hybrid deployments. Exemplary challenges include distributed switching processes, where the switching of features for edge deployments is not centrally handled by the software vendor, but rather by the enterprise (customer) according to its own timeline. More specifically, feature switching is typically used to activate features in a controlled and risk-minimizing manner, usually by the software vendor. In some examples, features may include functionality to be provided by software. In some examples, feature switching (also referred to herein as switching) is computer-executable code (e.g., provided in a component) that can be executed to activate (turn on) or deactivate (turn off) a feature.

[0025] The switchover process has the clear advantage of minimizing the risk of change and mitigating the cascading effects (e.g., blast radius) of incompatible or defective changes. In software development, when cloud and edge components are involved, switchovers involve both software vendors and customers. For example, the software vendor defines the feature switchover, the timeframe for the switchover to be enabled (e.g., the deadline for feature activation), and the component version required to use the switched-over feature. However, the customer decides on a single timing for when to activate the feature (e.g., possibly individually for each edge instance relative to the customer). If the software vendor identifies a problem with the software being rolled out, the vendor will still want the option to shut down the feature (as with SaaS components only). This presents challenges in terms of distributed deployment, timelines, and accountability. Typically, the software vendor monitors for problems with the new switched-over feature in its monitoring data and in customer-generated tickets about the products used. This is also difficult for distributed deployments.

[0026] Another exemplary technical problem is reflected in the faster availability of new features in cloud-based components and the slower availability of such features in edge components. For example, in cloud-based products, features are created and pushed relatively frequently, and as mentioned above, the availability of each feature is controlled by switching. On edge components, the corresponding implementation of a new feature is only available after a software update, and as mentioned above, this is often a customer-controlled process. This can lead to delays in the availability of new features in edge components. Customers have time constraints when upgrading edge software, which can further delay consumption. Therefore, there is a time lag in feature availability across different components, which needs to be managed because of the dependencies in the integration process between edge and cloud components, so features can only be activated after the corresponding software updates have been applied in both the cloud and the edge. There should be a process to support the closure / management of version gaps and prevent customers from activating features unless all prerequisites are met. Depending on the feature, this may require some or all edge components to be on a compatible software version with a cloud deployment before the feature can be activated (e.g., generally for the tenant, or specifically for a subset of edge components that already meet the requirements).

[0027] Another exemplary technical problem is the tendency to quickly remove feature switches (e.g., to clean up the codebase) once all customers have enabled the switch (i.e., activated the underlying feature). Developers create feature switches to roll out new development in a controlled manner. Feature switches allow for canary testing and can be quickly shut down if problems arise. However, switches make the codebase cluttered. At some point, developers want to remove the switch from the code and typically activate the corresponding feature. This should be uninterrupted for customers. Therefore, the switch is removed only once all customers have enabled it (e.g., enabled for themselves, or enabled for all remaining customers). This can be done covertly, without customer action (e.g., no testing, no configuration changes, etc.). In cloud deployments, the switch status among tenants is known to the vendor, so adoption trends are known and development can be planned. For on-premises software, the switch status is mostly unknown, so customer adoption of features on edge systems may be invisible to the vendor. If a switch is removed, it means that the code that doesn't always execute the switch now (i.e., the feature is permanently activated), and customers who rely on the feature being disabled will no longer receive service. Therefore, the use of features needs to be known to the supplier to prevent them from disrupting the customer's scenario.

[0028] Another exemplified technical issue is that customers want to enable new features in a controlled manner, according to their own timelines, including testing. If the switch involves functional changes, customers will naturally want to test the changes within their own infrastructure before accepting them. Even if the switch doesn't affect functionality, but may only affect performance, customers will still want to see the new software in their own infrastructure, especially if the software controls critical processes. Adopting new features comes with risk, and customers may want to mitigate that risk. For example, instead of enabling new features for all peripheral components (e.g., machines in a factory), they might start with one (less critical) and move later only to more mission-critical components controlled by the peripheral software (e.g., reducing the blast radius of the change). There may also be legal restrictions requiring appropriate testing and documentation of changes. Even in a factory or for continuously operating (e.g., 24 / 7) machines and processes, there may be periods of lower usage or frequency when it's easier to respond to changes or issues (e.g., low usage at night, change experts in the office during the day). Therefore, customers will want to plan version switchovers according to their own timelines (especially if it involves downtime).

[0029] In the context above, embodiments of this disclosure provide a feature management system to provide consistent control over the rollout and adoption management of software features for software products deployed in hybrid deployments (i.e., cloud-based (SaaS) components and on-premises (edge) components). The feature management system of this disclosure provides a feature management cabin that includes a vendor view (vendor cabin) and a customer view (customer cabin). The feature management cabin enables the definition of feature attributes and their dependencies on software versions, and provides processes for rollout, deployment, adoption, monitoring, and bug handling in a coordinated manner. Using this process, collaboration between the "SaaS operations team" and the "customer administrator" is closer, and processes across the lifecycle of hybrid deployments with all their interdependencies are simplified.

[0030] As described herein, the feature management system of this disclosure embodies a lifecycle management concept that transcends the cloud to address real-world situations beyond theoretical ideals that assume unrealistic boundary conditions (e.g., always-compatible interface evolution, immediate customer deployment of new software versions). By incorporating real-world software development and customer adoption behavior, the feature management system of this disclosure proactively manages and automates required processes on both the software vendor and customer sides to avoid complex manual lifecycle management and reduce process runtime and total cost of ownership (TCO) for hybrid software deployments.

[0031] Figure 1An exemplary architecture 100 according to embodiments of the present disclosure is depicted. In the illustrated example, the exemplary architecture 100 includes a client device 102, a network 106, and a server system 104. The server system 104 includes one or more server devices and a database 108 (e.g., a processor, memory). In the illustrated example, a user 112 interacts with the client device 102. In some examples, the server system 104 represents the vendor side of a hybrid deployment scenario, wherein one or more components of a software system are provided as cloud-based components hosted in the server system 104.

[0032] Figure 1 The exemplary architecture also includes a first client system 120 and a second client system 122. The first client system 120 includes a client device 124, a network 126, and a server system 128. The server system 128 includes one or more server devices and a database (e.g., processor, memory). In the illustrated example, user 130 interacts with client device 124. The second client system 120 includes client device 132, a network 134, and a server system 136. The server system 136 includes one or more server devices and a database (e.g., processor, memory). In the illustrated example, user 138 interacts with client device 124. In some examples, server systems 128 and 136 represent corresponding client sides in a hybrid deployment scenario, where one or more components of the software system are provided as field (edge) components hosted in server systems 128 and 136. Although Figure 1 Server systems 128 and 136 are described, but the concept of implementing field components in any suitable client-side computing environment (e.g., computer, machine in a factory) is conceived.

[0033] In some examples, client devices 102, 124, and 132 are capable of communicating with server system 104 via network 106. In some examples, client devices 124 and 132 are capable of communicating with server systems 128 and 136 via networks 126 and 134, respectively. In some examples, client devices 102, 124, and 132 include any suitable type of computing device, such as a desktop computer, laptop computer, handheld computer, tablet computer, personal digital assistant (PDA), cellular phone, network device, camera, smartphone, enhanced general packet radio service (EGPRS) mobile phone, media player, navigation device, email device, game console, or any suitable combination of two or more of these devices or other data processing devices. In some implementations, networks 106, 126, and 134 may include a large computer network connecting any number of communication devices, mobile computing devices, fixed computing devices, and server systems, such as a local area network (LAN), wide area network (WAN), Internet, cellular network, telephone network (e.g., PSTN), or suitable combinations thereof.

[0034] According to embodiments of this disclosure, and as described above, server system 104 is capable of hosting a feature management system. For example, this feature management system provides a feature management dashboard including a vendor view (vendor dashboard) and a customer view (customer dashboard). For instance, user 112 (e.g., an employee / agent of a software vendor) can access the vendor dashboard using computing device 102, user 130 (e.g., an employee / agent of a customer) can access the customer dashboard using computing device 124, and user 138 (e.g., an employee / agent of a customer) can access the customer dashboard using computing device 132.

[0035] As described above, the feature management system disclosed herein provides a feature management cockpit that supports feature rollout and offers the benefits of feature switching for software deployed in the cloud and on-premises (hybrid deployment). As described in more detail herein, the feature management system includes a dependency management component, a feature issue analysis component, a software update scheduling and monitoring component, and a switchover activation component. In some examples, the dependency management component enables the definition of dependencies between feature switching, software versions of edge components, and cloud components, feature switchover activation types, and feature switchover deadlines. The dependency management component also monitors the software update and switchover status in customer cloud tenants and customer edge tenants. In some examples, the feature issue analysis component provides analysis of customer ticketing data and monitoring alerts for customer tenants and software instances (depending on software version and feature). This allows software vendors to identify problems with newly created features and ultimately withdraw released features (if necessary). In some examples, the software update scheduling and monitoring component enables customers to plan and monitor updates and switchover activations for edge instances based on the type of switchover activation and the switchover deadline. Exemplary types of switching activation may include, but are not limited to, edge instance-level (e.g., toggling the switch individually for each edge instance) and tenant-wide (e.g., toggling the switch for all connected edge instances). Process and state information is also accessible to the software vendor. In some examples, the switching activation component enables consistent switching states between tenants and edge instances if the switching activation type requires it.

[0036] Figure 2 A conceptual overview diagram of a feature management system 200 according to an embodiment of this disclosure is depicted. Figure 2 In the example, the feature management system 200 includes a support port 202, a supplier cockpit 204, and a customer cockpit 206. Figure 2 In the example, a lessee controller 208 is provided to control (e.g., feature switching) the lessee cloud software 210, and an edge controller 212 is provided to control (e.g., feature switching) the edge component 214. The lessee cloud software 210 represents a cloud component provided to a specific lessee (customer) within the cloud. The edge component 214 represents an instance of edge software provided on-site at the customer's location.

[0037] In some examples, the vendor cockpit 204 enables access to and interaction with metadata 220, customer data and statistics 222, and error statistics 224. Metadata 220 includes, for example, part information including all part versions (CVs), features (F) for each CV, and deprecated features (F) for each CV. dThe data includes the deadline for each F (e.g., the deadline for switching on), and a flag indicating the status of each F (e.g., paused, activated). Customer data and statistics 222 include, for example, for each lessee (customer) in the lessee set, CVs deployed to the lessee, Fs switched on in the lessee, and the percentage of each lessee's edge that adopts each CV and each F (including information on whether it is set for "test" or "production"). Error statistics 224 include, for example, links to incidents related to F for all customers.

[0038] In some examples, the customer cockpit 206 is customer-specific and enables access to and interaction with metadata 230, customer data and statistics 232, and error statistics 234. Metadata 230 includes, for example, component information, including customer-related CVs, function parameters (F) for each CV, and deadlines for each F (e.g., the deadline for switching on). Customer data and statistics 232 includes, for example, for a lessee (customer) in the lessee set, the deployed CV, the switch F, and the function parameters for changing the version. <n>The deployment timeline to edge instances, along with a list of edge instances, CVs, and failover events. Error statistics 234 include, for example, a list of incidents related to events that include links to support tickets.

[0039] In some examples, the tenant controller 208 accesses and interacts with metadata 240. Metadata 240 includes, for example, the actual CVs used in the tenant cloud software 210 (i.e., the currently active CV), available functions (F), and the toggle state of each F. In some examples, the edge controller 210 accesses and interacts with metadata 240. Metadata 250 includes, for example, the actual CVs used in the edge component 214 (i.e., the currently active CV), available functions (F), and the toggle state of each F.

[0040] Figure 3 A conceptual overview diagram depicting the organization of metadata 300 is provided. Metadata 300 includes data representing software component 302, one or more CVs 304 for each software component 302, and one or more Fs 306 for each CV. Metadata 300 includes data representing one or more cloud stacks 308 to which CV 304 is deployed and one or more edge stacks 310 to which CV 304 is deployed. In some examples, each CV 304 is associated with a deployment schedule 312, which defines the timing of the deployment of the corresponding CV 304 to one of the cloud stacks 308 and the edge stacks 310. In some examples, this data includes data representing a deadline 314 by which the corresponding feature switch (toggle) 315 is to be removed (e.g., a deadline to deactivate a feature).

[0041] Refer again Figure 2 Furthermore, according to embodiments of this disclosure, support port 202 enables support personnel to access information representing a hybrid software deployment. For example, support personnel can use support port 202 to analyze fault tickets associated with different CVs. For instance, if an error exists related to a feature that has been switched, it can be determined whether there are further errors in other instances of CVs that have also been switched.

[0042] In some implementations, the vendor cabin 204 is accessible only to the vendor, enabling the vendor to define metadata and control the processes used for feature management. In some implementations, the customer cabin 206 is a dedicated instance for a single customer, through which the customer can access tenant and edge instance scenarios. In some examples, the vendor cabin 204 communicates with each of multiple customer cabins 206, each provided to a customer using software. Communication between the vendor cabin 204 and each customer cabin 206 can be bidirectional. For example, the vendor cabin 204 can push information to the customer cabin 206, and the customer cabin 206 can push information to the vendor cabin 204. In some examples, an event bus can be used to communicate information between the vendor cabin 204 and the customer cabins 206. In some examples, the vendor cabin 204 can periodically pull information from the customer cabins 206.

[0043] In some implementations, the feature management system displays the features and which software versions are required to switch features. The feature management system also displays the cloud and edge component instances involved, along with their software versions and feature switching status. In some examples, the feature management system enables the opening and closing (switching) of features (closing is typically done in emergency situations if there are problems opening). In some examples, the switching can be embedded in an automated process. The feature management system also has the capability to plan new version deployments, feature adoption and related change processes and scheduling, when to deploy updates, and when to switch features for specific instances. The feature management system supports specific processes for different feature types, thus ensuring the correct adoption of specific feature types.

[0044] More specifically, Vendor Cockpit 204 can be used by the software vendor to release component versions, features, and feature deadlines, and to relay this information to every communication in Customer Cockpit 206. Vendor Cockpit 204 provides statistics on software versions and an overview of customer adoption of features. Once a software version is adopted and its deadline has passed, the version is removed from the release list and the switchover occurs. In some examples, Vendor Cockpit 204 is able to receive information from Customer Cockpit 206 regarding software version and feature adoption statistics, and access information about software version and switchover adoption across all customers, including, for example, comparisons relative to deadlines. In some examples, Vendor Cockpit 204 accesses information about customer switchover schedules and notifies customers if a feature switchover is withdrawn.

[0045] In some implementations, the customer cockpit 206 provides features to show which component versions and associated features are available, how feature switching needs to be performed, and what the deadline for feature adoption is. In some examples, the customer cockpit 206 can receive information from the vendor cockpit 204, such as regarding delayed deadlines, and update information for the adoption schedule. In some examples, the customer cockpit 206 provides a landscape overview indicating which edge instances are using software components and which versions are deployed. In some examples, the customer cockpit 206 provides a feature overview indicating which edge instances have switched on which features. In some examples, the customer cockpit 206 provides an overview with information such as feature adoption progress and deployment schedules compared to deadlines. In some examples, the customer cockpit 206 can push aggregated statistics about software versions and feature adoption to the vendor. In some examples, the customer cockpit 206 enables the scheduling of software updates on edge instances. In some examples, individual edge instance schedules for deployment can be provided. In some examples, the customer cockpit 206 enables the toggling of features on / off, with the switching process depending on the feature type.

[0046] More specifically, Vendor Cockpit 204 enables dependency management for features and component versions used in hybrid deployments. This building block addresses dependency definitions, the process of defining and rolling out information, and information gathered from customers regarding the versions used. In some examples, Vendor Cockpit 204 can be used to define dependencies between component versions and features in the software, which can be toggled. For example, for the cloud—feature toggle availability; for the edge, software version—feature toggle availability. In some examples, the definition requires a feature deadline, as a feature in a closed state will be deprecated, and later software versions will no longer include feature toggle. That is, after the deadline, the feature is on by default.

[0047] As a non-restrictive example, features <f-1>It's new, and the version will be deployed at the edge once. <n1>Yes, it can be switched once the version is deployed to the cloud. <n2>,feature <f-1>It can no longer be switched. Using vendor cockpit 204, it can be targeted at edge software versions. <n1>Specify the following example information:

[0048] New features were developed – and features were targeted. <f-1>Feature switching <ft-1>Related.

[0049] The switch can be set individually by edge, or globally for the tenant.

[0050] Featured consumption deadline<d_1> .

[0051] Using vendor cockpit 204 can target later edge software versions. <n2>Specify the following example information:

[0052] Cancel switch <ft-1>and features <f-1>Permanently switch to "On".

[0053] In the corresponding cloud version <n1> / <n2>When the software has already been deployed to cloud tenants used by customers, vendor Cockpit 204 releases the edge software version in the relevant marketplace or download area used for downloading and deployment. <n1> / <n2>In some examples, vendor cockpit 204 notifies customers of new software versions and features. For instance, vendor cockpit 204 sends a message to customer cockpit 206, enabling the customer (e.g., an administrator) to see information about features, the software version used for deployment, and defined deadlines in customer cockpit 206.

[0054] In some examples, to continue feature development, vendors may want to have rules whereby, once all customers have deployed... <n1>And open <ft-1>(That is, the feature was activated) <f-1>The supplier only applies version ). <n2>If some customers are deploying and consuming... <n2>The time has not yet switched <ft-1>Suppliers can decide to postpone <n2>Deploy to the cloud, or based on <ft-1>The customer process was shut down and interrupted. To avoid this situation, at the deadline and <n2>Sufficient time should be allocated between deployments. In light of this, vendor cockpit 204 provides monitoring information. Exemplary monitoring information may include, but is not limited to, the version used by customers on their edge instances (e.g., how many customers are using version [specific version]). <n1>Information about the feature switching status (e.g., how many customers have deployed the version, and how many are on older versions), and information about the feature switching status (e.g., how many customers have deployed the version). <n1>Features have been enabled. <f-1>(How many instances are still running without this feature).

[0055] According to embodiments of this disclosure, the feature management system provides feature usage and problem analysis. For example, to determine whether a rolled-up feature is actually working or should be stopped from rolling, information from multiple domains is needed. For example, how it operates, how many people use the new feature (which has been switched on), how the feature functions, and whether any problems have been observed or reported. On the problem side, alarms and fault tickets are analyzed to identify whether switching on a feature resulted in an increased alarm rate and a higher volume of fault tickets, and whether there are alarms and tickets associated with the switched-on feature.

[0056] In light of this, Vendor Cockpit 204 can access the vendor's fault ticketing system and / or customer incident management system for parts, issues, tickets, and service requests. In some examples, Vendor Cockpit 204 can be used to query the fault ticketing system for tickets related to part versions and features. In some examples, Vendor Cockpit 204 can generate daily or weekly ticket statistics for each CV and feature to analyze trends, such as whether the number of tickets increases or decreases over time. In some examples, Vendor Cockpit 204 accesses the vendor's alerting system (or similarly, an event bus system) to receive events and alerts from SaaS tenants and instances connected to them. In some examples, Vendor Cockpit 204 can be used to query the alerting system or event bus data lake for alerts and events of types (e.g., errors) related to part versions and features. In some examples, Vendor Cockpit 204 can generate daily or weekly alert and error statistics for each part version and feature to analyze trends, such as whether the number of alerts and errors increases or decreases over time.

[0057] Therefore, through Vendor Cockpit 204, vendors can analyze alerts, bugs, and tickets related to new features. If trends indicate that a new feature is causing an increase in the number of issues, vendors can decide to postpone feature adoption, withdraw the feature, and replace it with a later version. By monitoring customer upgrade schedules, vendors can see if customers have planned upcoming feature activations, and in the event of a significant increase in the number of issues, vendors can notify customers to postpone their adoption.

[0058] Therefore, Vendor Cockpit 204 has a user interface (UI) to modify feature and workflow deadlines for feature revocation. In some examples, Vendor Cockpit 204 has a UI to add information by switching to a newly created software part version using a new feature that will be used as a corrected version of the feature to be revoked. In some examples, Vendor Cockpit 204 provides infrastructure to notify customers. In some examples, features to be revoked are removed from the list of available features in the software part version.

[0059] Furthermore, in the customer cockpit 206, it is no longer possible to enable the corresponding switch for the withdrawn feature (or the customer can override the lock after being warned and acknowledging the risks). In some examples, if the feature switch is already enabled, the customer can be allowed to disable the feature (or, if the customer does not encounter any problems, the customer can ignore this suggestion and continue using the feature). In some examples, the vendor cockpit 204 provides a UI to add information to the newly created software part version using the new feature switch for the corrected version that will be used as the withdrawn feature. For example, a vendor creates a new version of software with a corrected feature and releases the new feature version, allowing the switch to be enabled when deploying the new software version. This information is pushed to the customer cockpit 206, so the customer can adjust their consumption plan as needed.

[0060] According to embodiments of this disclosure, the feature management system provides upgrade scheduling and monitoring to make it easier for customers to plan the adoption of new advertised features. In some examples, in customer cockpit 206, upgrade schedules for edge components can be created, and feature adoption can be monitored. In some examples, customer cockpit 206 aggregates statistics and pushes them to vendor cockpit 204, enabling vendors to monitor adoption. Referring to the examples above, using customer cockpit 206, customers can see the advertised software version. <n1>Related characteristics <f-1>and its adoption deadline<d_1> The customer's task is to schedule (multiple) edge deployments before a specified deadline. In some examples, the customer is able to schedule updates (and switchovers) one by one for each edge component, but all edge components must be switched over before the deadline. For some features, the feature is implicitly activated along with the deployment of that version. This is only possible if it is possible to switch over one edge at a time for feature type [a]. Otherwise, deployments on all edges must occur before the feature is consistently switched over on all edges along with the switch in the cloud (type [b]).

[0061] The customer cabin 206 provides monitoring of deployment and switchover progress across all edge components. For the customer, this is intended to support their scheduling and provide information about their progress before deadlines. In some examples, the customer cabin 206 sends monitoring information to the vendor cabin 204, annotated with the customer ID (i.e., a unique identifier that uniquely identifies that customer among multiple customers). The vendor can use this information across all customers to, for example, ensure that features have been enabled for all customers. <f-1>Previously, versions were not deployed to the cloud. <n2>.

[0062] As stated above, customers will want to plan software upgrades for edge components in a way that minimizes risk and impact. Since every change carries the risk of error conditions, customers will want to test the changes and identify edge instances to begin rolling out with the lowest risk (e.g., minimizing the blast radius of the change). Furthermore, different edge instances will typically have a single time period in which the change is most appropriate. Thus, the deployment of a new software version is a process that unfolds over a specific time period. Depending on the type of feature ([a] or [b]), once the desired software version is deployed, the actual feature switchover may potentially propagate over time (for [a]) or be coordinated across all edge instances.

[0063] In some implementations, the feature management system provides consistent switching. For example, when deploying a new software version with new features, it may be important to control the switching on between edge instances and tenants. In view of this, the customer cabin 206 enables the management of feature switching, wherein a feature can only be switched if specified switching preset conditions are met. For example, for type [a], the edge component to be switched must at least meet certain conditions in the feature management system. <f-1>version <n1>Above, for type [b], all edge components at least in the feature <f-1>version <n1>If the feature is implicitly activated when deployed to the edge, the feature switch will be automatically configured in the cloud tenant for that edge instance once the deployment to the edge is successfully completed (more precisely, once the edge software version is switched to a new version).

[0064] In some examples, the customer cockpit 206 provides a procedure for switching features. For example, for type [a], the customer selects the edge instance to switch to and triggers the opening procedure; for type [b], all edge instances are selected and the opening procedure is triggered. In some examples, the customer cockpit 206 notifies the selected edge instances(s) of the upcoming feature. <f-1>The switching change occurs. Multiple edge instances complete their current process, initiate the switch, send a switch confirmation, and wait until they receive confirmation before starting a new process. Once all confirmations are received, the switch is initiated on the cloud component (tenant) (either for a specific edge instance (feature type [a]) or for the entire tenant (feature type [b])). Confirmations for the switch are sent to all edge instances, and the multiple edge instances continue the process with the new feature settings.

[0065] In some examples, a grace period is provided. For instance, if the vendor cabin does not receive confirmation of the switch from all edge instances, a fallback of the switch can be sent to (multiple) edge instances. In this case, the edge instances will switch to off and continue processing using the switch-off functionality.

[0066] Figure 4 An exemplary timeline 400 of representation switching according to embodiments of the present disclosure is depicted. Figure 4 The example depicts a switch-off cycle 402 and a switch-on cycle 404. During the switch-off cycle, multiple processes are executed by the corresponding edge components. While process 404 is executing, a switch-on notification (1) is received. That is, each edge instance is notified to switch on a feature. Upon completion of each process 404, the feature is opened at the corresponding edge instance (2), and each edge instance sends an acknowledgment (3). In response to the acknowledgment received from the edge instance, the feature is switched on for the corresponding cloud component (tenant) (4), and an acknowledgment (5) is sent. Afterwards, process 404' is executed by the edge instance during the open cycle 404.

[0067] To further illustrate embodiments of this disclosure, an exemplary general process is described in more detail herein. In this example, a vendor releases a software product. <s>New version <n>Including new features <f>New features can be achieved through feature switching. <ft>Switch. This software version includes options for edge deployment.<s_e> and cloud deployment<s_c> The components. Corresponding deployment methods are provided.<ft_e> and<ft_c> Switching to allow for fine-grained control over changes. The vendor provides cloud instances.<s_c> Push and deploy the software version <n>The supplier accesses the newly created software version in Supplier Cockpit 204. <n>and related software packages<s_e> and used for features<f_e> and<f_c> Switching<ft_e> and<ft_c> The supplier uses Supplier Cockpit 204 to release the software version. <n>This allows customers to consume data in the cloud and deploy it at the edge. Supplier cockpit 204 pushes a notification about the switch to customer cockpit 206.<ft_e> and<ft_c> Edge software to be deployed<s_e> Version and deployment deadline for the definition of this feature.<d_n> Information regarding the software version. In this example, the vendor plans to remove [the software].<n+x> Switching<ft_e> and<ft_c> The software version was scheduled in<d_n> Then deploy. Once the new version is released...<n+x> If available, the supplier updates the information in Supplier Cockpit 204 and removes the feature from the list of features that can be switched.

[0068] Customers (among multiple customers) receive notifications of new features and software versions through Customer Cockpit 206. Using Customer Cockpit 206, customers are able to identify which instances and lessees are affected by the changes. With this information, customers are able to identify the relevant processes(s) controlled by the affected edge instances and, for example, begin developing plans to adopt the features, starting from deployment to testing infrastructure.

[0069] During the testing phase, run<s_c> Cloud test tenants have already been in version [version number missing]. <n>Up, and run<s_e> The edge test instance was updated to <n>Switch on / off features in cloud-based test tenants.<f_c> And by switching to the edge test instance via customer cockpit 206.<f_e> Test the new feature. For example, the feature can be used to process test data and generate results. Evaluate the impact on (multiple) processes controlling edge instances. An exemplary impact could be related to deploying and toggling the enabled feature.<f_e> This includes related production stoppages and / or functional (e.g., changed APIs, changed configuration values) and non-functional (e.g., performance) changes. As a result of the impact assessment, deployment can be planned for production scenarios.

[0070] In Customer Cockpit 206, customers define deployment and feature switchover schedules for production instances. In some examples, for type [a] (edge-by-edge) feature switches, edge instances are selected for initial deployment (e.g., trial, first wave) that likely carry the lowest risk in terms of application changes. Depending on the size of the edge scenario, the plan can be rolled out in several waves, each wave including a set of edge instances to minimize risk and allow lessons learned from previous deployments to be incorporated for the next wave. A schedule for adopting features across different edge instances is created. Deployment and subsequent feature switches can be automated during the process, even after the edge instances have been updated to the latest version. <n>It launches immediately for each edge instance. In some examples, customers can launch it anytime after the edge component has been updated, but before the deadline.<d_n> Previously, features were switched for each edge component.

[0071] In some examples, for characteristics of type [b] (globally for the tenant), deployment can be phased out based on risk and the optimal deployment window, as described above for type [a]. This is after all edge components have been updated to version [b]. <n>Subsequently, feature switching is scheduled for the appropriate time point with the lowest global risk for the involved edge instances. The feature is switched on using Customer Cockpit 206 at both the lessee and the edge. In some examples, the feature... <f>The phased rollout includes the first wave of scheduling time, during which edge instances, as part of the first wave, will be updated to...<s_e> Version <n>(For type [a], the switch is on)<ft_e> Assess the deployment's execution and its impact on connected processes(s), and adjust the schedule as needed. If issues arise, prevent further rollout, stop the rollout, and notify the vendor. Otherwise, execute a second wave during the scheduled time, during which edge instances, as part of the second wave, will be updated to...<s_e> Version <n>(For type [a], toggle on)<ft_e> The assessment is conducted again. This process can continue until the final wave is deployed (e.g., the second wave could be the last).

[0072] For the characteristics of type [b], the switch is opened using customer cockpit 206, which pushes information to the supplier cockpit: the customer has fully adopted version [b]. <n>and characteristics <f>Suppliers can interact with customers during adoption through supplier cockpit 204 and customer cockpit 206. For example, they can notify suppliers of issues that arise during adoption. In some examples, the notification originates from the customer, instructing them to update / switch features. <f>This can lead to problems (e.g., by creating fault tickets in the supplier fault ticket system). Supplier Cockpit 204 periodically analyzes fault tickets and customer alerts. In some examples, the supplier analyzes the problem and develops solutions for any (or multiple) problems.

[0073] In some examples, if the solution can be implemented by the customer, the customer tunes the automation scripts, runs tests, and plans the next wave of deployment. Typically, vendor support provides information via incident tickets created by the customer. In some examples, if the solution is on the vendor's side, a deadline is set.<d_n> Extend or couple to the new deadline<d_n_i> Utilizing version<n+i> Create features<f_new> The new version, and switching to new features.<ft_i> Provide a new deadline<d_n_i> This process is initiated from the outset. It is controlled, at least in part, by pushing information from the supplier cockpit 204 to the customer cockpit 206 to enable the customer to adjust their schedule. Features are employed. <f>Customers who did not experience any issues were able to continue using the feature. <f>No features were used. <f>Customers can postpone adoption and, through targeted<ft_i> The new plan replaces its original plan, and the deadline is now...<d_n_i> .

[0074] As described above, the vendor monitors customer adoption of the offered features through Vendor Cockpit 204. If a customer is not implementing adoption and the deadline is approaching, the vendor notifies the customer of the upcoming deadline and the feature's deprecation. If some customers cannot apply the requested version, and this version is a prerequisite for deploying a further cloud version (e.g., because the feature switch has been removed since a certain version), cloud solution upgrades can be paused until all customers are on the required version and have activated the feature.

[0075] Figure 5 An exemplary process 500 capable of being executed according to embodiments of the present disclosure is depicted. In some examples, the exemplary process 500 is provided using one or more computer-executable programs executed by one or more computing devices.

[0076] Receive updated data (502). For example, as described herein, data representing an update to the hybrid software deployment is published using a vendor dashboard. In some examples, this data includes the component version of the edge component, one or more edge features, and a feature deadline for each of the edge features, which indicates the deadline for activating each edge feature. Each of multiple customer dashboards receives the updated data representing the hybrid software deployment. Schedule feature activation for one or more edge components (504). For example, as described herein, each customer is able to determine the appropriate time to activate the edge features of the edge component (edge ​​component instance) in a view of the deadlines(s).

[0077] Set counter i to equal 1 (506). Determine edge component i (EC) i Is the process (508) being executed? If EC i The above process was not executed in EC i In this case, one or more features will be switched to the active state (510). If EC i If the process is in progress, wait for the process to finish (512), and then in EC i One or more features are switched to an active state (510). For example, as described herein, a feature switch for each feature is triggered to transition the corresponding edge feature from an inactive state to an active state. It is determined whether i equals m (514). That is, it is determined whether all edge components for the corresponding customer have been addressed. If i is not equal to m, i is incremented (516), and the exemplary process 500 loops back. If i equals m, one or more tenant features are switched to an active state (518). For example, as described herein, a feature switch for each tenant feature is triggered to transition the corresponding tenant feature from an inactive state to an active state. Edge components are enabled to perform one or more processes (520).

[0078] Now for reference Figure 6 A schematic diagram of an exemplary computing system 600 is provided. System 600 can be used for operations described in conjunction with the embodiments described herein. For example, system 600 can be included in any or all of the server components discussed herein. System 600 includes a processor 610, memory 620, storage device 630, and input / output device 640. Components 610, 620, 630, and 640 are interconnected using a system bus 650. Process 610 is capable of processing instructions that execute within system 600. In some embodiments, processor 610 is a single-threaded processor. In some embodiments, processor 610 is a multi-threaded processor. Processor 610 is capable of processing instructions stored in memory 620 or storage device 630 to display graphical information for a user interface on input / output device 640.

[0079] Memory 620 stores information within system 600. In some embodiments, memory 620 is a computer-readable medium. In some embodiments, memory 620 is a volatile memory cell. In some embodiments, memory 620 is a non-volatile memory cell. Storage device 630 provides massive storage for system 600. In some embodiments, storage device 630 is a computer-readable medium. In some embodiments, storage device 630 may be a floppy disk device, hard disk device, optical disk device, or magnetic tape device. Input / output device 640 provides input / output operations for system 600. In some embodiments, input / output device 640 includes a keyboard and / or a pointing device. In some embodiments, input / output device 640 includes a display unit for displaying a graphical user interface.

[0080] The aforementioned features can be implemented in digital electronic circuits or in computer hardware, firmware, software, or combinations thereof. The apparatus can be implemented in a computer program product tangibly contained in an information carrier (e.g., a machine-readable storage device for execution by a programmable processor), and the method steps can be executed by a programmable processor executing an instruction program to perform the functions of the above-described embodiments by manipulating input data and generating output. The described features can advantageously be implemented in one or more computer programs executable on a programmable system, including at least one programmable processor, at least one input device, and at least one output device coupled to receive and transmit data and instructions from and to a data storage system. A computer program is a set of instructions that can be used directly or indirectly in a computer to perform an activity or produce a result. Computer programs can be written in any form of programming language, including compiled and interpreted languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0081] For example, suitable processors for executing programs include both general-purpose microprocessors and special-purpose microprocessors, as well as a single processor or one of multiple processors in any type of computer. Generally, the processor receives instructions and data from read-only memory or random access memory, or both. Computer components may include a processor for executing instructions and one or more memories for storing instructions and data. Typically, a computer may also include one or more mass storage devices for storing data files or be operatively coupled to communicate with one or more mass storage devices for storing data files; such devices include disks, such as internal hard disks and removable disks; magneto-optical disks; and optical disks. Storage devices suitable for tangibly implementing computer program instructions and data include all forms of non-volatile memory, such as semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM discs. The processor and memory may be supplemented by or incorporated into an ASIC (Application-Specific Integrated Circuit).

[0082] To provide interaction with the user, these features can be implemented on a computer with a display device (such as a CRT (cathode ray tube)) for displaying information to the user and a keyboard and pointing device (such as a mouse or trackball) that the user can use to provide input to the computer.

[0083] These features can be implemented in a computer system that includes back-end components (such as data servers), middleware components (such as application servers or internet servers), front-end components (such as client computers with graphical user interfaces or internet browsers), or any combination thereof. The components of the system can be connected via digital data communication of any form or medium (such as communication networks). Examples of communication networks include, for example, LANs, WANs, and computers and networks that form the Internet.

[0084] Computer systems may include clients and servers. Clients and servers are generally geographically separated and typically interact via a network, such as the one described. The client-server relationship is established by means of computer programs running on the respective computers and having a client-server relationship with each other.

[0085] Furthermore, the logic flow depicted in the accompanying drawings does not require the specific order or sequence shown to achieve the desired result. Additionally, other steps may be provided, or steps may be eliminated from the described flow, and other components may be added to or removed from the described system. Therefore, other embodiments are within the scope of the following claims.

[0086] Several embodiments of this disclosure have been described. However, it should be understood that various modifications can be made without departing from the spirit and scope of this disclosure. Therefore, other embodiments are within the scope of the following claims.< / f> < / f> < / f> < / f> < / f> < / n> < / n> < / n> < / f> < / n> < / n> < / n> < / n> < / n> < / n> < / n> < / ft> < / f> < / n> < / s> < / n1> < / n1> < / n>

Claims

1. A method for managing features in a hybrid software deployment, wherein the hybrid software deployment includes edge deployment and cloud deployment, the method being executed by one or more processors and comprising: A switching notification is received by the customer cockpit, indicating that an edge feature of the edge component of the hybrid software deployment should be activated. The switching notification is received during the execution process of the edge component, wherein the customer cockpit includes a user interface. Once the customer cabin determines that the process has ended, in response, the edge controller is triggered to switch the edge feature to an active state within the edge component. The supplier cockpit receives edge confirmation from the edge component, the edge confirmation confirming that the edge feature is in the active state, wherein the supplier cockpit includes a user interface; and In response to receiving the edge confirmation, the supplier cockpit triggers the lessee controller to switch the lessee characteristics of the corresponding lessee component deployed in the cloud to an active state.

2. The method according to claim 1, further comprising: The customer cabin receives a lessee confirmation from the lessee component, and the lessee confirmation confirms that the lessee feature is in the active state; as well as At least in part in response to receiving the tenant's confirmation, the edge component is enabled to at least partially use the edge feature to perform the process.

3. The method of claim 1, further comprising removing a feature switch corresponding to the edge feature from the edge component after the edge feature is in the active state, the feature switch including computer-executable code executed to transition the edge feature to the active state.

4. The method of claim 1, further comprising removing a feature switch corresponding to the lessee feature from the lessee component after the lessee feature is in the active state, the feature switch including computer-executable code executed to transition the lessee feature to the active state.

5. The method according to claim 1, wherein, Before the deadline expires, the edge controller is triggered to switch the edge feature to the active state.

6. The method of claim 1, further comprising, after switching the edge component to the active state, determining that a problem has occurred, and in response, switching the feature to an inactive state.

7. The method according to claim 1, further comprising: The vendor cockpit releases data indicating updates to the hybrid software deployment, including the component version of the edge component, the edge feature, and a feature deadline for the edge feature, the feature deadline indicating the deadline for activating the edge feature; as well as The data representing an update to the hybrid software deployment is received by each of a plurality of customer cockpits including the customer cockpit.

8. A non-transitory computer-readable storage medium coupled to one or more processors and storing instructions thereon, which, when executed by the one or more processors, cause the one or more processors to perform operations for managing features in a hybrid software deployment according to claim 1.

9. The non-transitory computer-readable storage medium according to claim 8, wherein, The operation further includes: The customer cabin receives a lessee confirmation from the lessee component, the lessee confirmation confirming that the lessee feature is in the active state; and At least in part in response to receiving the tenant's confirmation, the edge component is enabled to at least partially use the edge feature to perform the process.

10. The non-transitory computer-readable storage medium of claim 8, wherein the operation further includes removing a feature switch corresponding to the edge feature from the edge component after the edge feature is in the active state, the feature switch including computer-executable code executed to transition the edge feature to the active state.

11. The non-transitory computer-readable storage medium of claim 8, wherein the operation further includes removing a feature switch corresponding to the lessee feature from the lessee component after the lessee feature is in the active state, the feature switch including computer-executable code executed to transition the lessee feature to the active state.

12. The non-transitory computer-readable storage medium according to claim 8, wherein, Before the deadline expires, the edge controller is triggered to switch the edge feature to the active state.

13. The non-transitory computer-readable storage medium of claim 8, wherein the operation further includes determining that a problem has occurred after switching the edge component to the active state, and, in response, switching the feature to an inactive state.

14. The non-transitory computer-readable storage medium according to claim 8, wherein, The operation also includes: The vendor cockpit releases data indicating updates to the hybrid software deployment, including the component version of the edge component, the edge feature, and a feature deadline for the edge feature, the feature deadline indicating the deadline for activating the edge feature; and The data representing an update to the hybrid software deployment is received by each of a plurality of customer cockpits including the customer cockpit.

15. A computer-implemented system, the system comprising: Computing devices; as well as A computer-readable storage medium coupled to the computing device and storing instructions thereon, which, when executed by the computing device, cause the computing device to perform operations for managing features in a hybrid software deployment according to claim 1.

16. The system according to claim 15, wherein, The operation also includes: The customer cabin receives a lessee confirmation from the lessee component, the lessee confirmation confirming that the lessee feature is in the active state; and At least in part in response to receiving the tenant's confirmation, the edge component is enabled to at least partially use the edge feature to perform the process.

17. The system according to claim 15, wherein, The operation also includes removing a feature switch corresponding to the edge feature from the edge component after the edge feature is in the active state, the feature switch including computer-executable code executed to transition the edge feature to the active state.

18. The system according to claim 15, wherein, The operation also includes removing a feature switch corresponding to the lessee feature from the lessee component after the lessee feature is in the active state, the feature switch including computer-executable code executed to transition the lessee feature to the active state.

19. The system according to claim 15, wherein, Before the deadline expires, the edge controller is triggered to switch the edge feature to the active state.

20. The system according to claim 15, wherein, The operation also includes determining that a problem has occurred after switching the edge component to the active state, and, in response, switching the feature to an inactive state.

Images