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

1. A method comprising:

detecting an update to a first data schema associated with a first microservice among a plurality of microservices, wherein a respective functionality of each of the plurality of microservices is independently verifiable, wherein each of the plurality of microservices includes a liveness probe; and

responsive to detecting that the first data schema is updated, updating a first liveness probe of the first microservice using the updated first data schema.

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

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

4. The method of claim 2 , 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.

5. The method of claim 4 , wherein the first data schema includes fields for data, wherein the first testing data includes same fields as the fields of the first data schema.

6. The method of claim 4 , wherein the first testing data is a snapshot of data used by the first microservice.

7. The method of claim 4 , further comprising:

determining whether at least one of the plurality of microservices is updated; and

responsive to determining that a second microservice among the plurality of microservices is updated, updating a second liveness probe of the second microservice using a second data schema, wherein the second data schema is associated with the second microservice.

8. The method of claim 7 , further comprising:

determining whether the second liveness probe passes; 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.

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

10. The method of claim 9 , 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 passes or fails;

responsive to determining that the application liveness probe has failed, rolling back to an existing application version; and

responsive to determining that the application liveness probe has passed, deploying the updated application.

11. The method of claim 1 , wherein the update to the first data schema comprises an addition of a new field.

12. A system comprising:

a memory; and

one or more processors in communication with the memory;

wherein the one or more processors, when executed:

detect an update to a first data schema associated with a first microservice among a plurality of microservices, wherein a respective functionality of each of the plurality of microservices is independently verifiable, wherein each of the plurality of microservices includes a liveness probe; and

responsive to detecting that the first data schema is updated, update a first liveness probe of the first microservice using the updated first data schema.

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

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

15. The system of claim 13 , 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.

16. The system of claim 15 , wherein the first data schema includes fields for data, wherein the first testing data includes same fields as the fields of the first data schema.

17. The system of claim 15 , wherein the first testing data is a snapshot of data used by the first microservice.

18. The system of claim 15 , wherein the one or more processors:

determine whether at least one of the plurality of microservices is updated; and

responsive to determining that a second microservice among the plurality of microservices is updated, update a second liveness probe of the second microservice using a second data schema, wherein the second data schema is associated with the second microservice.

19. The system of claim 18 , wherein the one or more processors:

determine whether the second liveness probe passes; 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.

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:

detecting an update to a first data schema associated with a first microservice among a plurality of microservices, wherein a respective functionality of each of the plurality of microservices is independently verifiable, wherein each of the plurality of microservices includes a liveness probe; and

responsive to detecting that the first data schema is updated, updating a first liveness probe of the first microservice using the updated first data schema.