A deployment strategy is a method of updating or changing an application. The goal is to implement the modification with little downtime so that the USER doesn't notice any improvements.

A blue-GREEN deployment is the most typical strategy. Users continue to utilise the stable version while the new version (the blue version) is tested and evaluated (the green version). Users are converted to the blue version when they are ready. You can revert to the green version if a problem arises. An alternate technique is to employ A/B versions that are both live at the same time, with some users using one and others using the other. This can be used to collect customer feedback on modifications to the user interface and other FEATURES. It can also be used to check good operation in a production setting if only a small number of users are affected.

Canary deployment is used to test the new version, but if a fault is discovered, it rapidly reverts to the previous version. Both of the aforementioned tactics can be used to accomplish this. The count of PODS in the facilities is not scaled by route-based deployment options. The deployment configurations might have to be scaled to maintain acceptable performance characteristics.

Because the end-user typically gets the application via a router-managed route, the deployment strategy can concentrate on DeploymentConfig object or routing characteristics. All routes that use the application are affected by deployment strategies. Individual routes are targeted via strategies that leverage router features.

The DeploymentConfig object supports many deployment strategies, and some extra strategies are provided by router features. When deciding on a deployment strategy, keep the following in mind:

Long-term connections must be managed with care.
Database conversions are time-consuming and must be done in tandem with the application.
Downtime may be necessary to complete the transition if the application is a hybrid of microservices and traditional components.
To do this, you'll need the necessary infrastructure.
You can break both new and old versions in a non-isolated test environment.

A readiness check is used in a deployment strategy to see if a new pod is ready to use. The DeploymentConfig object retries to run the pod until it TIMES out if a readiness check fails. TimeoutSeconds in dc.spec.strategy.*params sets the default timeout to 10m.