Skip to content

Unified DevOps Platform

This page explains why the Unified DevOps Platform is built the way it is. It covers how technologies are chosen, how teams are expected to adopt the Platform, what the division gets in return, and how we share our work with the wider University.

Adopting the platform

Technology selection

The technologies included in the Platform were selected based on:

  • Being used in multiple different applications currently operated by DevOps, and proven to be successfully deployed and operated at the scale expected by the University.
  • Where there is a high level of existing expertise in DevOps with the technology.
  • Where high-quality documentation or training material already exists for the technology.
  • Being MIT licensed or where the University has an existing commercial agreement with the provider (e.g. Google Cloud Platform).
  • Being actively maintained by an open-source community or commercial organisation.

Defining the Platform in this way does mean that DevOps is intentionally deprecating the use of other technologies currently in use across the estate. This allows the division to invest in solutions that are a part of the Platform and enhances the ability for shared learning and developer mobility across the division.

Incremental adoption

The Platform has been designed so that it can be incrementally adopted, as well as used for greenfield development. For example, existing Java-based web applications can, and currently do, make use of the Continuous Integration and Continuous Deployment solutions from the Platform, despite not making use of the Web App solution. It is not expected that all applications maintained by DevOps will move to the Platform at pace, but instead an approach of incremental adoption will be taken - introducing elements of the platform as architecturally significant changes are made to existing applications.

Use of other technologies

There is no desire to stifle innovation, or force teams in DevOps to use unsuitable technologies to solve unique problems. Team members in DevOps are encouraged to try new technologies and identify where a non-platform technology should be used to meet specific functional or non-functional requirements. In these cases the DevOps Technical Lead Forum will review and agree on the approach to take. Technologies or approaches that have proven value and ability for re-use may be added to the Platform with agreement from the Technical Lead Forum.

Benefits of the Platform

The Unified DevOps Platform is intended to both improve the efficiency of the division and enhance the culture and working environment.

Efficiency improvements:

  • The solutions provided under the Unified DevOps Platform for multi-user systems (Web Apps and Websites) will allow compliance with core aspects of the Systems Management Policy and related technical standards by default, avoiding the need for security mechanisms and protections to be built into systems individually. However, using the Unified DevOps Platform does not guarantee full compliance, as system-specific requirements like data retention sit outside the Platform.
  • The Platform includes a solution for deploying web applications into a production-ready environment in Google Cloud Platform, including all the necessary SecOps tools with automated scaling, budget protection, monitoring and alerting provided by default, again avoiding this tooling being introduced on a project-by-project basis.
  • The solutions provided under the Unified DevOps Platform are linked to template responses to the TDA Non Functional Requirements (NFRs), allowing teams to easily demonstrate how the NFRs have been met when using the Platform.
  • All elements of the Platform include an automated upgrade-path enabled by Renovate Bot, allowing improvements made at the boilerplate level to be rolled out to all applications quickly.

Working environment improvements:

  • By ensuring that all members of the division have some level of expertise with the Platform, we enhance developer mobility across the division, increasing the potential for shared learning and cross-team collaboration.
  • We can be very clear on the expected tech stack used when hiring, allowing the division to better target candidates with skills in technologies that are a part of the Platform.
  • When outsourcing work, we can require that agency or external staff use the Platform directly, or at least use Platform technologies, to ensure that teams are not asked to maintain code which has been outsourced for development and delivered in an unknown technology stack.

Sharing the platform with the wider University

We have created a uis/devops/platform group in GitLab. Projects in that group not only form part of the Unified DevOps Platform but also come with a commitment from ourselves that we will always keep the wider University in mind as an audience when creating things in that group.

To that end:

  • We should aim to move platform components into that group over time.
  • We should make use of shared platform components once we've moved them.
  • Projects in that group should be reusable by the wider University.
  • Projects in that group containing GitLab-related components should not require that projects be in the uis/devops group to be of use.
  • Projects in that group containing GitLab CI/CD components should not require the use of DevOps-specific runners to be of use.
  • Projects in that group containing Google Cloud-related components should not require that they be deployed into Google Projects managed by the Google Cloud Project Factory.