An image contains the code used to create a deployment. Then, a deployment can be created from an image, which should then create a replica set (which is the number of pods that should be created), and then the pods should be created.
If you are not familiar with the oc command, refer to OpenShift - Getting Started with the oc command.
When deploying an application using the oc new-app command, if the --as-deployment-config flag is not used, the application will be created as a deployment, not a deployment config. In this scenario, you would need to delete the current deployment and the deploy the application again from the latest image. On the other hand, if the --as-deployment-config flag is used to deploy the application, the oc rollout command can be used to update the deployment from the latest image.
The oc get deploymentconfigs command can be used to list the deployments in a project / namespace. Notice in this example that TRIGGER BY has latest. This means that when the latest image is updated, the deployment can be updated to use the new latest image.
~]$ oc get deploymentconfigs NAME REVISION DESIRED CURRENT TRIGGERED BY my-app 1 1 1 config,image(my-app:latest)
The oc rollout latest command can be used to update the deployment to the latest image.
~]$ oc rollout latest deploymentconfig/my-app deploymentconfig.apps.openshift.io/my-app rolled out
And then the oc rollout history command can be used to see that the latet image was rolled out. In this example, revision 1 is the original deployment and revision 2 is the roll out.
~]# oc rollout history deploymentconfig/my-app deploymentconfig.apps.openshift.io/my-app REVISION STATUS CAUSE 1 Complete config change 2 Complete manual change
If some problem occurs with the new deployment, the oc rollout undo command can be used to go back to a prior revision.
~]# oc rollout undo --to-revision 1 deploymentconfig/my-app deploymentconfig.apps.openshift.io/my-app rolled back