UCL Research Data Information Security Management System GitOps Procedure #
Document Name: RISM18-GitOps_Procedure
Classification: Public
Author: George Svarovsky
version: 1.1
Last Review: 10/04/2025
Last Reviewed by: Jack Hindley
Approved by: OMG
Approved date: 12/03/2025
Review Period: 3 years
1. Document Overview #
This document describes the procedure for managing [operational] change according to RISM08-Change_Management_Policy by using git repositories ("GitOps" i.e. git operations).
2. Scope #
This procedure applies to all changes to documented information, systems, applications, and infrastructure managed via GitOps practices across the Research Data Information Security Management System’s Environments, including production and pre-production systems.
3. Procedure #
Git repositories using GitOps for change management shall be cloned to GitHub under a suitable organisation managed by UCL.
Access controls shall be enforced on GitHub repositories, ensuring only authorised personnel can make or approve changes to production systems.
Change Requests are realised as follows.
3.1 Issues #
All changes shall be initiated from a GitHub Issue representing the Purpose of the request for change.
- A Standard Change is labelled as
change-type:standard. - A Emergency Change is labelled as
change-type:emergency. - A Normal Change requires no specific label.
3.2 Branch Protection Settings #
The default branch and any dedicated production deployment branch shall be set to:
- Require a Pull Request before merging
- Require at least 1 Approval
- Dismiss stale Pull Request Approvals when new commits are pushed
3.3 Pull Requests #
If an Issue gives rise to a change, a git branch shall be created for the changed repository content. The branch shall be pushed to the GitHub repository, and a Pull Request created. The change control inclusions required by RISM08 shall be realised in a Pull Request as follows:
| Required Inclusion | Realisation |
|---|---|
| Purpose | The Issue, referenced by its GitHub Issue number in the Pull Request description. |
| Scope | The Pull Request content (Files tab) precisely defining the difference to be applied. |
| Impact | Only included if the impact is HIGH (see following section). |
| Risk assessment | Included or referenced in the Pull Request description. |
| Schedule | If applicable, included or referenced in the Pull Request description. |
| Test plan | The Pull Request content should include any related tests, scheduled according to test setup. |
| Communication plan | Included or referenced in the Pull Request description. |
| Contingency/Rollback plans | Unless otherwise included in the Pull Request description, rollback is by git revert and re-deployment. |
| Authorisation | The Approvers of the Pull Request. |
3.4 Impact and Approvers #
Impact shall be assessed as either:
- HIGH: The change could critically affect service components or the overall service quality. The Pull Request Approvers must include the Environment Owner; their approval shall be accompanied by a comment, which shall record, as appropriate, the considered input of other parties such as a supporting service owner, information governance advisory or the information security group.
- Otherwise, the impact is not high, and the change may be approved by any Environment Developer.
Changes affecting levels of risk shall be assessed in line with RISM04 Risk Assessment and Treatment Procedure and escalated to the Operational Management Group where appropriate.
Emergency changes should be retrospectively reviewed and approved by the Environment Owner.
3.5 Testing and Validation #
- Normal changes shall be tested in a pre-production environment before deployment.
- Emergency changes should be tested in a pre-production environment before deployment where appropriate.
- Live data shall not be used during testing or in non-production environments.
- Automated testing (e.g. unit tests, integration tests) shall be used to validate changes.
- For security-related changes, vulnerability assessments and penetration testing may be required.