Check vNext redirects prior to publishing a minor release

[pepopowitz]

We should implement a workflow that compares the sitemap as it would exist in vNext against the htaccess rules, to identify redirect rules that will be necessary when we cut the next version.

We currently have a practice of writing vNext rules into our htaccess file, even though they aren't validated, when we make content moves. It would be nice to have some validation of these rules instead of relying on an unchecked social contract.

Background

During #3250, we spent a lot of time on release-cutting day chasing down redirects in the new version. This happened because significant content moves were merged after practicing a release cutting, but before cutting the actual release, and therefore there were many redirects to track down during the cutting process.

It's not wrong for us to introduce significant content moves at any time. The issue here is that we don't have any way to actually test the vNext content against the htaccess rules. If we did, we could resolve most redirect issues prior to release, and closer to the time that we're making the content moves.

Implementation notes

• I don't think we should implement this as a blocking check on a PR. It is useful information during a PR, but it shouldn't prevent work from being merged, as it doesn't have to be resolved until the next minor release is cut. The risk is that we will potentially keep kicking the can down the road and never deal with the redirects until release cutting time anyway, but that is not much different than what we're doing right now.
• We could do this as a cron-based workflow that DX pays attention to and attempts to resolve sporadically.
• We could also implement it as a non-blocking workflow attached to PRs. This might introduce confusing noise that PR authors don't care about.
• Does it make sense to create separate htaccess rules per version as part of this work? That would allow us to (a) organize redirects by version affected, and (b) isolate the htaccess rules that need to be tested against vNext. On the downside, we often group rules that affect the same page across multiple versions, and this would introduce friction to that tactic.
• I think the logic for validating would look something like this:
  • Capture the sitemap.xml from production
  • Inject /next/ into all URLs in the sitemap
  • Run link-checking against the sitemap & running site