My Cambridge Application¶
This page gives an overview of the My Cambridge Application[1] - the undergraduate applicant portal - describing its current status, where and how it's developed and deployed, and who is responsible for maintaining it.
[1] My Cambridge Application is often internally abbreviated to MyCApp
, and has been
historically been referred to as "Admissions Portal (AP)" or "Cambridge Admissions Portal (CAP)".
You will find references to these names throughout historic documentation and the
codebase.
Note
This service only applies to undergraduate applicants. The Applicant Portal for postgraduates is an unrelated web application.
Service Description¶
My Cambridge Application provides a web application for undergraduate applicants to supply supplementary information as part of their university application, and to track the progress of their university application.
Service Status¶
My Cambridge Application is currently alpha, and has not yet been released as a production service.
Contact¶
Technical queries and support should be directed to the DevOps Hopper team and will be picked up by a member of the team working on the service.
Issues discovered in the service or new feature requests should be opened as GitLab issues here.
Environments¶
My Cambridge Application is currently deployed to the following environments:
Environment details¶
Environment | Deployment Frequency | User Access | Purpose |
---|---|---|---|
Production | End of each sprint | An environment where code changes are tested on live user traffic. | |
Integration | End of each sprint | An environment to test various interfaces and the interactions between integrated components or systems. | |
Regression | On merge to default branch | An environment to test that defects have not been introduced or uncovered in unchanged areas of the software, as a result of the changes made. | |
UAT | An environment to determine if intended users, customers or other authorised entities accept the system. | ||
Test | On merge to default branch | An environment to evaluate if a component or system satisfies functional requirements. | |
Development | On demand via pipeline job | An environment to check any development code changes without affecting end-users. |
Integrations¶
MyCApp env | CamSIS env (applicant feed) | Photo API env |
---|---|---|
Production | https://camsis.cam.ac.uk/intb_prod/ | https://api.apps.cam.ac.uk/photo/ |
Integration | https://camsis.cam.ac.uk/intb_reg/ | https://api.apps.cam.ac.uk/photo-test/ |
UAT | gs://ap-testdata-uat-76f5195d | none |
Regression | gs://ap-testdata-regression-052d7463 | https://api.apps.cam.ac.uk/photo-test/ |
Test | gs://ap-testdata-staging-26edd96d | https://api.apps.cam.ac.uk/photo-test/ |
Development | gs://ap-testdata-development-f1130a5d | none |
The mapping between MyCApp environments the Photo API is defined in ap-deployment/workspace-specific-settings.yml.
ap-backend
receives the applicant feed URL as follows:
-
An EXTRA_SETTINGS_URL points to two environment-specific artefacts:
-
an
apiapp-secret-settings
secret in GCP Secret Manager -
an
apiapp-settings
YAML config file in GCP Cloud Storage -
Both are fetched by
ap-backend
on startup and their contents read to populate the load_settings FastAPI dependable. -
The location of the applicant feed is now available as either
-
load_settings.applicants_source.camsis.url
for a CamSIS feed. load_settings.applicants_source.test_source.url
for a feed mocked by a JSON file.
Google Cloud Platform¶
The GCP console pages for managing the infrastructure of each component of the deployment are:
Name | Public Application Static Assets | Public Application Backend | Internal Portal Backend and Payment Callback API | Frontend Cloud Functions | Data service backend |
---|---|---|---|---|---|
Production | GCP CDN | Firebase | GCP Cloud Run | Cloud Functions | n/a |
Integration | GCP CDN | Firebase | GCP Cloud Run | Cloud Functions | GCP Cloud Run |
Regression | GCP CDN | Firebase | GCP Cloud Run | Cloud Functions | GCP Cloud Run |
UAT | GCP CDN | Firebase | GCP Cloud Run | Cloud Functions | n/a |
Test | GCP CDN | Firebase | GCP Cloud Run | Cloud Functions | GCP Cloud Run |
Development | GCP CDN | Firebase | GCP Cloud Run | Cloud Functions | GCP Cloud Run |
All environments share access to a set of secrets stored in the meta-project Secret Manager.
Source code¶
The source code for My Cambridge Application is spread over the following repositories:
Repository | Description |
---|---|
Portal Frontend | The source code for the application frontend and supporting cloud functions. |
Internal Portal Backend | The source code for the internal backend service and WPM callback API |
Portal Infrastructure Deployment | The Terraform infrastructure code for deploying the portal to GCP |
Data service | The source code for the data service which provides an API on the API Gateway |
Data service Deployment | The Terraform infrastructure code for deploying the data service to GCP |
Technologies used¶
The following gives an overview of the technologies My Cambridge Application is built on.
Category | Language | Framework(s) |
---|---|---|
Frontend | JavaScript | React 17, Gatsby, Firestore |
Cloud Functions | JavaScript | Nodejs 16 |
Internal Backend API | Python 3.8 | FastAPI |
WPM Callback API | Python 3.8 | FastAPI |
Data Service API | Python 3.9 | FastAPI, PostgreSQL 14 |
Operational documentation¶
The following gives an overview of how My Cambridge Application is deployed and maintained.
How and where My Cambridge Application is deployed¶
My Cambridge Application infrastucture is deployed using Terraform, with releases of the frontend and service-to-service backend API deployed by the GitLab CD pipelines associated with the infrastructure deployment repository.
Deploying a new release¶
The README.md
files in each of the source code repositories explain how to deploy the Admissions
Portal.
Deployment schedule¶
All environments are deployed to at sprint end. However, there are some exceptions:
- Development is only deployed to at sprint end, to keep it up to date, if there is no one currently using it for feature testing. This manual feature testing deployments are only done when a larger piece of functionality needs further testing, after manual development before or during a review.
- Staging is deployed to on merge to master.
User access management¶
Environment | User access management |
---|---|
Production | Firebase Auth - Accounts created Live CamSIS feed sync |
Integration | Firebase Auth - Fake CamSIS feed sync into Albatross and MyCApp |
Regression | Firebase Auth - API calls to create and tear down |
User testing | Firebase Auth - Excel spreadsheet sync to Albatross and MyCApp |
Staging | Firebase Auth - JSON file import to Albatross and MyCApp |
Development | Firebase Auth - JSON file import to Albatross and MyCApp |
Monitoring¶
GCP Cloud Monitoring is used for tracking the health of applications in the environments and sending alert emails when problems are detected.
Debugging¶
TBD
Displaying service alert messages¶
My Cambridge Application supports the display of service alert messages, to target one or more pages and/or user groups with information relevant to any ongoing live service issues.
For more information on how to configure these alerts, see
alerts
in the ap-frontend
repository.
Specifications¶
- Admissions Portal: High-Level Specification
- Admissions Portal: Backend Specification
- Admissions Portal: Frontend Specification
- Digital Admissions Project Index
Service Management and tech lead¶
The service owner for My Cambridge Application is TBD.
The service manager for My Cambridge Application is TBD.
The tech lead for My Cambridge Application is Brent Stewart.
The following engineers have operational experience with My Cambridge Application and are able to respond to support requests or incidents: