My Cambridge Application¶
This page gives an overview of the My Cambridge Application - the undergraduate applicant portal - describing its current status, where and how it's developed and deployed, and who is responsible for maintaining it.
 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.
This service only applies to undergraduate applicants. The Applicant Portal for postgraduates is an unrelated web application.
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.
My Cambridge Application is currently alpha, and has not yet been released as a production service.
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.
My Cambridge Application is currently deployed to the following environments:
|Environment||Deployment Frequency||User Access||Purpose|
|Development||An environment to check any development code changes without affecting end-users.|
|Integration||An environment to test various interfaces and the interactions between integrated components or systems.|
|Test||An environment to evaluate if a component or system satisfies functional requirements.|
|Regression||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.|
|Production||An environment where code changes are tested on live user traffic.|
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|
|User testing||GCP CDN||Firebase||GCP Cloud Run||Cloud Functions||n/a|
|Staging||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.
The source code for My Cambridge Application is spread over the following repositories:
|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|
The following gives an overview of the technologies My Cambridge Application is built on.
|Internal Backend API||Python 3.8||FastAPI|
|WPM Callback API||Python 3.8||FastAPI|
|Data Service API||Python 3.9||FastAPI, PostgreSQL 14|
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¶
README.md files in each of the source code repositories explain how to deploy the Admissions
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|
GCP Cloud Monitoring is used for tracking the health of applications in the environments and sending alert emails when problems are detected.
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
- 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: