Development process with Docker

Question

I understand the basic concept of Docker and its advantages but I doubt how it is used in the development process, these doubts are:

• Technically Docker generates "machine snapshot" so all developers must pull from the same hub to not have difference in the correct container?
• This container is on every team developer’s machine or on an external server?
• I code on my machine and "deploy" on the container only after development?
• The type-approval environment continues to be used after the Docker?

Answer 1

One answer at a time:

Technically Docker generates "snapshot of the machine" so all developers must pull from the same hub to have no difference in the correct container?

Exactly. That machine snapshot which is called container. In it container has all necessary environment to run your service.

This container is on every team developer’s machine or on an external server?

This varies greatly in each team’s workflow. The container is usually the final product of the development process, in the sense that it has all the capacity of run the service with only one command, and it is he who also goes into production.

I code on my machine and "deploy" to the container only after development?

Yes, what you’re looking for is the Automated Builds, which is a resource of Dockerhub which allows you to align a Github repository with a container, making a process very similar to that of continuous integration, with each commit Dockerhub will try to make a Docker build, with the Dockerfile present in the repository root.

The type-approval environment continues to be used after the Docker?

One of the advantages of Docker is that it can run the approval environment on your machine, or easily recover it if something goes wrong. But this does not rule out the need to have an approval environment, it is always important to test and validate the services and if the containers are running accordingly.

Your doubt is clearly not from Docker, but from Devops. It also encompasses Docker and other concepts that make use of Docker, such as Continuous Integration and Continuous Delivery.

The Devops has allowed to have an automated and more agile delivery process. I recommend taking a look at this concept, as it encompasses the use of Docker in production. Some interesting links:

• Whitepaper Docker and The Three Ways of Devops
• Devops Wiki

Answer 2

Based on my experience with Docker:

• Whether or not to use Docker in the Development process depends on the established process. For example, in my process I have a base_container containing all the dependencies of a Project (such as ruby + Sinatra). From there I have 2 processes, one as my dev environment and another of builds (for Homologation or Production). In the dev environment I use base_container and mount the volumes with project code. In the process build CI use to generate the final containers and from them game in Production.

• Containers are usually stored on servers: Docker Registry for Internal Server or Dockerhub contracted as a service.

• Yes, ideally do it in different processes. as in the answer 1 example. Usually a Dev container is polluted with manual installations, test files, randomly modified configuration files, things like ... But nothing prevents you from generating tags from a developer machine, it depends on the established process.

• The Homologation environment is important if you need to consolidate the delivery of various projects, codes, containers .. or when you have a large team of developers and you need to group all the changes before you take them to a production environment. Particularly I would start observing Continuous Delivery and Bluegreen Deployment so that it is possible to shorten the time between commits and deploys in production.

I hope I’ve helped.

Answer 3

Well, taking as an example the process I’ve been using:

Usually custom images are generated (from Dockerfiles) to meet the needs of each application service, such as web services, database server and caching server, from these images, each generating its own container. And the use of Docker-Composer for orchestrating all services, facilitating the set-up of the whole environment.

For practical purposes, in a development environment, mirrored the source code of the application through Volumes of Docker within their respective containers, so each developer runs the build of the 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.

For the QA environment, production and the like, the use of an image repository (such as Dockerhub, or a Dockerregistry private) where we no longer mirror the source code in the container, but only embed it within it. The deployment process from there becomes basically a pull, on your server, from 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 from the development process of each project.