Renaming an MFE (microfrontend) in production

This is a brief write-up of my experience changing the title, hostname, and repository name of an MFE that was deployed to production. It is not a thoughtful or fleshed-out guide. Depending on your situation, this may or may be helpful to you.

Context

In the Master’s & MicroMaster’s squad, we have an MFE called Program Console. Partners use it to manage enrollments in Master’s degrees and download learner reports for a few different types of programs.

It was originally called Program Manager. We realized after deploying that MFE to partners that the name was confusing. Partners interface with edX staff members called “Program Managers”, so when we would say things to partners like “to find that out, go to the program manager,” there was definitely some ambiguity.

We decided to rename the MFE to Program Console. However, we wanted the old link (https://program-manager.edx.org) to seamlessly redirect to the new link (https://program-console.edx.org) so that existing users who had bookmarked the old URL did not see 404s.

Unlike other MFEs, we had the flexibility that short bouts of downtime were tolerable. At the time, there were literally only a dozen or so users. While it was very important that the MFE never did an incorrect thing, it was not critical that it was available for more than 99.9% of the time.

Changing the title, heading, and repository name

We knew that changing the URL of the MFE was going to require the most learning, so we started with the stuff we knew how to do.

Changing the title and primary heading

Nothing surprising here; just updating text.

https://github.com/edx/frontend-app-program-console/pull/26

Changing the repository name

Any administrator of the MFE’s repo can go to “Settings” and change the name of the repository. This is actually very safe to do any can be done first, as GitHub will seamlessly redirect from the old repository name to the new repository name indefinitely.

For good measure, we still updated the references of program-manager to program-console in the repository and renamed the NPM package:

https://github.com/edx/frontend-app-program-console/pull/27

Changing the repository URL and service names in devstack

With these two PRs (which can be done in a single PR), we updated devstack to reference the new repository URL (for good measure, not out of necessity) and changed the name of the service from program-manager to program-console.

https://github.com/edx/devstack/pull/498

Those PRs do change the folder in which docker-compose looks for code on the host computer from ../frontend-app-program-manager/ to ../frontend-app-program-console/. Because of this, we needed to let Devstack users that, in order to use Program Console on Devstack, they would either need to rename the folder or delete it re-clone the repository. @Alex Wang (Deactivated) sent out an email for this:

tl;dr - If you expect program manager to keep working in devstack, please remove your local “frontend-app-program-manager” project folder if you have it, and git clone git@github.com:edx/frontend-app-program-console.git

Longer:

Hi folks, 

We have renamed the repository “frontend-app-program-manager” to “frontend-app-program-console”, relevant changes have also been made to devstack accordingly:

[PR links]

 From now on, if you want to work with program manager (which is now known as program console), then make sure to remove your local “frontend-app-program-manager” project folder if you have it, and git clone git@github.com:edx/frontend-app-program-console.git

 Also, relevant commands in devstack have been changed. For example:

* `make dev.up.program-manager` becomes `make dev.up.program-console`

* `make program-manager-shell` becomes `make program-console-shell`

* ...and so on

Cheers,

Alex


Discovery: Changing the URL

In my mind, I wanted the URL change to go something like this:

  1. Introduce the new program-console.edx.org URL, but do not redirect program-manager.edx.org to it yet.

  2. Verify that program-console.edx.org works correctly.

  3. Then, redirect program-manager.edx.org to program-console.edx.org.

I filed a DevOps Support ticket and went to DevOps office hours. They explained that I should essentially create a whole new MFE in Terraform (our AWS configuration) and create a new deployment pipeline in it for Gomatic (our GoCD setup) for step 1. They would both pull code from the repository.

Then, for step 3, I would update the program-manager S3 bucket config in Terraform to redirect to the program-console bucket, and then finally remove the program-manager GoCD pipeline.

Adding new Program Console MFE

Add configuration for program-console

Add new GoCD pipeline for program-console

This also required asking DevOps for access to the new pipeline.

Create program-console microfrontend in S3

I also decided to go ahead and make program-manager.stage.edx.org redirect to program-console.stage.edx.org in the PR in order to make sure that the next step would work as expected. This required having DevOps clear the Stage program-manager bucket before applying the Terraform.

In applying this, we hit an unexpected snag related to us hitting a limit of Cloudflare worker scripts we can deploy. In the same PR, Joe Mulloy did some refactoring to make it so all MFEs shared the same Cloudflare worker script, resolving the problem. If you’re reading this because you want to rename an MFE, you don’t need to worry about this.

I then hit an issue where our program-manager GoCD pipeline was broken, because its Stage bucket was now a read-only bucket that redirected to program-console. I resolved this by making that bucket writable again.

Making Program Manager redirect to Program Console

Make prod program-manager bucket redirect to program-console

Note that this requires the program-manager S3 bucket being cleared before applying the Terraform changes. Your MFE will be down in the time period between the bucket-wipe and the Terraform-apply. Coordinate with DevOps for this.

If your MFE can’t tolerate ~60 seconds of downtime, then this may not be the right approach.

Removing the old program-manager pipeline

Remove program-manager config