Set up staging deploy

[waxlamp]

trafficstars

Originally posted by @subdavis in https://github.com/Kitware/dive/issues/274#issuecomment-673468590:

I've been thinking about this some more, Jake, and I think you're right that we need Netlify deploy previews, but I don't think that's the whole issue.

Feature velocity / acceptance criteria

If we had retrospectives, I'd bring this up then. But I've noticed that our workflow may be a little flawed around the done/archived step. Matt is serving as our product owner, so he alone should get to decide whether or not a ticket has been done properly. Our deploys lag master, so he isn't able to do this, which means he has been rubber-stamping stuff then coming back a week or two later with follow-on issues that really should have blocked the ticket from being closed.

In other words, I think our feature velocity may be a bit too high and acceptance criteria too lose at the moment, which is causing QA-type issues that are impacting production and customers.

Staging env

If we had a full staging environment with automated deployments, and netlify previews pointed at staging instead of prod, I think our workflow hiccups would be solved. Matt could immediately look at a feature and decide whether it passes or fails the acceptance criteria.

I don't think we need another server for this. We could run the staging environment alongside prod for now. I recognize that isn't a best practice, but I don't think we have enough user traffic to justify multiple servers. Even something dumb like putting staging on a different port would be fine with me.

Then, our netlify previews could be pointed at the staging instance and if we break stuff, it doesn't matter.

Thoughts?

[subdavis]

See my comment on #274 I was wrong about staging. Unless another machine becomes available, I don't think we can do this.

[waxlamp]

Let's discuss the ROI on actually doing this, and if it's sufficiently high we can engage with sysadmin for a second machine.