9 ms·

The real problem for parallel dev is ensuring parallel dev environments can seamlessly co-exist without treading on each other. As soon as one of them wants to

by zmmmmm 24d ago

The real problem for parallel dev is ensuring parallel dev environments can seamlessly co-exist without treading on each other. As soon as one of them wants to open a port, talk to an external database or write to a shared location as part of testing you have them conflicting with each other. Much of this is a legacy dev issue where there was never so much of an assumption that parallel ephemeral dev environments would be in play in the first place. But legacy dev is still most of dev.

lefra 24d ago
To avoid that, the code should have ways to override default ports or paths for testing. Then, when testing, ask the OS for a free port or temporary file, and tell the tested code to use that instead of its default. This also allows running tests concurrently. In what case would talking to an external DB be a problem? Databases support parallel queries.
- pprotas 24d ago
  On your last point, imagine worktree A talks to a database assuming some specific schema. If worktree B changes the schema (let’s day, we remove a column from a table), then worktree A can run into some errors.
  - bdangubic 24d ago
    all schema changes should always be addition only
    - pprotas 24d ago
      Maybe ideally, sure. In practice, in an org with multiple engineering teams: good luck enforcing that rule!
      - bdangubic 23d ago
        no database user has drop rights - very easily enforced
mock-possum 24d ago
I just have a handful of ‘hot desks’ I assign different agents to - each desk is numbered, and the numbers inform the ports. So my first agent (001, because it’s an agent after all) uses 8081 for the web server, 3001 for the database, 8001 for the api service, etc - and 002 would use —2 for all the same. Nice and neat, nobody’s toes get stepped on.
SimionBaws 23d ago
Easy: each worktree starts services on new ports. https://termic.dev https://termic.dev goves you ENV variables for this, oir you definee your own custom named variables, and termic assigns ports for each wotktree. Or if the stack is too complex to start it in parallel, use spotlight to sync changes to main checkout from a single worktree at a time. You can only test one at a time, let's be serios. https://termic.dev/docs/spotlight/ https://termic.dev/docs/spotlight/
quesobob 21d ago
[dead]

by zmmmmm 24d ago

lefra 24d ago

To avoid that, the code should have ways to override default ports or paths for testing. Then, when testing, ask the OS for a free port or temporary file, and tell the tested code to use that instead of its default. This also allows running tests concurrently. In what case would talking to an external DB be a problem? Databases support parallel queries.

pprotas 24d ago
On your last point, imagine worktree A talks to a database assuming some specific schema. If worktree B changes the schema (let’s day, we remove a column from a table), then worktree A can run into some errors.
- bdangubic 24d ago
  all schema changes should always be addition only
  - pprotas 24d ago
    Maybe ideally, sure. In practice, in an org with multiple engineering teams: good luck enforcing that rule!
    - bdangubic 23d ago
      no database user has drop rights - very easily enforced

mock-possum 24d ago

I just have a handful of ‘hot desks’ I assign different agents to - each desk is numbered, and the numbers inform the ports. So my first agent (001, because it’s an agent after all) uses 8081 for the web server, 3001 for the database, 8001 for the api service, etc - and 002 would use —2 for all the same. Nice and neat, nobody’s toes get stepped on.

SimionBaws 23d ago

Easy: each worktree starts services on new ports. https://termic.dev https://termic.dev goves you ENV variables for this, oir you definee your own custom named variables, and termic assigns ports for each wotktree. Or if the stack is too complex to start it in parallel, use spotlight to sync changes to main checkout from a single worktree at a time. You can only test one at a time, let's be serios. https://termic.dev/docs/spotlight/ https://termic.dev/docs/spotlight/

quesobob 21d ago

[dead]