4 ms·
"Corgibytes often introduces new clients to Docker, making it much easier and faster to set up new developer environments." (emphasis mine) She isn't advocatin
by gvb 10y ago
"Corgibytes often introduces new clients to Docker, making it much easier and faster to set up new developer environments." (emphasis mine)
She isn't advocating using Docker for the target environment, she is advocating using Docker to set up a standard development environment that allows the developers to be productive[1] in 10 minutes rather than 10 hours.
I've been in the situation where the development environment is a poorly documented, massively multi-step steaming pile. The result is I spent a lot of time chasing down those responsible for the steaming pile (the "rockstar" in the department) asking them how to get the development environment working. Typically they pull the keyboard away from me, type a bunch, and then say "there, it works." Which it does. For a while.
Rinse and repeat for every developer. Regularly.
[1] Well, at least building the system rather than staring at mysterious very broken error messages.
- marcosdumay 10y agoHum... You are trading an opaque irreproducible environment for another opaque environment that you reproduce by copying verbatim. Technically, it's progress. But I can't imagine how people get satisfied by this.
- Arcsech 10y agoI'm not too experienced with Docker, but aren't Docker images built using Dockerfiles, which are essentially glorified shell scripts? In that case, wouldn't the Dockerfile be a relatively transparent way to see what's needed to reproduce an environment?
- lallysingh 10y agoYes, yes they are. And they're written down where you can read them yourself. And maybe even version controlled!
- GrinningFool 10y agoOn the other hand, tracing back a dockerfile that pulls in an obscure one-off base image, then repeating that all the way up the chain, you can find yourself left with a dozen Dockerfiles that you need to read in the right order to know what you have. That's if you can even find the original Dockerfiles - I recently ran into a situation where a container image was in the registry, but the original Dockerfile was completely lost. Docker/containers in general move the complexity to a different plane, but they only move it - they don't eliminate it. Care needs to be taken to avoid situations just like the one above - or any of a number of other pitfalls - or you end up with an environment that's far more complex to understand than a VM housing a monolithic dev environment.
- pavel_lishin 10y ago> Typically they pull the keyboard away from me, type a bunch, and then say "there, it works." Which it does. For a while. This would happen if they distributed Docker environments, too. Your setup process would be to download a Dockerfile, crank up everything you need, discover it doesn't work, call the Rockstar over, have him or her explain that there's a few manual steps that they haven't yet added to the codebase (or to the wiki), and then you rinse and repeat that process, instead.
- fapjacks 10y agoNo, because once your Dockerfile works, it works fucking everywhere.
- qznc 10y agoOh wait, you need to configure your networking bridge differently ... oh wait, the DNS needs this little tweak ... oh wait, you still use this old version from your distros repo? ... oh wait, you must give it this docker volume ...
- fapjacks 10y agoI can tell you're frustrated from too much yak shaving. But once you become more experienced with systems in general, you'll feel much more comfortable around Docker.
- collyw 10y agoYou have to set up docker first.
- pavel_lishin 10y agoWhich is great if you're the person in charge of distributing it, but if the person in charge keeps giving out the "slightly broken" version, everyone will keep fixing it. Or, and I'm not sure if this is worse, a few people will fix it in slightly different ways, and start distributing those, leading to a weird ecosystem of competing Dockerfiles none of which are quite correct.
- calinet6 10y agoAnd really, the fact that we're caught up on this at all is concerning. It was one small suggestion in a sea of rather intelligent discourse mostly on team environments, structures, and management. Not technology.
- hinkley 10y agoYou know what else happens in that situation? Nobody will volunteer to help you fix an obscure bug that only happens reliably in your version. Because it's too painful for them to shelve their local configuration and grab yours. And once people have that hesitation, 'all hands on deck' emergency fixes become window dressing, because only a few people can actually participate in tracking down and triaging the bug. Everyone else is sitting around waiting to be needed for the two minutes that they can contribute.
- rogerdpack 10y agoIsn't "setting up your environment" pretty much a one time cost, though? In my head at least, losing a couple days up front doesn't matter as much, it's the time after that the needs to be optimized. But maybe that's just my work place where people tend to stay on the same team for years...
- marcosdumay 10y agoShouldn't be. When you automate "setting up your environment", you are able to switch between several of them, create new ones for forks or extra tests, and roll back to debug production issues.
- infinii 10y agoIgnoring the one time aspect. It's the standardization that is important. Docker environments enforce uniformity that are beneficial for testing. No more of the "it works on my machine" excuses. Although the article mentioned development environment specifically, there is recurring benefit in being able to power up a Docker VM for testing purposes.
- collyw 10y agoWhile I agree this sort of thing can be frustrating when starting a new company, I find that it is useful. If i can't get the system working on my dev machine, how can I be expected to debug the production site when there are problems?