2 ms·

A couple large corporations I worked for had two instances of prod, geographically isolated with one acting as a fallback in case the primary went down. This is

A couple large corporations I worked for had two instances of prod, geographically isolated with one acting as a fallback in case the primary went down. This isn't particularly novel at all, but what I was always interested in was using a similar setup for testing production prior to flipping the release live. Effectively you'd just have prod and staging with identical deployment configuration. The benefit would be promoting the exact staging release to prod as soon as tests pass. That said, I've never tried this and I'm sure there are good arguments for avoiding the added complexity of regularly flipping production between two different environments.

hot_gril 2y ago
This sounds like canarying, which is fine
- _heimdall 2y ago
  Are canary releases handled this way? I always thought they were effectively a public staging, with the next prod release generally meaning a rebuild from the same codebase as the canary release rather than a full switch over from one prod environment to the next. Edit: its worth noting that I'm specifically thinking about software along the lines of a hosted service or web application where you could swap it out on hardware you own. Native apps, like the actual web browser, wouldn't fit this model since the binaries live on the client.
  - hot_gril 2y ago
    Usually I've seen it as, you have some system with replicated jobs, and you update the code or config for a few of the jobs and wait before doing the rest. It is sort of a public staging. You can also canary native binaries pushed to clients, which is a different mechanism but the same idea, you're 99...% sure the change is safe but still better not to globally release it. I guess your case isn't the same idea since you're not testing with real usage, it's your own staging tests. But I don't see anything wrong with that.

hot_gril 2y ago

This sounds like canarying, which is fine

_heimdall 2y ago
Are canary releases handled this way? I always thought they were effectively a public staging, with the next prod release generally meaning a rebuild from the same codebase as the canary release rather than a full switch over from one prod environment to the next. Edit: its worth noting that I'm specifically thinking about software along the lines of a hosted service or web application where you could swap it out on hardware you own. Native apps, like the actual web browser, wouldn't fit this model since the binaries live on the client.
- hot_gril 2y ago
  Usually I've seen it as, you have some system with replicated jobs, and you update the code or config for a few of the jobs and wait before doing the rest. It is sort of a public staging. You can also canary native binaries pushed to clients, which is a different mechanism but the same idea, you're 99...% sure the change is safe but still better not to globally release it. I guess your case isn't the same idea since you're not testing with real usage, it's your own staging tests. But I don't see anything wrong with that.