Abstract: According to some implementations, while a proxy routes production traffic to a first application (app) version that runs in a plurality of container orchestration system (cos) pods having first app version containers, configuration information is received including an identification of a second app version container image for a second app version. The second app version is an updated version of the first app version. Cos pods having second app version containers are brought up based on the second app version container image identified in the configuration information. Test and/or warmup traffic is caused to be routed to the second app version containers. Responsive to an indication regarding the routing of the test and/or warmup traffic to the second app version, causing a transition to sending production traffic to the second app version containers instead of to the first app version.

Abstract: According to some implementations, while a proxy routes production traffic to a first application (app) version that runs in a plurality of container orchestration system (cos) pods having first app version containers, configuration information is received including an identification of a second app version container image for a second app version. The second app version is an updated version of the first app version. Cos pods having second app version containers are brought up based on the second app version container image identified in the configuration information. Test and/or warmup traffic is caused to be routed to the second app version containers. Responsive to an indication regarding the routing of the test and/or warmup traffic to the second app version, causing a transition to sending production traffic to the second app version containers instead of to the first app version.

Abstract: According to some implementations, while a proxy routes production traffic to a first application (app) version that runs in a plurality of container orchestration system (cos) pods having first app version containers, configuration information is received including an identification of a second app version container image for a second app version. The second app version is an updated version of the first app version. Cos pods having second app version containers are brought up based on the second app version container image identified in the configuration information. Test and/or warmup traffic is caused to be routed to the second app version containers. Responsive to an indication regarding the routing of the test and/or warmup traffic to the second app version, causing a transition to sending production traffic to the second app version containers instead of to the first app version.

Abstract: Cloud services release orchestration with a reusable deployment pipeline. According to some implementations, responsive to receiving from a COS controller parameters from configuration information provided to the COS controller while an app aware proxy routes production traffic to a first application (app) version that communicates with a database management system (DBMS) and that runs in container orchestration system (COS) pods having first app version containers, causing a validation of a second app version using COS pods having second app version containers that are now live after having been brought up by the COS controller responsive to the provision of the configuration information. After the validation, causing the transition to sending production traffic to the second app version containers that are determined to be live instead of to the first app version containers.

Abstract: Cloud services release orchestration with a reusable deployment pipeline. According to some implementations, responsive to receiving from a COS controller parameters from configuration information provided to the COS controller while an app aware proxy routes production traffic to a first application (app) version that communicates with a database management system (DBMS) and that runs in container orchestration system (COS) pods having first app version containers, causing a validation of a second app version using COS pods having second app version containers that are now live after having been brought up by the COS controller responsive to the provision of the configuration information. After the validation, causing the transition to sending production traffic to the second app version containers that are determined to be live instead of to the first app version containers.

Abstract: Cloud services release orchestration with a reusable deployment pipeline. According to some implementations, responsive to receiving from a COS controller parameters from configuration information provided to the COS controller while an app aware proxy routes production traffic to a first application (app) version that communicates with a database management system (DBMS) and that runs in container orchestration system (COS) pods having first app version containers, causing a validation of a second app version using COS pods having second app version containers that are now live after having been brought up by the COS controller responsive to the provision of the configuration information. After the validation, causing the transition to sending production traffic to the second app version containers that are determined to be live instead of to the first app version containers.

Abstract: A release orchestration mechanism for cloud services. According to some implementations, while an app aware proxy routes production traffic to a first application (app) version that runs in a plurality of container orchestration system (COS) pods having first app version containers, configuration information is received. When a threshold number of the COS pods having the second app version containers are live, a validation of the second app version is caused. Then a transition to sending production traffic to the second app version containers is performed. After causing the transition, timers are started based on a time period indicated in the configuration information and the first app version containers are instructed to gracefully shut down. Based on expiration of the timers, any of the COS pods having the first app version containers that are not yet shut down are forced to shut down.

Abstract: Upon receiving instructions from a release orchestrator to validate a second application version prior to a transition to sending production traffic to the second application version instead of a first application version, a determination of an application version identifier for a second application version is performed. Tests are selected based on the application version identifier and version rules. The tests are performed by sending test traffic to the second application version via a routing engine while the routing engine routes production traffic to the first application version. Based on the responses to the test traffic, a determination that any failure rules for any of the tests that failed indicate that on a failure the transition should not occur is performed. Responsive to that determination, a communication to the release orchestrator that the second application version is not validated for production traffic and the transition should not occur is performed.

Abstract: Cloud services release orchestration with a reusable deployment pipeline. According to some implementations, responsive to receiving from a COS controller parameters from configuration information provided to the COS controller while an app aware proxy routes production traffic to a first application (app) version that communicates with a database management system (DBMS) and that runs in container orchestration system (COS) pods having first app version containers, causing a validation of a second app version using COS pods having second app version containers that are now live after having been brought up by the COS controller responsive to the provision of the configuration information. After the validation, causing the transition to sending production traffic to the second app version containers that are determined to be live instead of to the first app version containers.

Abstract: A release orchestration mechanism for cloud services. According to some implementations, while an app aware proxy routes production traffic to a first application (app) version that runs in a plurality of container orchestration system (COS) pods having first app version containers, configuration information is received. When a threshold number of the COS pods having the second app version containers are live, a validation of the second app version is caused. Then a transition to sending production traffic to the second app version containers is performed. After causing the transition, timers are started based on a time period indicated in the configuration information and the first app version containers are instructed to gracefully shut down. Based on expiration of the timers, any of the COS pods having the first app version containers that are not yet shut down are forced to shut down.

Abstract: A method for performing pre-release, version specific testing to validate application versions is described. Upon receiving instructions from a release orchestrator to validate a second application version prior to a transition to sending production traffic to the second application version instead of a first application version, a determination of an application version identifier for second application version is performed. Tests are selected based on the application version identifier and version rules. The tests are performed by sending test traffic to the second application version via a routing engine while the routing engine routes production traffic to the first application version. Based on the responses to the test traffic, a determination that any failure rules for any of the tests that failed indicate that on a failure the transition should not occur is performed.