The Beacons registration service enables:
- 406Mhz beacon owners to register their details with the Maritime & Coastguard Agency
- Search and rescue Mission Control Centres to retrieve information about beacons during distress signal activations
It comprises three applications:
- A public-facing frontend that uses NextJS and the [GOV.UK Design System]
(https://design-system.service.gov.uk/). Source code is in the
webapp/directory. - An API that uses Spring Boot, Postgres
and OpenSearch. Source code is in the
service/directory. - A backoffice single-page application (SPA) that uses React
to allow users in MCA to query and perform operations on beacon registrations. Source code is in
service/src/main/backoffice. The SPA is served by Spring Boot.
Infrastructure-as-code remains the single source-of-truth for Beacons infrastructure! Always check terraform/ if
unsure.
| dependency | version |
|---|---|
| java | 11.x |
| nvm | 0.38 |
| terraform | 1.0.X |
| Docker desktop | Latest |
$ make # Start up the applications in development mode, with backing servicesThe Terraform directory contains the Terraform code for managing the infrastructure for the Beacons registration service.
Automated testing, building and deployment is performed using GitHub Actions with configuration held in
.github/workflows.
A build and deployment to the development environment is triggered on each push to main. Docker images are tagged
with the hash of the triggering commit and published to AWS Elastic Container Registry. Images built and deployed to
for the development environment are ephemeral and not used anywhere else.
Creating a pre-release triggers a versioned deployment to the staging environment of code at the HEAD of the main
branch. Docker images are tagged with the version tag of the release. Version tags must match the pattern v*.*.
Changing the status of a pre-release to release triggers a deployment to production of the images that were created
for the staging
environment. Environment protection
is applied to the production environment such that another member of the development team is prompted to approve
deployments to production.
Manual scenario testing that must be performed before and after each release is documented in tests/.
We use ADRs to document design choices that address functional and non-functional requirements that are architecturally significant to the Beacons Registration project. Please see this record for how and when to document ADRs for the project.
Secrets are set in the Repository and injected during deployment.
Unless stated otherwise, the codebase is released under the MIT License. This covers both the codebase and any sample code in the documentation.
The documentation is © Crown copyright and available under the terms of the Open Government 3.0 licence.