Development workflow using Docker

Question

To remove this from the way, I am not here to discuss the great benefits of using Docker for production. Neither when you are using docker-compose to set up redis and postgres for example when working on an API codebase. However, my question concerns using Docker in a local development workflow.

So the common workflow I have seen for Docker on local development is the following (using a sample ExpressJS in this case)

# Dockerfile
FROM node:16
WORKDIR /usr/src/app

COPY package.json ./
COPY package-lock.json ./
RUN npm install

COPY . .
EXPOSE 3000

# "start:dev": "nodemon --config nodemon.json"
CMD [ "npm", "run", "start:dev" ]

# .dockerignore
.git
node_modules

# docker-compose.yml
version: '3'
services:
  api:
    build: .
    ports:
      - '3000:3000'
    volumes:
      - ./:/usr/src/app

For development purposes, the critical bit is the volumes ./:/usr/src/app mapping my local source folder with the one on the container. This with nodemon allows reloading the application at any code change.

But then what are the benefits? Why not just develop on the local machine as usual and only produce the image for test and deployment purposes?

Docker aims to solve the "It works on my machine" paradigm. But is it true still in a local development environment where you have to modify the code, add dependencies, and so forth? Because in this case, pulling the image is not enough and I would need to install at least npm on my machine to install dependencies.

One argument could be that when using Docker in a local development environment, you can detect potential production issues sooner. I am still not convinced as the volume sync all files on the local machine and container. When adding a dependency on my machine, it is also added on the container but not by npm install , but rather by copy so if you got an OS-dependent dependency, this would bring you issues. You could solve this by only syncing the ./src:/usr/src/app/src folder where the actual code is and not the whole project and rebuilding the image at every dependency or config change.

I find it better to develop without docker as I am not finding any benefits so far, and let Docker be used with the CI/CD workflows to catch the potential issues during testing and deploy to dev/staging/prod servers.

Looking forward to some feedback on this and if using Docker to develop is worth it.

Answer 1

I'll try to go through your questions:

But then what are the benefits? Why not just develop on the local machine as usual and only produce the image for test and deployment purposes?

• One point that you didnt mention is that you will have repeatable development environment for other developers which may use different Operating systems.
• It works on my machine , docker will solve this aswell as you are downloading the dependencies in the container. If you are not then you are not using it correctly. Please note there is no problem with mounting the host directory as you will keep the downloaded dependencies for the next run. (in case of windows, you will download linux dependencies if you are using a linux container). A picture is worth more than a 1000 words:

I find it better to develop without docker as I am not finding any benefits so far, and let Docker be used with the CI/CD workflows to catch the potential issues during testing and deploy to dev/staging/prod servers.

This would work as well. But keep in mind that you need to wait for the CI/CD pipeline to throw the errors, depending how frequent you push, you could develop big chunk just to find out that the dependency that you used doesnt work on the production OS. this could be an easy fix but also depending on the dependency could mean you need to change the code and potentially lose time.