4 ms·

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 de

by fuzzy2 2y 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.

Pxtl 2y 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.
- rollcat 2y 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.
  - 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 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.
      - Pxtl 2y 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.

by fuzzy2 2y ago

Pxtl 2y 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.

rollcat 2y 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.
- 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 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.
    - Pxtl 2y 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.