-
-
Notifications
You must be signed in to change notification settings - Fork 359
Use docker-compose for setting up the development flow #77
Comments
It's easy to think that docker is a good choice for self hosted instances. We can discuss the Pros and Cons from a more technical POV. Any other altenatives? |
I agree with this. I use docker-compose for most of my dev environments (with hot reloading) and it's just a smoother dev experience. Downsides from a dev experience POV might be longer loading times when docker images have to be built / memory consumption (for those of us with limited disk space) |
+1 for docker-compose for local dev. Can use volume mounts to hot-reload etc., and gets us closer to dev-prod parity. If folks have resource constraints to the point that they can't use Docker, they can look inside the Dockerfile to replicate the environment. |
I've never used docker-compose during development time, mostly used for building images and testings builds before committing. When we talk about using docker-compose, so we mean that there is some web-server running that has the local directory mapped to a volume, and setting up some hot-reload feature within that container? |
Using docker for development in an open source project such as this one ensures that everyone's environment is as close to being the same as possible, reducing the number of OS-specific quirkiness that can arise otherwise. This gets a 👍 from me |
This sounds like a really good idea. docker-compose during development reduces setup time and enables contributors to get up to speed quickly and like @iansltx said, those with resource constraints can easily replicate the environment by looking at the docker-compose file. |
Same for me. Could someone clarify what capacity it is being proposed for |
To add, we can use docker to standardize node app + postgres setup so contributors can just run a docker-compose command to set up a local postgres db. I'll make a PR for this as well if #78 is merged |
I completely agree with @timmyichen 's last comment. As soon as chapter is going to include a DB and a backend + frontend, it's going to be much easier to run all the parts together. You don't need to set up any system dependency as it's going to be managed by docker, thus making the development much easier and more consistent across developers. Also if you want to delete or upgrade the system everything is going to be in a single place, making the process easier. The only price is a bit of learning (less than setting up all the services manually) and having the docker server running, but that's easier to shut down when not neeeded. Plus the deployment is going to be in a much more similar environment than development, minimising the differences between dev and prod environments. I'm all in for working more having a |
I quite agree with the idea of using docker to ensure consistency between our codes. That way it'll be feasible to run similar instances of the app on individual machines irrespective of the OS |
I agree with @mikeattara it will be a good idea to use docker in Dev environment. In my current project i am using docker-compose with hot reloading. Trust me using docker we can make development/setup process very fast and hassle free. |
Closed by 93f6aad. |
I am opening this issue for us to discuss the possibility of using docker-compose for the development of this project. This I think will make onboarding easier.
The text was updated successfully, but these errors were encountered: