// Module included in the following assemblies:
//
// * applications/deployments/what-deployments-are.adoc

:_mod-docs-content-type: CONCEPT
[id="deployments-and-deploymentconfigs_{context}"]
= DeploymentConfig objects

include::snippets/deployment-config-deprecated.adoc[]

Building on replication controllers, {product-title} adds expanded support for the software development and deployment lifecycle with the concept of `DeploymentConfig` objects. In the simplest case, a `DeploymentConfig` object creates a new replication controller and lets it start up pods.

However, {product-title} deployments from `DeploymentConfig` objects also provide the ability to transition from an existing deployment of an image to a new one and also define hooks to be run before or after creating the replication controller.

The `DeploymentConfig` deployment system provides the following capabilities:

* A `DeploymentConfig` object, which is a template for running applications.
* Triggers that drive automated deployments in response to events.
* User-customizable deployment strategies to transition from the previous version to the new version. A strategy runs inside a pod commonly referred as the deployment process.
* A set of hooks (lifecycle hooks) for executing custom behavior in different points during the lifecycle of a deployment.
* Versioning of your application to support rollbacks either manually or automatically in case of deployment failure.
* Manual replication scaling and autoscaling.

When you create a `DeploymentConfig` object, a replication controller is created representing the `DeploymentConfig` object's pod template. If the deployment changes, a new replication controller is created with the latest pod template, and a deployment process runs to scale down the old replication controller and scale up the new one.

Instances of your application are automatically added and removed from both service load balancers and routers as they are created. As long as your application supports graceful shutdown when it receives the `TERM` signal, you can ensure that running user connections are given a chance to complete normally.

The {product-title} `DeploymentConfig` object defines the following details:

. The elements of a `ReplicationController` definition.
. Triggers for creating a new deployment automatically.
. The strategy for transitioning between deployments.
. Lifecycle hooks.

Each time a deployment is triggered, whether manually or automatically, a deployer pod manages the deployment (including scaling down the old
replication controller, scaling up the new one, and running hooks). The deployment pod remains for an indefinite amount of time after it completes the deployment to retain its logs of the deployment. When a deployment is superseded by another, the previous replication controller is retained to enable easy rollback if needed.

.Example `DeploymentConfig` definition
[source,yaml]
----
apiVersion: apps.openshift.io/v1
kind: DeploymentConfig
metadata:
  name: frontend
spec:
  replicas: 5
  selector:
    name: frontend
  template: { ... }
  triggers:
  - type: ConfigChange <1>
  - imageChangeParams:
      automatic: true
      containerNames:
      - helloworld
      from:
        kind: ImageStreamTag
        name: hello-openshift:latest
    type: ImageChange  <2>
  strategy:
    type: Rolling      <3>
----
<1> A configuration change trigger results in a new replication controller whenever changes are detected in the pod template of the deployment configuration.
<2> An image change trigger causes a new deployment to be created each time a new version of the backing image is available in the named image stream.
<3> The default `Rolling` strategy makes a downtime-free transition between deployments.
