Four environments, same app — how should base URLs be laid out so nobody copies the wrong one?
Example threads. These questions and answers were written by the SDODS team to document real problems and how to fix them. The people named are illustrative, not real users. Questions asked on this site are marked new.
We are moving off a home-grown runner where the base URL was a giant switch statement in a helper. Four targets: a stack we bring up on the laptop, a shared dev box, staging and a read-only production smoke.
What does the idiomatic layout look like here? One file per target, or one file with a map inside it?
A map inside one file would defeat the whole design — -e selects a file, provenance reports per environment, and secrets live in a .env.<env> named after it.
Two things that stopped us hard-coding URLs anywhere else:
Put paths in routes: in the project file rather than in steps, so a scenario says goto(cart) and the environment supplies the origin.
And for the read-only production target, use the per-environment overrides for the things that should differ in anger — timeouts, retries via ci: true, screenshots — instead of forking the project file.
If the same environment answers on more than one origin — a vanity domain and an internal one, say — put the extras in aliases: rather than making a second environment. The recorder rewrites them back to routes, so a flow recorded against the internal host still replays against the public one.