Re:Tracking developer build times to decide if the M3 MacBoo...
by __jem on Friday December 29, 2023 @07:36PM
(#38811829)
Isn't the point of a dev environment precisely that the intern can drop tables? Idk, I've never had a shared database not turn to mush over a long enough period, and think investing the effort to build data scripts to rebuild dev dbs from scratch has always been the right call.
Re:Tracking developer build times to decide if the M3 MacBoo...
by makeitdouble on Friday December 29, 2023 @07:52PM
(#38811899)
Dropping tables to see what happens or resetting DBs every hour is fine with a small dataset, but it becomes impractical when you work on a monolith that talks to a set of DB with a hundred+ tables in total and takes 5 hours to restore.
As you point out rebuilding small test datasets instead of just filtering the prod DB is an option, but those also need maintenance, and take a hell of time to make sure all the relevant cases are covered.
Basically, trying to flee from the bulk and complexity tends to bring a different set of hurdles and missing parts that have to be paid in time, maintenance and bugs only discovered in prod.
PS: the test DB is still reset everyday. Eorse thing happening is we need to do something else for a few hours until it's restored.
Re:Tracking developer build times to decide if the M3 MacBoo...
by arthens on Saturday December 30, 2023 @04:50AM
(#38813982)
> We have interns coming in and fully ready within an hour or two of setup. Same way changing local machines is a breeze with very little downtime.
This sounds like the result of a company investing in tooling, rather than something specific to a remote dev env. Our local dev env takes 3 commands and less than 3 hours to go from a new laptop to a fully working dev env.
We have interns coming in and fully ready within an hour or two of setup. Same way changing local machines is a breeze with very little downtime.