Ever been in a situation, where you got into a new project and just setting up the codebase on your local, with all the dependencies, frameworks itself was a real pain. 🤕 Maintaining a Setup Document is so very crucial for every project. What do you guys think ?

Agree that documentation is important. A better way of fixing this would be to use something like https://www.gitpod.io/ or https://github.com/features/codespaces ie your setup will be stored in your git repo as config/code

That's really interesting 😯

Yes, dev setup documents are really necessary as your team scales up. At work, every new hire is expected to fix something or update the setup doc as they're going through it. Prevents the doc from going stale.

The ease of setup is one of the markers of how well a project is architected. If it takes more than a few minutes to spin up the application, then that's a red flag for me from a quality perspective.

Some companies go through a cycle of "hiring" -> "growth" -> "hiring" I usually see this behaviour in such companies. Since there's no continuous inflow, there's little incentive to make and maintain such docs as it's a 1-2 day problem every time a new batch comes in. By the time you'd be hiring another batch, your setup would have shifted anyway so even less incentive to make such changes. The codespaces-ish approach is pretty decent, but it usually doesn't have access to the dev environment in ways that I'd like. So my middleground approach for right now is a dev VM in the dev environment 😇

@dry-monkey-93718 The dreaded VMs 😅 Docker Compose setups would serve as well. What do you think ?

Context: It's just me on the VM, not the entire dev team. I generally use cheap VMs, they often don't have enough juice in them to do the things I am trying to do, adding another layer of docker isn't really worth it for me. If I had to set it up for all devs in the company? I might look at either ansible or some way to make real machine images from dockerfiles.

No point using docker if your workloads aren't containerized so makes sense 👍

The workloads as in the final builds run in containers. They get built in cloud builder after I push to github. Not my dev environment though. I mean I do have docker installed and run it when I need it to. Eg: making changes to the dockerfile / build process and testing it out before pushing. or recently I had to run various versions of different dbs to run an integration test. Docker compose is perfect for that kind of case.