Hacker News new | ask | show | jobs
by fuzzy2 617 days ago
Wow that sounds like the absolute worst. My condolences. In projects I manage I even try not to use containers for the service being developed. (Only for its dependencies.) Everything that affects cycle times must go.

That being said, you should also have a dev environment. QA isn't for development. It'll certainly be cheaper than firing people.
1 comments
Pxtl 617 days ago
Right? I do the DevOps/architect stuff at my org and one game changer for testing was configuring it to spin up a separate instance per pull-request. Occasionally things get wonky because all the PR instances share an authentication/authorization server, but by and large it is excellent for being able to quickly demo.

But it does mean that you have to be religious about building links and connection-strings in your code.

link
rollcat 617 days ago
Once you have 3 environments (which IMHO is the minimum viable number: dev, staging, prod), it tends to be much easier to generalise that to N, at least from the application side (spinning up the extra infra is a separate beast). It tends to weed out many of the "if (prod)"s because there should now be differences between dev & staging that you need to take care of, and sprinkling elaborate switch statements gets tedious really fast - most devs tend to be happier actually simplifying code.

I've seen some really nasty offenders though, e.g. actual business logic hidden behind an "if (window.location.hostname == ...)". Sometimes it takes a lot of patience to explain that this is how you get production-only bugs that QA will never have a chance to find or reproduce.

link
Pxtl 616 days 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.
link
rollcat 615 days ago
You 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.
link
Pxtl 614 days ago
Of 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.

link