91–94 of 94 posts
Earlier quoted context omitted.
Docker makes it really easy
If only that were true. Source: several years of supporting other developers working with Docker-based local development environments. It certainly helps, but there's still SO MUCH that can go wrong.
Earlier quoted context omitted.
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 c…
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 ted…
Earlier quoted context omitted.
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 ted…
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.
Earlier quoted context omitted.
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.
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.
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.