Simplify the CI / CD / hosting setup

[slorber]

During the Docusaurus v1 / v2 migration that we have done with @Simek (#2273), I noticed a few things that could be improved regarding the CI / CD / hosting setup.

We didn't do these changes as part of the migration, because:

• We didn't want to disrupt the existing setup, in addition to the already large migration project
• I'm not sure who at Facebook is able to take that decision

As the migration is over, wanted to document some of my findings, and recommend something better.

---

Current setup

We have 3 tools when we could only use one

Netlify

https://app.netlify.com/sites/react-native

The production deployment (https://react-native.netlify.app/) is actually not used.

This is only used for PR deploy previews.
So we basically use a subset of all the Netlify capabilities.

CircleCI

2 workflows:

• tests: do a site build + other minor/fast CI checks.
• publish: to Github Pages

Github Pages

We publish to Github pages.

Surprisingly, this repo does not publish to react-native-website GH pages, but publish to react-native github pages: https://github.com/facebook/react-native/tree/gh-pages

---

Problems

• 3 tools: hard to understand what is going on, and how they all play together
• For each PR commit, both Netlify (as part of deploy previews) and CircleCI (as part of tests workflow) build the site. This is kind of duplicate/useless CI usage
• Burden to manage the permissions on the 3 tools: people rarely have access to the 3, not easy to know who is the admin of a given tool.
• Limited server customization options: GH pages are very limited in what you can do. Not possible to add server-side redirects, set up immutable cache headers for assets that have a hash in filename...
• Risk: GH pages only allow 1 deployment per repo. For large migrations like we did, it would be preferable to be able to have 2 deployments side by side, ensure the new one work, and then perform a simple DNS switch.
• Risk: using a different hosting solution for deploy previews and production. The behavior might be slightly different in subtle ways ( for example, redirecting to trailing slash URLs) and the deploy preview is not anymore a reliable way to validate it will work when in production

---

Suggestion

Just use Netlify for everything (or Vercel or something simple).

I suggest Netlify because:

• there's a Facebook Open-source team on Netlify, using an Entreprise plan
• it's already used on this site, not a new tool
• the archive site deployment use Netlify
• 1 tool = easier to manage permissions (for both prod + archive)
• very simple to setup, for both prod and deploy previews
• simpler than GH pages, does not require git login + commit to a repo
• less risky, due to being able to have multiple production deployments and switch from one to another
• we don't really need CircleCI for tests: deploy previews already perform a site build (we can add a few other additional checks to fail the deploy preview if needed)
• _redirects and _headers file to have server-side options, not available on Github Pages
• Netlify offers more control over trailing slashes

Technical solution

The Netlify production deployment already exist: react-native.netlify.app

We just have to make reactnative.dev target this deployment.

Netlify doc to configure an Apex/naked domain (without subdomain): https://docs.netlify.com/domains-https/custom-domains/configure-external-dns/#configure-an-apex-domain
DNS settings are on CloudFlare, which support CNAME flattening.

So, we don't need to setup any new CI/CD tool. The only thing to do is replace the CNAME entry in CloudFlare:

Once this is done, we can just remove CircleCI and Github pages and manage everything through Netlify

[slorber]

Docusaurus v1->v2 migration: downtime post-mortem

This is funny because I wrote the above issue while the v2 deployment was not totally finished.

I wrote about the risks of GH pages, and the unability to have 2 prod deployments side by side.

Obviously, the inevitable happened. Due to some missing config (absence of website/static/CNAME file to setup GH pages custom domain), the v2 site deployed something bad to GH pages, and the site was down for 30 minutes until we figured how to fix this.

This file used to be generated automatically on Docusaurus v1.
On v2, it's documented, but we missed that, and the problem could only be seen after we actually "override" the prod v1 site.

The fix was easy, but this is another good reason to avoid GH pages in the future, as it adds an additional risk to such migrations.

[slorber]

FYI we migrated the ReactNative website to Netlify 2 days ago:

• @hramos and @JoelMarcey agreed on this
• @Simek reported that CircleCI GH pages deployment was regularly crashing (not happening in Netlify, not sure why)

We now have 2 Netlify sites for RN:

• https://app.netlify.com/sites/react-native/
• https://app.netlify.com/sites/react-native-archive

The old CircleCI / GH Pages setup will be removed by @Simek soon if no problem is reported, alongside the now useless .nojekyll / CNAME files (used by GH pages)