2 ms·
For us the challenge was our DNS wasn't set up to spin up unlimited subdomains, so we had to run applications on dev.companyname.tld/application_prInstanceID/,
by Pxtl 2y ago
For us the challenge was our DNS wasn't set up to spin up unlimited subdomains, so we had to run applications on dev.companyname.tld/application_prInstanceID/, so that was the case where we had to make application-level changes to support N instances, since some code assumed they would have their own private sub-domain-name.
- rollcat 2y agoYou really should have a completely separate domain for all the internal/dev stuff tho, e.g. example.com vs example.net. Even if things like cookies, TLS, control over the DNS zone, etc weren't all involved, it's just hygiene.
- Pxtl 2y agoOf course, I just mean if you've got one internal.productname.com or .local or whatever, the problem is not having one domain for each branch. Like, the public product is www.productname.com, and the internal site is dev.productname.local, right? But since we set up one instance for each active PR, you have to host the sites at dev.productname.local/PR11235 and dev/productname.local/PR12345 if you don't have the infrastructure set up to spin them up as pr11235.dev.productname.local and pr12345.dev.productname.local That was the challenge with "one instance per active PR" we hit. Very handy for both automated and manual testing, but took some work to get the product site to run at arbitrary URLs instead of assuming it had a domain all to itself.