Microservice update system

Abstract

The present invention proposes a microservice update system, which includes a build scheduler system, the build scheduler system receives a microservice modification request, identifies a first microservice included in a plurality of microservices providing a service. The build scheduler system then triggers a corresponding microservice pipeline for each first microservice. A continuous integration system receives a corresponding microservice modification code for each first microservice via the corresponding pipeline triggered for each first microservice, and updates a first portion of the corresponding service code. The continuous integration system then tests the updated service code to test: the first microservice, which is provided by the first portion of the updated service code; and a second microservice, which is included in the plurality of microservices providing the service, the second microservice being provided by at least one second portion of the updated service code that is not updated as part of the update, and which depends on at least one of the first microservices.

Description

Background Art

[0001] The present disclosure relates generally to information handling systems, and more particularly to updating microservices that enable services provided by information handling systems.

[0002] As the value and use of information continues to increase, individuals and businesses are looking for other ways to process and store information. One possible option for users is an information processing system. An information processing system typically processes, compiles, stores and / or communicates information or data for business, personal or other purposes, allowing users to exploit the value of information. Information processing systems may also vary due to different technical and information processing needs and requirements between different users or applications, which are related to the following items: what information to be processed; how to process the information; how much information to be processed, stored or transferred; and how quickly and efficiently the information can be processed, stored or transferred. Variations are made to information processing systems, which allow information processing systems to be general or for specific users or specific purposes, such as financial transaction processing, airline reservations, enterprise data storage or global communications. In addition, information processing systems can include various hardware and software components that can be configured to process, store and transfer information, and can include one or more computer systems, data storage systems and networking systems.

[0003] Information processing systems, such as one or more networked server devices (sometimes referred to as "cloud servers"), are sometimes used to provide services to client systems. Traditionally, such services are provided by "monolithic" applications run by networked server devices, and those skilled in the art will recognize that such monolithic applications are single-tiered software applications in which the components of the software application (e.g., user interface, data access code, etc.) are combined / integrated into a single program on a single platform that is self-contained and independent of other computing applications. Therefore, the monolithic application operates to perform each step / operation necessary to provide the desired functionality and is designed to be non-modular. However, monolithic applications are being replaced by microservices, and those skilled in the art will recognize that the microservices are provided by software development techniques that construct the services provided by the networked server devices as a collection of loosely connected, fine-grained microservices operating via lightweight protocols, which provide modularity, making the services easier to understand, develop, and test, while also providing resilience to architectural erosion. Furthermore, using microservices enables autonomous teams to independently develop and scale their respective microservices, while allowing the architecture of any individual microservice to emerge, which is achieved through continuous refactoring and / or updating, and continuous integration, delivery, and deployment of microservices that provide services.

[0004] However, there are many problems with traditional updates of services provided by the microservices discussed above, because traditional service update techniques are designed for the monolithic applications discussed above, and therefore provide updates to all code in the code base of the service when the update / build is triggered. Although such service update techniques are very important for monolithic applications, they bring a lot of inefficiencies to the microservice-oriented architecture discussed above, in which microservices can be provided as discrete code modules. For example, when a developer makes a code change to his microservice, the code change will generally only affect a subset of the microservices that provide the service (e.g., a single microservice, and in some cases one or more microservices related to the microservice). However, the update / build triggered when the code change is submitted will result in the reconstruction of the entire code base of the service, and thereby the reconstruction of all microservices provided by the code base, including many unmodified microservices and microservices that are unrelated to the modified microservice. Thus, traditional service updates made in response to modifications to one or more of its microservices are inefficient, with relatively long build times associated with modifications to a single microservice consuming relatively large amounts of resources that may hinder or limit the ability to perform parallel build operations.

[0005] Therefore, there is a need to propose an improved microservice update system. Summary of the invention

[0006] According to one embodiment, an information handling system (IHS) includes: a processing system; and a storage system coupled to the processing system and including instructions that, when executed by the processing system, cause the processing system to provide a continuous integration engine, the continuous integration engine being configured to: receive, for each microservice in a first subset of microservices included in a plurality of microservices configured to provide a service, corresponding microservice modification code for each microservice in the first subset of microservices, for which modifications have been requested; update at least one first portion of service code using the corresponding microservice modification code for each microservice in the first subset of microservices, which provides the first subset of microservices for the service, wherein the update provides updated service code; and test the serviced code to test: the first subset of microservices, which is provided by at least one first portion of the updated service code; and a second subset of microservices, which is included in the plurality of microservices configured to provide the service, which is provided by at least one second portion of the updated service code that is not updated as part of the update and is dependent on at least one microservice in the first subset of microservices. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1 is a schematic diagram illustrating one embodiment of an information handling system (IHS).

[0008] Figure 2 is a schematic diagram illustrating one embodiment of a microservice update system.

[0009] Figure 3 It shows that Figure 2 A schematic diagram of an implementation of a build scheduler system provided in a microservice update system.

[0010] Figure 4 It shows that Figure 2 A schematic diagram of an implementation of a continuous integration system provided in a microservice update system.

[0011] Figure 5A is a flow diagram illustrating an embodiment of a portion of a method for updating a microservice.

[0012] Figure 5B is a flow diagram illustrating an embodiment of a portion of a method for updating a microservice.

[0013] Figure 6 It shows that Figure 2 A schematic diagram of an implementation of a code repository screen displayed on a developer system provided in the microservice update system.

[0014] Figure 7 It shows that Figure 2 A diagram of an implementation of a microservice update result screen displayed on a developer system provided in the microservice update system of FIG.

[0015] Figure 8 It shows that Figure 2 A diagram of an implementation of a microservice update result screen displayed on a developer system provided in the microservice update system of FIG. DETAILED DESCRIPTION

[0016] For the purposes of this disclosure, an information handling system may include any tool or collection of tools that can be operated to calculate, arithmetic, determine, classify, process, send, receive, retrieve, initiate, switch, store, display, communicate, indicate, detect, record, reproduce, process or utilize any form of information, intelligence or data for commercial, scientific, control or other purposes. For example, an information handling system can be a personal computer (e.g., a desktop or laptop computer), a tablet computer, a mobile device (e.g., a personal digital assistant (PDA) or a smart phone), a server (e.g., a blade server or a rack server), a network storage device, or any other suitable device, and can vary in size, shape, performance, functionality or price. An information handling system may include random access memory (RAM), one or more processing resources (such as a central processing unit (CPU) or control logic of hardware or software), ROM and / or other types of non-volatile memory. Additional components of an information handling system may include one or more hard drives, one or more network ports for communicating with external devices, and various input and output (I / O) devices, such as a keyboard, a mouse, a touch screen and / or a video display. An information handling system may also include one or more buses that can be operated to transmit communications between various hardware components.

[0017] In one embodiment, the IHS 100 ( Figure 1 ) includes a processor 102, which is connected to a bus 104. The bus 104 serves as a connection between the processor 102 and other components of the IHS 100. An input device 106 is coupled to the processor 102 to provide input to the processor 102. Examples of input devices may include a keyboard, a touch screen, a pointing device (such as a mouse, a trackball, and a touchpad), and / or various other input devices known in the art. Programs and data are stored on a mass storage device 108, which is coupled to the processor 102. Examples of mass storage devices may include a hard disk, an optical disk, a magneto-optical disk, a solid-state storage device, and / or various mass storage devices known in the art. The IHS 100 also includes a display device 110, which is coupled to the processor 102 via a video controller 112. A system memory 114 is coupled to the processor 102 to provide a fast storage device for the processor, thereby facilitating the execution of computer programs by the processor 102. Examples of system memory may include random access memory (RAM) devices (such as dynamic RAM (DRAM), synchronous DRAM (SDRAM)), solid-state storage devices, and / or various other storage devices known in the art. In one embodiment, chassis 116 houses some or all of the components of IHS 100. It should be understood that other buses and intermediate circuits can be deployed between the above-mentioned components and processor 102 to facilitate interconnection between the components and processor 102.

[0018] Reference now Figure 2 , which shows an embodiment of a microservice update system 200. In the embodiment, the microservice update system 200 includes one or more developer systems 202. In one embodiment, any or all of the developer systems 202 can be configured according to the above Figure 1 The developer systems 202 may be provided by the IHS 100 discussed, and / or may include some or more components of the IHS 100. In a specific example, any or all of the developer systems 202 may be provided by a desktop computing device, a laptop computing device / notebook computing device, a tablet computing device, and / or other user devices, and those skilled in the art in possession of the present disclosure will recognize that the developer systems 202 are configured to allow developers to provide software code that is used to provide microservices and microservice modifications / updates, as discussed below. In the illustrated embodiment, each developer system 202 includes a display device 202a, and those skilled in the art in possession of the present disclosure will recognize that the developer system 202 includes various other computing components to provide the functionality discussed below.

[0019] The microservice update system 200 also includes a source code management system 204, which is coupled to the developer system 202 (e.g., via one or more networks provided by a local area network (LAN), the Internet, etc.). In one embodiment, the source code management system 204 can be configured as follows: Figure 1 The source code management system 204 may be provided by the IHS 100 discussed above, and / or may include some or all of the components in the IHS 100. In a specific example, the source code management system 204 may be provided by one or more server devices and / or other devices (as will be appreciated by those skilled in the art having the present disclosure) that provide the functionality discussed below for services / source code (also referred to as "service code"). However, although shown and discussed as being provided by a server device, those skilled in the art having the present disclosure will appreciate that the source code management system 204 may be provided by a variety of devices that fall within the scope of the present disclosure.

[0020] The microservice update system 200 also includes a build scheduler system 206, which is coupled to the source code management system 204 (e.g., via one or more networks provided by a local area network (LAN), the Internet, etc.). In one embodiment, the build scheduler system 206 can be configured to execute the above-mentioned operations according to the above-mentioned configuration. Figure 1The construction scheduler system 206 may be provided by the IHS 100 discussed above, and / or may include some or all of the components in the IHS 100. In a specific example, the construction scheduler system 206 may be provided by one or more server devices and / or other devices (which those skilled in the art in possession of the present disclosure will recognize) that provide the functionality of the construction scheduler system discussed below. However, although shown and discussed as being provided by a server device, those skilled in the art in possession of the present disclosure will recognize that the construction scheduler system 206 may be provided by various devices that fall within the scope of the present disclosure.

[0021] The microservice update system 200 also includes a continuous integration system 208, which is coupled to the build scheduler system 206 (e.g., via one or more networks provided by a local area network (LAN), the Internet, etc.). In one embodiment, the continuous integration system 208 can be configured as described above according to Figure 1 The continuous integration system 208 may be provided by the IHS 100 discussed above, and / or may include some or all of the components in the IHS 100. In a specific example, the continuous integration system 208 may be provided by one or more server devices and / or other devices (which those skilled in the art in possession of the present disclosure will recognize) that provide the functionality of the continuous integration system discussed below. However, although shown and discussed as being provided by a server device, those skilled in the art in possession of the present disclosure will recognize that the continuous integration system 208 may be provided by a variety of devices that fall within the scope of the present disclosure.

[0022] The microservice update system 200 also includes a service configuration system 210, which is coupled to the continuous integration system 208 (e.g., via one or more networks provided by a local area network (LAN), the Internet, etc.). In one embodiment, the service configuration system 210 can be configured according to the above Figure 1The service configuration system 210 may be provided by the IHS 100 discussed, and / or may include some or all of the components of the IHS 100. In a specific example, the service configuration system 210 may be provided by one or more server devices (e.g., a network configuration "cloud" server device), and / or other devices (as can be recognized by those skilled in the art having the present disclosure), which provide the functionality of cloud-based service configuration discussed below. In the illustrated embodiment, the service configuration system 210 includes a plurality of microservices 210a, 210b, and up to 210c, which as discussed above may be provided by a collection of loosely connected, fine-grained code modules operating via a lightweight protocol, which provide modularity, making the services provided by the microservices 210a-c easier to understand, develop, and test, while also providing resilience against architectural erosion. Thus, an autonomous team of developers may utilize the developer system 202 to independently develop and extend the corresponding microservices 210a-c, while allowing continuous integration, delivery, and deployment of microservices providing related services through continuous refactoring and / or updating of the architecture in which any individual microservice appears. However, those skilled in the art having the present disclosure will appreciate that the service configuration system 210 will include various other computing components in order to provide the functionality discussed below.

[0023] The microservice update system 200 also includes one or more client systems 212, which are coupled to the service configuration system 210 (e.g., via one or more networks provided by a local area network (LAN), the Internet, etc.). In one embodiment, the client system 212 can be configured to update the microservice configuration system 210 according to the above Figure 1 The client system 212 may be provided by the IHS 100 discussed, and / or may include some or all of the components in the IHS 100. In a specific example, the client system 212 may be provided by one or more server devices, and / or other devices (as can be recognized by those skilled in the art in possession of the present disclosure), which provide consumption of services provided by the service configuration system as discussed below. However, although shown and discussed as server devices, those skilled in the art in possession of the present disclosure will recognize that the client system 212 may be provided by various devices that fall within the scope of the present disclosure. Although a specific microservice update system 200 has been illustrated and described, those skilled in the art in possession of the present disclosure will recognize that the microservice update system 200 of the present disclosure may include various components and component configurations while still remaining within the scope of the present disclosure.

[0024] Reference now Figure 3 , which shows an embodiment of building a scheduler system 300, which can provide the above Figure 2 Therefore, the construction scheduler system 300 can be constructed by the above according to Figure 1The discussed IHS 100 may be provided and / or may include some or all of the components of IHS 100, and in certain examples may be provided by one or more server devices. In addition, although shown and discussed as being provided by one or more server devices, those skilled in the art in possession of the present disclosure will recognize that the functionality of the build scheduler system 300 discussed below may be provided by other devices that are configured to operate in a manner similar to that described below. In the illustrated embodiment, the build scheduler system 300 includes a chassis 302 that houses the components of the build scheduler system 300, only some of which are described below. For example, the chassis 302 may house a processing system (not shown, but which may include the above according to Figure 1 The processor 102 discussed above) and a storage system (not shown, but which may include the above according to Figure 1 The memory 114 discussed above is coupled to the processing system and includes instructions that, when executed by the processing system, cause the processing system to provide a build scheduler engine 304, which is configured to implement the functionality of the build scheduler engine and / or build scheduler system discussed below.

[0025] The chassis 302 may also accommodate a storage system (not shown, but which may include the above according to Figure 1 108 ) is coupled to the build scheduler engine 304 (e.g., via a coupling between the storage system and the processing system) and includes a build scheduler database 306 that is configured to store any information utilized by the build scheduler engine 304 discussed below. The chassis 302 may also house a communication system 308 that is coupled to the build scheduler engine 304 (e.g., via a coupling between the communication system 308 and the processing system) and may be provided by a network interface controller (NIC), a wireless communication system (e.g., Bluetooth, a near field communication (NFC) component, a WiFi component, etc.), and / or any other communication component (as will be appreciated by those skilled in the art in possession of this disclosure). Although a particular build scheduler system 300 is shown, those skilled in the art in possession of this disclosure will recognize that a build scheduler system (or other device that operates in accordance with the teachings of this disclosure in a manner similar to that described below with respect to the build scheduler system 300) may include various components and / or component configurations that are used to provide the general functionality and the functionality discussed below while remaining within the scope of the present disclosure.

[0026] Reference now Figure 4 , which shows an embodiment of a continuous integration system 400, which can provide the above Figure 2 The continuous integration system 208 discussed. Therefore, the continuous integration system 400 can be implemented by the above Figure 1 The continuous integration system 400 discussed below may be provided by and / or may include some or all of the components of the IHS 100, and in certain examples may be provided by one or more server devices. Furthermore, while illustrated and discussed as being provided by one or more server devices, those skilled in the art in possession of the present disclosure will recognize that the functionality of the continuous integration system 400 discussed below may be provided by other devices configured to operate in a similar manner as discussed below. In the illustrated embodiment, the continuous integration system 400 includes a chassis 402 that houses components of the continuous integration system 400, only some of which are shown below. For example, the chassis 402 may house a processing system (not shown, but which may include the processing system described above according to Figure 1 The processor 102 discussed) and a storage system (not shown, but which may include the above according to Figure 1 The memory 114 discussed above is coupled to the processing system and includes instructions that, when executed by the processing system, cause the processing system to provide a continuous integration engine 404, which is configured to implement the functions of the continuous integration engine and / or continuous integration system discussed below.

[0027] The chassis 402 may also accommodate a storage system (not shown, but which may include the above according to Figure 1 4. The chassis 402 may also include a storage device 108 discussed above, which is coupled to the continuous integration engine 404 (e.g., via a coupling between the storage system and the processing system) and includes a continuous integration database 406 that is configured to store any information utilized by the continuous integration engine 404 discussed below. The chassis 402 may also house a communication system 408 that is coupled to the continuous integration engine 404 (e.g., via a coupling between the communication system 408 and the processing system) and may be provided by a network interface controller (NIC), a wireless communication system (e.g., Bluetooth, a near field communication (NFC) component, a WiFi component, etc.), and / or any other communication component (as will be appreciated by those skilled in the art in possession of this disclosure). Although a particular continuous integration system 400 is shown, those skilled in the art in possession of this disclosure will recognize that a continuous integration system (or other device that operates in accordance with the teachings of this disclosure in a manner similar to that described below with respect to the continuous integration system 400) may include various components and / or component configurations that are used to provide the general functionality and the functionality discussed below while remaining within the scope of this disclosure.

[0028] Now refer to Figure 5, which shows an embodiment of a method for updating microservices. As discussed below, the system and method of the present disclosure provide a more efficient update of microservices provided and enabled by service code, which is to limit the updates to be implemented on the service code to the updates of some parts of the service code that provide the microservice to be modified (e.g., modified using microservice modification code), and then test only the microservices that have been modified and the microservices that depend on the microservices that have been modified. For example, a developer can use a developer system to provide the microservice modification code to a source code management system, and a push request or a merge request causes the source code management system to send the microservice modification request to the build scheduler system. In response to receiving the microservice modification request, the build scheduler system can identify a first subset of microservices (from a plurality of microservices providing services) for which modifications have been requested (i.e., via microservice modification requests and / or microservice modification codes), and can trigger a corresponding microservice pipeline for each microservice in the first subset of microservices.

[0029] The continuous integration system will accept the microservice modification code for each microservice in the first subset of microservices via the corresponding microservice pipeline of each microservice in the first subset of microservices, and will operate to update at least one first part of the service code providing the first subset of microservices using the corresponding microservice modification code. The continuous integration system will then test the first subset of microservices provided by the first part of the updated service code, and the second subset of microservices that depend on the first subset of microservices (from multiple microservices providing the service). The continuous integration system will then provide the results of the test for display to the developer through its developer system, and if the test passes, the updated service code can be automatically deployed on the service configuration system so that the service can be provided to the user through its user device. Therefore, a more efficient update of the service in response to the modification of one or more microservices in its microservices is provided, wherein the modification of a single microservice requires a relatively short build time, which consumes a relatively small amount of resources, which can enhance the ability to perform parallel build operations through the microservice manufacturing chain.

[0030] The method 500 begins at block 502, where a developer system provides microservice modification code to a source code management system. In one embodiment, at block 502, a developer may utilize the developer system 202 to provide microservice modification code configured to modify any one of the plurality of microservices 210a-210c, which enables the service configuration system 210 to provide a service. Figure 6 , including a developer system 600 of a display device 602 (which may be Figure 22 (one of the developer systems 202 shown) including a display device 202a is shown displaying one embodiment of a code library screen 604 that displays a hierarchy of service code that enables services provided by the service configuration system 210. Figure 6 In the particular example shown in , the codebase screen 604 shows how the “out of the box” particular service includes five microservices:

[0031] "DATA-STORAGE-MONGO" microservice, "MFT-FORWARDER" microservice, "PY-DATA-HANDLER" microservice, "PY-DATA-SERVICE" microservice, and "UI" microservice. For example, the "RAILAI" service may be provided by a folder that includes five subfolders, which are the root directories of the five microservices discussed above. However, although specific services and microservices are shown and described below for illustrative purposes, those skilled in the art in possession of the present disclosure will recognize that services, their associated service code, and the microservices that provide the services may be organized in a variety of ways that will still fall within the scope of the present disclosure.

[0032] Thus, at block 502 and with reference to the example of services and microservices discussed above, a developer may utilize their developer subsystem 202 to provide microservice modification code for the “MFT-FORWARDER” microservice and the “PY-DATA-HANDLER” microservice to the source code management system 204. Additionally, as the microservice modification code is provided, at block 502, the developer may use the developer system 202 to provide a request to incorporate the microservice modification code into the service code providing the service. Continuing with the example of services and microservices discussed above, at block 502, the developer may use the developer system 202 to provide a “push” request, a “merge” request, and / or other requests known in the art to request that the microservice modification code for the “MFT-FORWARDER” microservice and the “PY-DATA-HANDLER” microservice be incorporated into the “RAILAI” service.

[0033] The method 500 then proceeds to block 504, where the source code management system provides the microservice modification request to the build scheduler system. In one embodiment, at block 504, the source code management system 204 can generate a microservice modification request and provide the microservice modification request to the build scheduler system 206. For example, the source code management system 204 can be configured using a "webhook" that is triggered in response to receiving a push request or a merge request discussed above, and the webhook can provide for the sending of a hypertext transfer protocol (HTTP) request to the build scheduler system 206, which provides the microservice modification request at block 504. For example, the HTTP request providing the microservice modification request can include and / or identify information about the microservice (e.g., via a build request payload) for which the microservice modification code has been provided in the source code management system 204 at block 502. However, although specific microservice modification requests have been described, those skilled in the art having the present disclosure will recognize that requests to modify microservices may be provided to the build scheduler system 206 in a variety of ways, which will fall within the scope of the present disclosure.

[0034] The method 500 then proceeds to block 506, where the build scheduler system identifies a first subset of microservices from the plurality of microservices providing services and requests modifications therefor. In one embodiment, at block 506, the build scheduler engine 304 in the build scheduler system 300 may receive a microservice modification request (e.g., the HTTP request discussed above) through its communication system 308, and in response may analyze the HTTP request to determine a first subset of microservices from the plurality of microservices 210a-c providing services discussed above, for which modifications are requested. For example, at block 506, the build scheduler engine 304 may analyze the build request payload (which is included or identified by the HTTP request providing the microservice modification request), and may determine a first subset of microservices for which modifications are requested based on the analysis. In some embodiments, the operation of the build scheduler engine 304 at block 506 may differ depending on whether the microservice modification request is provided in response to a push request from a developer at block 502 or in response to a merge request from a developer at block 502.

[0035] For example, if a microservice modification request (e.g., an HTTP request) includes a request header indicating that it is associated with a merge request (e.g., the "webhook" discussed above is a merge request webhook), the build scheduler engine 304 can be operated to extract from the build request payload one or more source branches including the microservice modification code provided by the developer, the target branch and the source branch being requested to be combined with the following items: the git secure shell (SSH) uniform resource locator (URL) of the source code repository; the project identification number (e.g., in Gitlab); the most recent commit; the email address of the developer who submitted the merge request; and / or, various other information, which is obvious to those skilled in the art in possession of the present disclosure. However, although examples of information retrieved in response to a merge request are detailed above, those skilled in the art in possession of the present disclosure will recognize that information that can be retrieved by the build scheduler engine 304 in response to a push request, and therefore the retrieval of such information will also fall within the scope of the present disclosure.

[0036] Continuing with the above example, where a microservice modification request (e.g., an HTTP request) is associated with a merge request, at block 506, the build scheduler engine 304 in the build scheduler system 300 is operable to spawn a child thread and process the microservice modification request by, for example, cloning a source code repository and calculating the difference between a source branch and a target branch (using, for example, a "git subtract" operation with a "name only" flag set (e.g., "" set (e.g., "" such as "")). As will be appreciated by those skilled in the art in possession of the present disclosure, the use of the git subtract operation with the name only flag in the manner described above will return a list of paths to files that have been modified. Continuing with the specific example provided above, where a developer requests to modify the "MFT-FORWARDER" microservice and the "PY-DATA-HANDLER" microservice, the use of the "git subtract" operation with the "name only" flag may return a list of paths to the two files:

[0037] MFT-FORWARDER / setup.py

[0038] PY-DATA-HANDLER / setup.py

[0039] However, while a specific example has been described in which a first subset of microservices is identified and modifications are requested for the first subset of microservices, those skilled in the art in possession of the present disclosure will recognize that the modified microservices may be identified using other techniques, which would fall within the scope of the present disclosure.

[0040] The method 500 then proceeds to block 508, where the build scheduler system triggers a corresponding microservice pipeline for each microservice in the first subset of microservices. In one embodiment, at block 508, the build scheduler engine 304 in the build scheduler system 300 may be operable to trigger a corresponding microservice pipeline for each microservice in the first subset of microservices identified as discussed above. For example, at block 508 and continuing with the specific example discussed above, the build scheduler engine 304 may process a list of paths to two files (e.g., the paths to the files "MFT-FORWARDER / setup.py" and "PY-DATA-HANDLER / setup.py" discussed above), thereby retrieving only the root path folders for "MFT-FORWARDER" and "PY-DATA-HANDLER", and may then iterate over the list of microservices to trigger a related pipeline for the continuous integration system 208 for each microservice. This is in contrast to conventional systems which do not provide the ability to generate pipelines on a microservice basis (e.g., can be placed in the root of the corresponding microservice folder), but instead only allow generation of a single pipeline file to be applied to the entire service / source code.

[0041] For example, the continuous integration system 208 / 400 may include an automatic server engine that is part of the continuous integration engine 404 and is configured as an automatic part of the software development process to provide continuous integration and / or facilitate technical aspects of continuous delivery. In the specific examples discussed below, the automatic server engine is provided by JENKINS open source software, although those skilled in the art in possession of the present disclosure will recognize that various server automation subsystems will fall within the scope of the present disclosure. In these examples, the corresponding pipeline of each microservice can be triggered via the JENKINS application programming interface (API) by providing the pipeline name in JENKINS and a payload with pipeline parameters. In addition, to configure pipeline calls, the build scheduler engine 304 in the build scheduler system 300 can utilize a dictionary that maps microservice names to their corresponding parameters, and the code of an example is provided below:

[0042]

[0043]

[0044] Those skilled in the art who have the present disclosure will recognize that the key of the above dictionary is the microservice root folder name, and the value is a parameter, including the pipeline name in JENKINS (which can be configured in the URL), and the payload passed to the pipeline to fill its variables, wherein the variables include: the branch name to be checked out, the application name for setting the working directory, the Python path for configuring Python custom imports, the user email of the developer for notifying the pipeline process, and the project ID and submission ID of the update submission (for example, in Gitlab) according to the pipeline result (for example, in progress, running, failed, aborted, etc.). In this particular example, the parameters can be passed to the pipeline, because the pipeline is unique for all microservices. In addition, those skilled in the art who have the present disclosure will recognize that the examples of the above microservices are all encoded in the Python programming language, and therefore may all be organized according to a standard code, so that they can be built according to the same steps, and only the configuration (provided by the payload) is different. However, those skilled in the art who have the present disclosure will also recognize how to use microservices encoded in different programming languages ​​with slight changes, and these changes also fall within the scope of the present disclosure.

[0045] The method 500 then proceeds to block 510, where the continuous integration system receives corresponding microservice modification code via the corresponding microservice pipeline for each microservice in the first subset of microservices, and then proceeds to block 512, where the continuous integration system updates at least one first portion of service code that provides the corresponding microservice modification code for the first subset of microservices. In one embodiment, at block 510, the continuous integration engine 404 in the continuous integration system 208 / 400 may receive the corresponding microservice modification code (e.g., provided by a developer at block 502) via the corresponding microservice pipeline for each microservice in the first subset of microservices triggered at block 508. Furthermore, in embodiments of block 512, the continuous integration engine 404 in the continuous integration system 208 / 400 uses the microservice modification code received via the microservice pipeline to update at least one first portion of service code that provides the first subset of microservices.

[0046] Thus, continuing with the specific example provided above, at blocks 510 and 512, the continuous integration engine 404 in the continuous integration system 208 / 400 may be operated to update the first portion of the service code that provides the "MFT-FORWARDER" microservice and the "PY-DATA-HANDLER" microservice using the microservice modification code provided by the developer at block 502. Those skilled in the art in possession of the present disclosure will recognize that updating the service code using the microservice modification code may be handled by a code version control system and will not be described in detail herein. Thus, other microservices that provide services (e.g., Figure 6 The "DATA-STORAGE-MONGO" microservice, the "PY-DATA-SERVICE" microservice, and the "UI" microservice shown in ) are not processed to update any part of the service code because they are not modified by the merge request discussed above. Those skilled in the art in possession of the present disclosure will recognize that modifications to the microservices that provide services in this manner will result in faster build times because less code is processed to implement the modifications while also consuming fewer resources to perform the build. Therefore, for any particular build / software modification environment, more builds can be performed in parallel using the techniques of the present disclosure due to more efficient utilization of resources in that build / software environment.

[0047] The method 500 then proceeds to block 514, where the continuous integration system tests a first subset of microservices provided by at least one first portion of the updated service code. In one embodiment, at block 514, the continuous integration engine 404 in the continuous integration system 208 / 400 is operable to test the first subset of microservices provided by at least one first portion of the service code updated at block 512. Continuing with the example provided above, the continuous integration engine 404 may test the "MFT-FORWARDER" microservice and the "PY-DATA-HANDLER" microservice, which are provided by the first portion of the service code and updated using the microservice modification code at block 512. As will be appreciated by those skilled in the art in possession of the present disclosure, testing the portion of the service code modified at block 512 may include various other testing operations known in the art, which will be discussed in more detail below.

[0048] The method 500 then proceeds to block 516, where the continuous integration system tests the second subset of microservices that are dependent on the first subset of microservices. In one embodiment, at block 516, the continuous integration engine 404 in the continuous integration system 208 / 400 may be operated to test the second subset of microservices that are dependent on the modified first subset of microservices, and may be provided by at least a second portion of the service code that is not updated at block 512. Continuing with the example provided above, the continuous integration engine 404 may test the "PY-DATA-SERVICE" microservice provided by the second portion of the service code that is not updated at block 512. As will be appreciated by those skilled in the art having the present disclosure, testing of the portion of the service code that is dependent on the microservice updated at block 512 may include testing any second microservice that consumes the output generated by the modified first microservice, and performing various test operations known in the art, which will be discussed in further detail below. Therefore, in some examples, any microservice downstream of the modified microservice may be tested at block 514. Furthermore, although shown and discussed as being implemented independently, at least some of the testing at blocks 514 and 516 may be performed in parallel while still remaining within the scope of the present disclosure.

[0049] For example, the testing operations performed at blocks 512 and 514 may include performing unit testing using a "mock and stubbing" technique that is used to replace dependencies (e.g., in a database). As will be appreciated by those skilled in the art who possess the present disclosure, unit testing can be run quickly and does not require the code being tested to be deployed. Subsequently, integration testing may be performed in which the microservice being tested is deployed to Pivotal Cloud Foundary (PCF) along with the microservices it depends on, and a Representational State Transfer (REST) ​​request is sent to the microservice REST application programming interface (APIs) so that the corresponding reply can be verified (e.g., by verifying the http status, a payload containing messages and results, and / or other reply information known in the art). The testing operations may also include checking records in a database in the case where the APIs discussed above retain some information, ensuring that the messages exchanged by the microservices are successfully processed and / or sent / received by verifying that these dependent microservices also operate according to their expected logic (e.g., by processing and saving records in a database).

[0050] Continuing with the specific example discussed above, where the “MFT-FORWARDER” microservice and the “PY-DATA-HANDLER” microservice are modified and include a “PY-DATA-SERVICE” microservice that depends on at least one of them, these microservices may be provided in a chain where the “PY-DATA-SERVICE” microservice depends on the “PY-DATA-HANDLER” microservice, which also depends on the “MFT-FORWARDER” microservice. When the build scheduler system 206 / 300 receives a microservice modification request and retrieves the microservice modification code for each of the "MFT-FORWARDER" microservice and the "PY-DATA-HANDLER" microservice, the build scheduler system 206 / 300 can trigger two parallel builds: the first build for the "MFT-FORWARDER" microservice will deploy the "MFT-FORWARDER" microservice, the "PY-DATA-HANDLER" microservice, and the "PY-DATA-SERVICE" microservice, and run the tests discussed above. The build will use the code branch that includes the microservice modification code for the "MFT-FORWARDER" microservice and the "PY-DATA-HANDLER" microservice, and the test operation will execute the microservice modification code for the "MFT-FORWARDER" microservice and the microservice modification code for the "PY-DATA-HANDLER" microservice, while also verifying the microservice modification code integrated with the "PY-DATA-SERVICE" microservice (even if the "PY-DATA-SERVICE" microservice is not modified). In addition, the build scheduler system 206 / 300 will trigger a second build for the "PY-DATA-HANDLER" microservice, which will deploy the "PY-DATA-HANDLER" microservice and the "PY-DATA-SERVICE" microservice and run the tests discussed above.

[0051] The method 500 then proceeds to decision block 518, where the continuous integration system determines whether all microservices providing services have passed the test. In one embodiment, at decision block 518, the continuous integration engine 404 in the continuous integration system 208 / 400 can operate to determine whether each microservice tested at blocks 514 and 516 has passed the test (e.g., by determining whether the microservice is performing the desired function, such as generating the expected output discussed above). If at decision block 518, the continuous integration system determines that all microservices providing services have passed the test, the method 500 proceeds to block 520, where the continuous integration system provides test results for display on the developer subsystem. In one embodiment, at block 520 and in response to determining that all microservices tested at blocks 514 and 516 have passed the test, the continuous integration engine 404 in the continuous integration system 208 / 400 can generate test results and provide these test results for display on the developer system 202. For example, as will be appreciated by those skilled in the art in possession of the present disclosure and with reference to the examples provided above, when a microservice pipeline is completed, the continuous integration engine 404 in the continuous integration system 208 / 400 can update the commit build request provided by the merge request, which allows developers to use their respective developer systems 202 to verify which microservices (i.e., the first subset of microservices discussed above) are rebuilt as part of the code change, as well as the results of running each microservice pipeline.

[0052] For example, refer to Figure 7 , the developer system 600 is shown as providing a microservice update results screen 700, which in the illustrated embodiment provides test results for updating the "MFT-FORWARDER" microservice and the "PY-DATA-HANDLER" microservice discussed above. As can be seen in the microservice update results screen 700, the developer can examine the two builds associated with the latest commit of their merge request, which in the illustrated embodiment indicates that the "MFT-FORWARDER" microservice and the "PY-DATA-HANDLER" microservice have been updated and have passed their tests.

[0053] The method 500 may then proceed to optional block 522, where the continuous integration system automatically deploys the updated service code on the service configuration system. In one embodiment, at optional block 522, the continuous integration engine 404 in the continuous integration system 208 / 400 may operate to automatically deploy the updated service code on the service processing system 210 so that the service processing system 210 may provide its associated services (e.g., via microservices 210a-c, at least some of which have been updated) to the client system 212. In another example, the deployment of the updated service code may be in response to the developer selecting an “ACCEPT MERGE REQUEST” button on the microservice update results screen 700.

[0054] refer to Figure 8 , the developer system 600 is shown as providing a microservice update result screen 800, which in the illustrated embodiment provides the test results of updating the "MFT-FORWARDER" microservice and the "PY-DATA-HANDLER" microservice discussed above. As those skilled in the art who possess the contents of this disclosure will appreciate, when the source branch is merged into the main branch, the developer can be notified again so that they can verify the results of the build triggered on the main branch. Therefore, continuing the specific example discussed above, after the developer merges the updated service code with the main branch, the merge commit build update (e.g., in Gitlab) can be verified to confirm that the "MFT-FORWARDER" microservice and the "PY-DATA-HANDLER" microservice have been successfully updated and deployed to the stage and production environments. As can be seen in the microservice update result screen 700, the developer can check the updates of the stage and production environments, the "MFT-FORWARDER" microservice and the "PY-DATA-HANDLER" microservice updates, which indicate that each microservice has been updated and passed its tests.

[0055] If at decision block 518, the continuous integration system determines that at least one of the microservices providing the service has not passed the test, the method 500 proceeds to block 524, where the continuous integration system provides the test results for display on the developer subsystem. In one embodiment, at block 524, and in response to determining that at least one microservice has not passed the test at blocks 514 and / or 516, the continuous integration engine 404 in the continuous integration system 208 / 400 can generate and provide microservice update result screens on the developer system 202 / 600 that are consistent with the microservice update result screens. Figure 7 and Figure 8, but it indicates which microservice failed its test. Therefore, when developers try to update / modify their microservices unsuccessfully or there is a problem with the operation of the service code and the service configuration system 210 providing services to the client system, the developer 212 is notified.

[0056] In a particular implementation, the systems and methods of the present disclosure may require that a developer creating a new microservice add an entry to a map in the build scheduler system 206 that allows for configuration of pipelines (e.g., via Jenkins discussed above) and pipeline parameters, as well as the creation of a new pipeline (which may be executed in Jenkins by cloning an existing pipeline). In addition, when developers are added to or removed from a team of developers authorized to modify the microservices that provide the service, the user / developer profile in the build scheduler system 206 may need to be updated to add / remove their associated email addresses, user identifiers, and security tokens (e.g., in Jenkins), which may be used to authenticate build triggering HTTP requests and for recording build-related information (e.g., in Jenkins). In addition, those skilled in the art in possession of the present disclosure will recognize that when the build scheduler system 206 is provided via a Python application, it may be deployed using PIP and may be registered with LINUX or systemd to allow LINUX to manage the application at runtime.

[0057] Thus, systems and methods have been described to provide a selective build of modified microservices provided by service code that implements the service, thereby providing more efficient microservice updates, by limiting the updates performed on the service code to update the portion of the service code that provides the modified microservice (e.g., modified using microservice modification code), and then testing only the modified microservice and microservices that depend on the modified microservice. For example, in response to receiving a microservice modification request, a build scheduler system may identify a first subset of microservices (from a plurality of microservices that provide services) for which modifications have been requested, and may trigger a corresponding service pipeline for each microservice in the first subset of microservices. A continuous integration system then receives microservice modification code for each microservice in the first subset of microservices through its corresponding microservice pipeline, and will operate to update the microservice modification code corresponding to at least one first portion of the service code that provides the first subset of microservices. The continuous integration system will then test the first subset of microservices provided by the first portion of the updated service code, and test a second subset of microservices that depend on the first subset of microservices (from a plurality of microservices that provide services). The continuous integration system then provides the test results to be displayed to the developer through its developer system, and if the test passes, the updated service code can be automatically deployed on the service configuration system, so that the service can be provided to the customer through its customer device. Therefore, a more efficient service update in response to modifying one or more of its microservices is provided, wherein the modification of a single microservice requires a relatively short build time, which consumes a relatively small amount of resources, thereby enhancing the ability to perform parallel build operations.

[0058] Although illustrative embodiments have been shown and described, extensive modifications, changes, and substitutions are contemplated in the foregoing disclosure, and in some cases, some features of the embodiments may be employed without the corresponding use of other features. It is therefore appropriate that the appended claims be interpreted broadly in a manner consistent with the scope of the embodiments disclosed herein.

Claims

1. A microservice update system, comprising: Build the scheduler system, which is configured to: Receive microservice modification requests; identifying a first subset of microservices, the first subset of microservices being included in a plurality of microservices configured to provide a service, and for which modification has been requested in the microservice modification request; as well as triggering a corresponding microservice pipeline for each microservice in the first subset of microservices; as well as A continuous integration system coupled to the build scheduler system and configured to: receiving, via a corresponding microservice pipeline triggered for each microservice in the first subset of microservices, corresponding microservice modification code for each microservice in the first subset of microservices; updating at least one first portion of service code providing the first subset of microservices for the service using the corresponding microservice modification code for each microservice in the first subset of microservices, wherein the updating provides updated service code; as well as Test the updated service code to test: The first subset of microservices is provided by at least one first portion of the updated service code; as well as a second subset of microservices included in the plurality of microservices configured to provide the service, the second subset of microservices being provided by at least one second portion of the updated service code that is not updated as part of the update, and being dependent on at least one microservice in the first subset of microservices.

2. The system of claim 1, wherein the continuous integration system is configured to: In response to testing the updated service code, determining that each of the first subset of microservices and the second subset of microservices has passed the test; and, For display on a developer system, an indication is provided that each of the first subset of microservices and the second subset of microservices has passed the test.

3. The system of claim 1, wherein the continuous integration system is configured to: In response to determining that each of the first subset of microservices and the second subset of microservices has passed the test, automatically deploying the updated service code to a service configuration system.

4. The system of claim 1, wherein the continuous integration system is configured to: In response to the testing of the updated service code, determining that at least one of the first subset of microservices and the second subset of microservices has not passed the testing; and For display on a developer system, an indication is provided that at least one of the first subset of microservices and the second subset of microservices has not passed the test.

5. The system of claim 1, wherein the second subset of microservices is dependent on at least one subset of the microservices because the second subset of microservices utilizes at least one output generated by at least one subset of the microservices during the testing.

6. The system of claim 1 , wherein the first subset of microservices includes at least two microservices, and wherein the updating provides at least a first portion of service code of the first subset of microservices for the service, comprising: The at least two microservices included in the first subset of microservices are updated in parallel.

7. An information processing system comprising: Processing systems; as well as a storage system coupled to the processing system and comprising instructions that, when executed by the processing system, cause the processing system to provide a continuous integration engine, the continuous integration engine being configured to: receiving, for each microservice in a first subset of microservices, respective microservice modification codes for each microservice in the first subset of microservices, the first subset of microservices being included in the plurality of microservices configured to provide services and for which modifications have been requested; updating at least a first portion of service code providing the first subset of microservices for the service using the corresponding microservice modification code for each microservice in the first subset of microservices, wherein the updating provides updated service code; as well as Test the updated service code to test: The first subset of microservices provided by at least one first portion of the updated service code; as well as A second subset of microservices, included in the plurality of microservices configured to provide the service, the second subset of microservices being provided by at least one second portion of the updated service code that is not updated as part of the update, and being dependent on at least one microservice in the first subset of microservices.

8. The information processing system of claim 7, wherein the continuous integration engine is configured to: In response to the testing of the updated service code, determining that each of the first subset of microservices and the second subset of microservices has passed the testing; and For display on a developer system, an indication is provided that each of the first subset of microservices and the second subset of microservices has passed the test.

9. The information processing system of claim 8, wherein the continuous integration engine is configured to: In response to determining that each of the first subset of microservices and the second subset of microservices has passed the test, automatically deploying the updated service code to a service configuration system.

10. The information processing system of claim 7, wherein the continuous integration engine is configured to: In response to the testing of the updated service code, determining that at least one of the first subset of microservices and the second subset of microservices has not passed the testing; and For display on a developer system, an indication is provided that at least one of the first subset of microservices and the second subset of microservices has not passed the test.

11. The information processing system of claim 7, wherein the second subset of microservices is dependent on the at least one subset of microservices because the second subset of microservices utilizes at least one output generated by the at least one subset of microservices during the testing.

12. The information processing system of claim 7, wherein the first subset of microservices includes at least two microservices, and wherein the updating provides at least a first portion of service code of the first subset of microservices for the service, comprising: The at least two microservices included in the first subset of microservices are updated in parallel.

13. The information processing system of claim 7, wherein the storage system includes instructions that, when executed by the processing system, cause the processing system to provide a build scheduler engine, the build scheduler engine being configured to: Receive microservice modification requests; identifying a first subset of the microservices included in the plurality of microservices configured to provide for the service, and for which modification has been requested in the microservice modification request; as well as A corresponding microservice pipeline is triggered for each microservice in the first subset of microservices, causing the continuous integration engine to receive the corresponding microservice modification code for each microservice in the first subset of microservices.

14. A method for updating a microservice, comprising: receiving, by a continuous integration system, for each microservice in a first subset of microservices, corresponding microservice modification code for each of the first subset of microservices, the first subset of microservices being included in a plurality of microservices configured to provide services and for which modifications have been requested; updating, by the continuous integration system, each microservice in the first subset of microservices using the corresponding microservice modification code, at least one first portion of service code providing the first subset of microservices for the service, wherein the update provides updated service code; as well as The updated service code is tested through the continuous integration system to test: The first subset of microservices is provided by at least one first portion of the updated service code; as well as A second subset of microservices, included in the plurality of microservices configured to provide the service, the second subset of microservices being provided by at least one second portion of the updated service code that is not updated as part of the update, and being dependent on at least one microservice in the first subset of microservices.

15. The method of claim 14, further comprising: determining, by the continuous integration system, in response to the test of the updated service code, that each of the first subset of microservices and the second subset of microservices has passed the test; and For display on a developer system, an indication is provided, by the continuous integration system, that each of the first subset of microservices and the second subset of microservices has passed the test.

16. The method of claim 14, further comprising: By the continuous integration system, in response to determining that each of the first subset of microservices and the second subset of microservices has passed the test, the updated service code is automatically deployed to a service configuration system.

17. The method of claim 14, further comprising: determining, by the continuous integration system, in response to the test of the updated service code, that at least one of the first subset of microservices and the second subset of microservices has not passed the test; as well as For display on a developer system, an indication is provided, by the continuous integration system, that at least one of the first subset of microservices and the second subset of microservices has not passed the test.

18. The method of claim 14, wherein the second subset of microservices is dependent on the at least one subset of microservices based on the second subset of microservices utilizing at least one output generated by the at least one subset of microservices during the testing.

19. The method of claim 14, wherein the first subset of microservices includes at least two microservices, and wherein the updating provides at least a first portion of service code of the first subset of microservices for the service, comprising: The at least two microservices included in the first subset of microservices are updated in parallel.

20. The method of claim 14, further comprising: Receive microservice modification requests by building a scheduler system; identifying, by the build scheduler system, a first subset of the microservices included in the plurality of microservices configured to provide the service, and for which modifications have been requested in the microservice modification request; as well as The corresponding microservice pipeline is triggered for each microservice in the first subset of microservices through the build scheduler system, causing the continuous integration engine to receive the corresponding microservice modification code for each microservice in the first subset of microservices.

Images