Merge pull request #35001 from skrthomas/BZ1945073

BZ1945073: Replace DeploymentConfig with Deployment

Author: bergerhoffer

applications/deployments/route-based-deployment-strategies.adoc

@@ -5,7 +5,7 @@ include::modules/common-attributes.adoc[]
 
 toc::[]
 
-Deployment strategies provide a way for the application to evolve. Some strategies use `DeploymentConfig` objects to make changes that are seen by users of all routes that resolve to the application. Other advanced strategies, such as the ones described in this section, use router features in conjunction with DeploymentConfig` objects to impact specific routes.
+Deployment strategies provide a way for the application to evolve. Some strategies use `Deployment` objects to make changes that are seen by users of all routes that resolve to the application. Other advanced strategies, such as the ones described in this section, use router features in conjunction with `Deployment` objects to impact specific routes.
 
 ////
 This link keeps breaking Travis for some reason.

modules/deployments-ab-testing-lb.adoc

@@ -25,7 +25,7 @@ weighting.png[Visualization of Alternate Back Ends in the Web Console]
 
 To set up the A/B environment:
 
-. Create the two applications and give them different names. Each creates a `DeploymentConfig` object. The applications are versions of the same program; one is usually the current production version and the other the proposed new version.
+. Create the two applications and give them different names. Each creates a `Deployment` object. The applications are versions of the same program; one is usually the current production version and the other the proposed new version.
 .. Create the first application. The following example creates an application called `ab-example-a`:
 +
 [source,terminal]
@@ -197,7 +197,7 @@ Not all routers may support multiple or weighted backends.
 ====
 
 [id="deployments-ab-one-service-multi-dc_{context}"]
-== One service, multiple `DeploymentConfig` objects
+== One service, multiple `Deployment` objects
 
 .Procedure
 
@@ -215,7 +215,7 @@ The application is deployed and a service is created. This is the first shard.
 +
 [source,terminal]
 ----
-$ oc expose deploymentconfig ab-example-a --name=ab-example --selector=ab-example\=true
+$ oc expose deployment ab-example-a --name=ab-example --selector=ab-example\=true
 $ oc expose service ab-example
 ----
 
@@ -253,7 +253,7 @@ $ oc scale dc/ab-example-a --replicas=1; oc scale dc/ab-example-b --replicas=0
 +
 Refresh your browser to show `v1` and `shard A` (in blue).
 
-. If you trigger a deployment on either shard, only the pods in that shard are affected. You can trigger a deployment by changing the `SUBTITLE` environment variable in either `DeploymentConfig` object:
+. If you trigger a deployment on either shard, only the pods in that shard are affected. You can trigger a deployment by changing the `SUBTITLE` environment variable in either `Deployment` object:
 +
 [source,terminal]
 ----

modules/deployments-blue-green.adoc

@@ -14,7 +14,7 @@ Consider the data used in testing the new version. If it is the production data,
 [id="deployments-blue-green-setting-up_{context}"]
 == Setting up a blue-green deployment
 
-Blue-green deployments use two `DeploymentConfig` objects. Both are running, and the one in production depends on the service the route specifies, with each `DeploymentConfig` object exposed to a different service.
+Blue-green deployments use two `Deployment` objects. Both are running, and the one in production depends on the service the route specifies, with each `Deployment` object exposed to a different service.
 
 [NOTE]
 ====