I'd prefer something like Flyway to keep database schema and code in sync. But Docker for sure avoids the hazzle of installing and updating database and middleware. Your build system should pick the correct version of the compiler.
The should be no procedure other than getting the software from the repository , almost.
IMHO, projects should work with default config at least of basic functionality, or crash at start time with a nice error message telling what's missing to add or configure. Docker should not be needed for development environments, at most docker-compose when there are several interrelated components, and always accessing the actual source code from a volume, so it's only used to spin servers up.
I miss a plot twist, like "...until a new teammate joined, and found Docker was either the solution", and later a long post explaining the importance of document everything and have documentation updated and how to test all the onboarding process is updated automatically :-)
I remember working in companies where there were long setup documents. A new joiner would start reading the docs, following the steps, then discovering the steps don't work, then ask around. The docs sometimes got updated, sometimes not. Sometimes also the new joiner made a mistake in following the steps.
All of that could be prevented by automating this process. That's where Docker and other similar tools are very helpful.
Docker as development environment abstract it, for that use case I find it better a setup script that can run everywhere.
Yes, it offers a layer of abstraction over our OS.
Learning your stack is an underrated talent.
What are your recommendations for juniors, regarding learning the tech stack? What would you say are high priority areas of knowledge/skillset there?
I'd prefer something like Flyway to keep database schema and code in sync. But Docker for sure avoids the hazzle of installing and updating database and middleware. Your build system should pick the correct version of the compiler.
The should be no procedure other than getting the software from the repository , almost.
Documents get outdated. Period.
Well said. We should maximize automation (up-to-date) and minimize documentation (out-of-date).
Is it easy for developers who've never used Docker to get used to it?
I think so. It's easier than config all app by hand.
Yes, indeed. Sure, there is a learning curve when using Docker the first time, but afterwards it’s easy.
IMHO, projects should work with default config at least of basic functionality, or crash at start time with a nice error message telling what's missing to add or configure. Docker should not be needed for development environments, at most docker-compose when there are several interrelated components, and always accessing the actual source code from a volume, so it's only used to spin servers up.
“projects should work with default config at least of basic functionality“
Yes.
“Docker should not be needed for development environments“
VJ: But how would you hand the case where the app needs a DB, yet there’s no Docker?
Allow to install the database globally, include a local mock server, or use docker-compose. Docker-compose is nice for these use cases, Docker isn't.
Where do you see Docker as useful?
Only for deployment, that's what it was build for. An in fact, there are better alternatives and more secure like Vagga.
Docker was build by DevOps at NodeJitsu for DevOps in mind, not for developers.
I miss a plot twist, like "...until a new teammate joined, and found Docker was either the solution", and later a long post explaining the importance of document everything and have documentation updated and how to test all the onboarding process is updated automatically :-)
I remember working in companies where there were long setup documents. A new joiner would start reading the docs, following the steps, then discovering the steps don't work, then ask around. The docs sometimes got updated, sometimes not. Sometimes also the new joiner made a mistake in following the steps.
All of that could be prevented by automating this process. That's where Docker and other similar tools are very helpful.
Docker as development environment abstract it, for that use case I find it better a setup script that can run everywhere.