Well, taking as an example the process I've been using:
Generally, custom images (from
Dockerfiles ) are generated to meet the needs of each application service, such as web services, database server and caching server. From these images, each image generating its own container. And the use of docker-composer for orchestration of all services, facilitating the set-up of the whole environment.
For practical purposes, in a development environment, we mirror the application source code through Volumes of Docker into their respective containers, so each developer runs < in> build of images and runs your container, locally, with your version of the project. So theoretically you develop on your machine, but with results being reflected in real time in your container.
Already for the QA environment, production and the like, you can use an image repository (such as DockerHub , or a private DockerRegistry ) where no more we mirror the source code in the container, but we just embed it inside it. The deploy process from there basically becomes a pull , on your server, of the corresponding image.
The great benefit of Docker is the ease of reproducing the same conditions of the production environment on any other machine, but this does not exclude the need for approval environments and this goes through the development process of each project. >