My Cambridge Application

[Team | Digital Admissions Team] [Tech Lead | bs461] [Service Owner | hr244] [Service Manager | kb851] [Product Manager | bmd42]

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:

Name	Usage	Public Application URL	Data Service API URL	Payment Callback API URL
Production	Live service	https://apply.undergraduate.study.cam.ac.uk	https://api.apps.cam.ac.uk/undergraduate-admissions/v1alpha1	https://wpmapp.prod.ap.gcp.uis.cam.ac.uk/
Integration	End-to-end testing getting as close to production-like as possible	https://webapp.int.ap.gcp.uis.cam.ac.uk	https://api.apps.cam.ac.uk/undergraduate-admissions-int/v1alpha1/	https://wpmapp.int.ap.gcp.uis.cam.ac.uk/
Regression	Automated testing	https://webapp.reg.ap.gcp.uis.cam.ac.uk	https://api.apps.cam.ac.uk/undergraduate-admissions-reg/v1alpha1/	https://wpmapp.reg.ap.gcp.uis.cam.ac.uk/
UAT	Content and design and user acceptance testing	https://webapp.uat.ap.gcp.uis.cam.ac.uk/	n/a	https://wpmapp.uat.ap.gcp.uis.cam.ac.uk/
Test	Manual testing before deployment to production and production-like environments	https://webapp.test.ap.gcp.uis.cam.ac.uk/	https://api.apps.cam.ac.uk/undergraduate-admissions-test/v1alpha1	https://wpmapp.test.ap.gcp.uis.cam.ac.uk/
Development	Development playground	https://webapp.devel.ap.gcp.uis.cam.ac.uk/	https://api.apps.cam.ac.uk/undergraduate-admissions-dev/v1alpha1	https://wpmapp.devel.ap.gcp.uis.cam.ac.uk/

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:

1. An EXTRA_SETTINGS_URL points to two environment-specific artefacts:

2. an apiapp-secret-settings secret in GCP Secret Manager

3. an apiapp-settings YAML config file in GCP Cloud Storage

4. Both are fetched by ap-backend on startup and their contents read to populate the load_settings FastAPI dependable.

5. The location of the applicant feed is now available as either

6. load_settings.applicants_source.camsis.url for a CamSIS feed.

7. 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

The Team responsible for this service is Digital Admissions Team.

The Tech Lead for this service is bs461.

The Service Owner for this service is hr244.

The Service Manager for this service is kb851.

The Product Manager for this service is bmd42.

The following engineers have operational experience with this service and are able to respond to support requests or incidents:

• pdh45
• amh254
• bw509
• jb2595
• pfk22