Skip to main content

Source Code Management

PR process for MFEs​

A pull request is a useful forum for discussing a new proposed feature. Once a given feature branch is ready, a developer can raise a pull request through their GitHub account.

Once it is public, anyone involved have evrything they need to review the code and merge it in the the main branch.

This is a great opportunity to discuss, take onboard and apply feedback that may be useful for the given repository as well as the users and owners of the repository.

In an organisation like Hackney Council, this workflow can work particularly well if teams

  • deploy their applications independently as microfrontends
  • have teams dedicated for each microfrontnend
  • are autonomous and have specialised busines domain needs and expertise

The list above is something to strive towards for the organisation as well as teams and individual contributors. In the context of Microfrontends at Hackney Council, we can break the PR process can be broken down into two main parts.

Initial commit​

Just to emphasise, a new MFE will require it's own repository which can be created on GitHub. Currently we are using public repositories. Once a repository is up and running, the creator of the MFE will be able to push the initial scaffolding of the MFE application straight into the main branch.

At this point, they are one of the owners and contributors of this repository. As other's (people from the same or other programmes / streams) join in build new features, the original person will likely play a role in the approval stage.

Applying changes to an existing MFE​

Once a developer has created a feature branch, other contributors and/or owners will need to be involved in the approval process to ensure the MFE is still working as per their needs and expectations. The contributors and owners may or may not be working in different teams, hence they may share the same visibility at all times.