Regent House Ballots application¶
[Team | Jackson Team] [Tech Lead | TBC] [Service Owner | cb765] [Service Manager | ajc322] [Product Manager | TBC]
This page gives an overview of the Regent House ballots application, describing its current status, where and how it's developed and deployed, and who is responsible for maintaining it.
Service Description¶
The Regent House is a key governance body for the University. Membership of the Region House will vote in Ballots of the Regent House. These ballots cover a wide range of issues facing the Regent House.
The University out-sources the actual voting recording and tallying to an external third-party. All ballots have a list of eligible voters. For each voter on a particular ballot, the third-party provider gives the University a unique URL which the voter can use to vote on a ballot.
This web application presents a single shareable URL representing a ballot. When a University member visits that URL, they are authenticated and, should they be on the voter list for that ballot, they are redirected to their unique voting URL.
Additionally, this web application provides a management interface which allows administrators to create ballots, specify the times at which they open and close and upload a list of voters along with unique voter URLs.
Service Status¶
The Region House Ballots app is currently in early user testing.
Contact¶
Technical queries and support should be directed as per our contact page.
Issues discovered in the functionality of service or new feature requests should be opened as GitLab issues in the application project.
Issues discovered with deployment, e.g. mis-configured certificates, broken authentication, etc, should be opened as GitLab issues in the deployment project.
Environments¶
The Regent House Ballots application is currently deployed to the following environments with the following SAML metadata records:
Notification channel(s) for environments¶
| Environment | Display name | |
|---|---|---|
| Production | Regent House Ballots - Jackson DevOps team email channel | devops-jackson@uis.cam.ac.uk |
Source code¶
The source code for the Regent House Ballots application is spread over the following repositories:
| Repository | Description |
|---|---|
| Web application | Django-based web application |
| Infrastructure | Terraform-based deployment |
These repositories are configured in the GitLab project factory.
Technologies used¶
The following gives an overview of the technologies the Regent House Ballots application is built on.
| Category | Language | Framework(s) |
|---|---|---|
| Web application | Python | Django |
| Deployment | Terraform | Google Cloud Platform |
Special note should be taken that this application uses Raven SAML 2.0 for authentication. Post-deployment configuration steps are documented in the deployment project's README.
Operational documentation¶
The following gives an overview of how the Regent House Ballots application is deployed and maintained.
Users' guide¶
The users' guide for the application is maintained in a Google doc and is published to a public website which is linked to from the application itself. This link may be customised in the terraform configuration.
Access control¶
Access control in the application is keyed by Lookup group membership. This is configured in the deployment project.
IMPORTANT The membership of the uis-regent-house-ballot-{...} groups must be "University" or "World" in order for Raven SAML 2 to pass membership information to the application.
In development, any member of uis-regent-house-ballot-superadmins has both staff and superuser status.
In production and staging, members of uis-regent-house-ballot-superadmins have both staff and superuser status. Members of uis-regent-house-ballot-administrators have staff and ballot manager status.
In production and staging, it is envisaged that technical support staff will be members of uis-regent-house-ballot-superadmins while "normal" ballot administrators will be members of uis-regent-house-ballot-administrators.
How and where the Regent House Ballots application is deployed¶
Deployment is via our standard terraform deployment CI pipeline.
Deploying a new release¶
Making a new release of the application is done via release automation. In short: merged commits are collected together into a draft "next release" Merge Request. When merged, a new release tag is pushed to the repository along with a Docker image being pushed to Google's Artefact registry.
Deployment is done by:
- Updating the deployment project's repository with any changes, including bumping the deployed web application release.
- Using the "play" buttons in the CI pipeline to deploy to production when happy. (Deployments to
staging happen automatically on merges to
main.)
Monitoring¶
Monitoring is configured as per our standard Google Cloud Run application module.
Service Management¶
The Team responsible for this service is Jackson Team.
The Tech Lead for this service is TBC.
The Service Owner for this service is cb765.
The Service Manager for this service is ajc322.
The Product Manager for this service is TBC.
The following engineers have operational experience with this service and are able to respond to support requests or incidents:
Contacts at the University's voting provider are included in the infrastructure project's README.