What are suggested Docker "best development practices"?

What are “best development practices” when it comes to application development (not “Docker development”) when the final product is deployed using Docker?

Here’s what I mean…

It is important to distinguish/separate “development” vs. “deployment”. As a developer with many years of experience, I have accustomed to doing all development, testing and troubleshooting locally in my development environment (I use Eclipse IDE), and deploy code to production when it’s ready. In the new team that I joined recently, Docker is used for deploying the product to a server (or multiple servers) - but the team has (“stupid” in my personal opinion) practice that requires all code being tested in a Docker container. In fact, the code itself includes much environment-specific hardcoding (directory/file path locations) specific to container deployment.

With that, it is impossible for me to perform testing and troubleshooting/debugging locally - without having to duplicate deployment environment (which includes using some system directories like /opt). What I have done - is made code changes to replace environment-specific hardcoding with the environment variables (and added those env. variables to Docker configuration file). But… the team (especially - team lead who’d been there the longest) refuses to deploy these changes - and instead INSISTS on all development/testing/debugging to be done directly in a Docker container.

That would be fine - if Eclipse IDE would have provided an easy way to perform debugging/testing of code running in a Docker container (with the “local” code from my project/workspace).

To be more specific, I am not talking of testing the “docker container” (i.e the application running in a container) itself… Here, I am talking about running/debugging individual modules (Perl, Python, JavaScript, whatever…) - using unit test scripts that are not part of a “running container”, but rather are there in the source distribution exclusively for testing. I must be able to (manually) run/debug individual unittest script, step through its execution line-by-line, use breakpoints to evaluate variables at run time, etc. I need to learn how to do that in a Docker environment using Eclipse…

Unfortunately, I have not found how to do that (to have code from my Eclipse project to run in a container, and have Perl or Python debugger attach to that running process and allow stepping-through the code and using breakpoints setup in Eclipse).

So… in my (personal) opinion, it is best to do development/testing/debugging locally, and deploy product using Docker - but not use Docker itself as a primary development/testing environment. In fact, I was able to reproduce deployment environment (other than file system locations) in my local environment, and now I am able to run/test/debug/troubleshoot all code locally - providing that there’s no Docker environment-specific hardcoding. This makes me much more productive, efficient, and allows me to develop higher quality (more reliable) code than others in a team…

To summarize… I think that it is best to perform everything other than deployment and final QA (development, debugging, preliminary testing, troubleshooting) locally - provided that it is possible to duplicate runtime environment.

I am interested to know what Docker development community thinks what “best development practices” are in terms of separation of development/testing/debugging/troubleshooting vs. deployment and execution.

[quote=“vpogrebi, post:1, topic:42936, full:true”]
So… in my (personal) opinion, it is best to do development/testing/debugging locally, and deploy product using Docker - but not use Docker itself as a primary development/testing environment. [/quote]

FWIW, I basically totally agree with this. There are a lot of questions around this forum from people who seem to be successfully using a development setup where their source code gets bind-mounted into a Docker container, though this only helps so much if your language is compiled (Java, C++, modern JavaScript, …). You might see if answered questions here or on SO have some guidance.

One thing I might try, if the source code really has hard-coded paths that can’t be avoided and the runtime container doesn’t have hard-core developer tooling, is to set up a virtual machine that replicates enough of the runtime environment to be useful but also has a full suite of developer tools; Vagrant is a popular tool for building these.