Automatically validated release candidates for data-driven applications by automated publishing of integration microservice and data container tuple

Patent metadata

Field	Value
Publication number	US-10108534-B2
Application number	US-201615297916-A
Country	US
Kind code	B2
Filing date	Oct 19, 2016
Priority date	Oct 19, 2016
Publication date	Oct 23, 2018
Grant date	Oct 23, 2018

Abstract

A system and method for automatically validated release candidates for data-driven applications includes monitoring a first microservice and a second microservice. A respective functionality of each microservice is independently verifiable. The method also includes determining whether at least one of the first microservice and the second microservice is updated. The first microservice includes a first liveness probe and the second microservice includes a second liveness probe. The method further includes, responsive to determining that the first microservice is updated, updating the first liveness probe using a first data schema. The first data schema is associated with the first microservice.

First claim

The invention is claimed as follows:

1. A method comprising:
monitoring a first microservice and a second microservice, wherein a respective functionality of each microservice is independently verifiable;
determining whether at least one of the first microservice and the second microservice is updated, wherein the first microservice includes a first liveness probe and the second microservice includes a second liveness probe; and
responsive to determining that the first microservice is updated, updating the first liveness probe using a first data schema, wherein the first data schema is associated with the first microservice.

2. The method of claim 1 , wherein monitoring the first microservice and the second microservice includes monitoring a first release tag of the first microservice and a second release tag of the second microservice, wherein the first release tag and the second release tag indicate whether the first microservice and the second microservice are updated, respectively.

3. The method of claim 1 , further comprising determining whether the first liveness probe fails.

4. The method of claim 3 , further comprising responsive to determining that the first liveness probe has failed, rolling back the first microservice.

5. The method of claim 3 , further comprising responsive to determining that the first liveness probe has passed, packaging the first microservice with first testing data to form a first tuple of a first service-dataplane container, wherein the first testing data is associated with the first data schema.

6. The method of claim 5 , further comprising:
determining that the second microservice is updated;
updating the second liveness probe using a second data schema, wherein the second data schema is associated with the second microservice; and
responsive to determining that the second liveness probe has passed, packaging the second microservice with second testing data to form a second tuple of a second service-dataplane container, wherein the second testing data is associated with the second data schema.

7. The method of claim 6 , further comprising creating a union database, wherein the union database includes the first service-dataplane container and the second service-dataplane container.

8. The method of claim 7 , further comprising:
updating an application liveness probe in an updated application using the first service-dataplane container and the second service-dataplane container;
determining whether the application liveness probe fails;
responsive to determining that the first liveness probe has failed, rolling back to an existing application version; and
responsive to determining that the first liveness probe has passed, deploying the updated application.

9. The method of claim 1 , further comprising:
detecting that a second data schema associated with the second microservice is updated; and
updating the second liveness probe using the second data schema.

10. The method of claim 9 , further comprising determining whether the second liveness probe fails.

11. The method of claim 10 , further comprising responsive to determining that the second liveness probe has failed, rolling back the second data schema.

12. The method of claim 10 , further comprising responsive to determining that the second liveness probe has passed, packaging the second microservice with second testing data to form a second tuple of a second service-dataplane container, wherein the second testing data is associated with the second data schema.

13. A system comprising:
a memory; and
one or more processors in communication with the memory;
wherein the one or more processors, when executed:
monitor a first microservice and a second microservice, wherein a respective functionality of each microservice is independently verifiable;
determine whether at least one of the first microservice and the second microservice is updated, wherein the first microservice includes a first liveness probe and the second microservice includes a second liveness probe; and
responsive to determining that the first microservice is updated, update the first liveness probe using a first data schema, wherein the first data schema is associated with the first microservice.

14. The system of claim 13 , wherein the one or more processors determine whether the first liveness probe fails.

15. The system of claim 14 , wherein responsive to determining that the first liveness probe has failed, the one or more processors roll back the first microservice.

16. The system of claim 14 , wherein responsive to determining that the first liveness probe has passed, the one or more processors package the first microservice with first testing data to form a first tuple of a first service-dataplane container, wherein the first testing data is associated with the first data schema.

17. The system of claim 16 , wherein the one or more processors, when executed:
determine that the second microservice is updated;
update the second liveness probe using a second data schema, wherein the second data schema is associated with the second microservice; and
responsive to determining that the second liveness probe has passed, package the second microservice with second testing data to form a second tuple of a second service-dataplane container, wherein the second testing data is associated with the second data schema.

18. The system of claim 17 , wherein the one or more processors create a union database, wherein the union database includes the first service-dataplane container and the second service-dataplane container.

19. The system of claim 18 , wherein the one or more processors:
update an application liveness probe in an updated application using the first service-dataplane container and the second service-dataplane container;
determine whether the application liveness probe fails;
responsive to determining that the first liveness probe has failed, roll back to an existing application version; and
responsive to determining that the first liveness probe has passed, deploy the updated application.

20. A non-transitory machine readable medium storing instructions, which when executed by one or more processors in a computer system, cause the computer system to perform a method comprising:
monitoring a first microservice and a second microservice, wherein a respective functionality of each microservice is independently verifiable;
determining whether at least one of the first microservice and the second microservice is updated, wherein the first microservice includes a first liveness probe and the second microservice includes a second liveness probe; and
responsive to determining that the first microservice is updated, updating the first liveness probe using a first data schema, wherein the first data schema is associated with the first microservice.

Assignees

• Red Hat Inc

Inventors

• Vyas Jay
• Chen Huamin

Classifications

• G06F11/368

  for test version control, e.g. updating test cases to a new software version · CPC title

• G06F9/455

  Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines · CPC title

• G06F8/65 Primary

  Updates (security arrangements therefor G06F21/57) · CPC title

• G06F8/71

  Version control (security arrangements therefor G06F21/57); Configuration management · CPC title

• G06F11/14

  Error detection or correction of the data by redundancy in operations (error detection or correction of the data by redundancy in hardware G06F11/16) · CPC title