4 ms·

If iterations take longer than 10s, then I'm really not interested. Typical Docker based CIs are ten minutes to build. Nevermind the deployment. A ridiculous w

by hendry 7y ago

If iterations take longer than 10s, then I'm really not interested. Typical Docker based CIs are ten minutes to build. Nevermind the deployment. A ridiculous waste of time and energy.

techsin101 7y ago
I refuse to do work on docker because of this.
- Myrmornis 7y ago
  If you’re working with python or javascript or something similar, the usual solution is to mount a directory from your host OS as a docker volume, so that you don’t have to rebuild image layers on every change. Isn’t it?
the8472 7y ago
If you have a fleet of services and currently work on services A and B you can just start up A - G in docker-compose based on CI-built images but mount your local build output into the A and B containers. Override their commands to watch filesystem changes so they reload themselves when you build. This can be easily managed with an personal override file on top of a committed compose file used by your team.
- hendry 7y ago
  I agree the local dev environment UX is pretty much there. I use volume mounts myself. But when you're deploying on a remote host. OMG. Just sharing a Docker image internally is anguish. Developing as a remote team using Docker / Kubernetes workflow is just crazy. You're way WAY better off using serverless, where some implementations take ~2s to deploy my Go binary.
  - the8472 7y ago
    This can be hacked together in a similar way. Add a wrapper that watches for filesystem changes to the container command, then add a kubectl cp as last build step locally. Or push an image, set the deployment to pull on start and kill the pod. For sharing docker images, assuming you have write access to some dev repository, you can push to a tag tied to your development branch and others can configure their docker setups to pull that on restart. Dev images can be built faster by just copying build output into an image as last step, that way other steps to prepare the image are cached. No need to use whatever slow things CI is doing in its Dockerfile. It only takes a few lines of shell or makefile to automate most of these things. Of course local dev is still nicer.

by hendry 7y ago

If iterations take longer than 10s, then I'm really not interested. Typical Docker based CIs are ten minutes to build. Nevermind the deployment. A ridiculous waste of time and energy.

techsin101 7y ago

I refuse to do work on docker because of this.

Myrmornis 7y ago
If you’re working with python or javascript or something similar, the usual solution is to mount a directory from your host OS as a docker volume, so that you don’t have to rebuild image layers on every change. Isn’t it?

the8472 7y ago

If you have a fleet of services and currently work on services A and B you can just start up A - G in docker-compose based on CI-built images but mount your local build output into the A and B containers. Override their commands to watch filesystem changes so they reload themselves when you build. This can be easily managed with an personal override file on top of a committed compose file used by your team.

hendry 7y ago
I agree the local dev environment UX is pretty much there. I use volume mounts myself. But when you're deploying on a remote host. OMG. Just sharing a Docker image internally is anguish. Developing as a remote team using Docker / Kubernetes workflow is just crazy. You're way WAY better off using serverless, where some implementations take ~2s to deploy my Go binary.
- the8472 7y ago
  This can be hacked together in a similar way. Add a wrapper that watches for filesystem changes to the container command, then add a kubectl cp as last build step locally. Or push an image, set the deployment to pull on start and kill the pod. For sharing docker images, assuming you have write access to some dev repository, you can push to a tag tied to your development branch and others can configure their docker setups to pull that on restart. Dev images can be built faster by just copying build output into an image as last step, that way other steps to prepare the image are cached. No need to use whatever slow things CI is doing in its Dockerfile. It only takes a few lines of shell or makefile to automate most of these things. Of course local dev is still nicer.