[stdbrouw]

Because "running things just fine" across production, continuous integration and on dev machines is actually quite a hard thing to do.

But then, if you don't feel like you need it, that's probably because you don't need it.

(If people are downvoting your question, it's probably because you're giving off a bit of a "I don't understand Docker so it must be crap" vibe, which is not helpful.)

[scurvy]

OK, now we're getting somewhere. What is difficult about getting things right across production and CI? What are the pain points? What are the exact problems we're being asked to solve here? I don't think dev environments need to be harmonized the same as production. If your tests are good, you should catch most of the "it worked on my laptop" problems.

Sorry if my initial question came across with a weird vibe. I'm generally curious. I have colleagues working at places and they actually are being asked to drop everything and implement Docker. I asked why and what's driving this and got the predictable response of "management/dev/someone wants something new".

[zaphar]

Most "it worked on my laptop" problems get caught somewhere between commit and push to production. What docker helps with is catching them "early" rather than "later". Because a failed push emergency push with reason "Doesn't work in production environment" as a reason is a really stressful way to work.

Catching it before pushing your changes is far more preferable.

There are a lot of different methods and processes to fix this. Docker is a new one that simplifies a number of the pieces of the puzzle by constraining the environment is useful ways.

However, if you already have a process worked out and aren't experiencing pain then you probably don't need to switch for the sake of switching.

[riquito]

> I don't think dev environments need to be harmonized the same as production. If your tests are good, you should catch most of the "it worked on my laptop" problems.

That's true until something break in production: then you want to replicate the same situation in the dev environment, as close as possible.

[danesparza]

Please take note of the companies that are using docker.

Docker isn't magical, but the process that it lends itself to can be very useful. Those companies aren't using docker to be successful. They are successful because of the processes (and intensity) that docker fits into.

I'm sorry that your colleagues are being asked to drop everything and look at anything (much less Docker). That's not a nice way to work -- and I'm sure it influences their notions of Docker.