Skip to main content

User Workflows (CI/CD)


We use trunk base development in the Modernisation Platform, with all user application infrastructure stored in the modernisation-platform-environments repository.


There are as standard up to four different environments that can be used per application:

  • development
  • test
  • preproduction
  • production

In order to avoid having duplicate Terraform code for each environment, we use Terraform Workspaces. This allows us to store the Terraform state for each of those environments separately and deploy to the relevant environment by switching the workspace.

You can choose which environments you want for your application with multiple configurations possible.

Environment configurations

Deploying Infrastructure

For our CI/CD pipelines we use GitHub actions.

Workflow files are found here and are named after your application. They are generated as part of the initial environment set up workflow and based off of a template

Environment workflow:

Environment Workflow

We use GitHub Environments to create a manual approval gate before each deployment. This gives you chance to review the Terraform plan before approving the deployment. The GitHub environments are automatically created by the using your GitHub team as the reviewer, as part of the initial account creation process.

After approving, the infrastructure is deployed with the terraform apply command.


The code and AWS account is protected in a few different ways which work together to ensure that your AWS account is only modified by a member of your GitHub team or a Modernisation Platform engineer.


Your GitHub team will be assigned as a codeowner for your application folder, so someone in your team or the Modernisation Platform team will be required to review any pull requests before they can be merged. Members of your Github team will be able to approve a majority of pull requests. Approvals from the modernisation platform team members are only required in cases where a change might impact other customers or core platform components such as any files in the .github/ directory, as well as, and files in your application directory. For specific rules please see the CODEOWNERS file. For modernisation-platform-ami-builds you will need to add your team to CODEOWNERS when you add a team to the list. See the file for examples.

GitHub Environments

GitHub environments prevents any workflow being deployed to your environments unless it is approved by a member of your GitHub team.

AWS IAM (Identity and Access Management)

Each account has a MemberInfrastructureAccess IAM role that allows the GitHub workflows to create resources in each AWS account. Each application workflow will use the role for the relevant account, ensuring one account can’t create resources in another.

For modifying DNS entries, a dns-<business-unit>-<environment> role is used. It is only capable of changes to the DNS hosted zone for your particular business unit.

For creating certificates, a modify-dns-records role in the core-network-services account is used to create DNS validation records.


Service Control Policies (SCPs) prevent certain actions from running which may have a detrimental effect on the platform.

These are applied at a higher Organisational Unit (OU) level and are inherited by the application OUs.

Deploying Applications

Legacy applications often use “Click Ops” to make application deployments (manual configuration through the AWS console). Whilst this is still possible on the Modernisation Platform, we encourage and can help people to build application deployment pipelines.

To allow automated access to your AWS account we provide an “OIDC CI/CD (Continuous integration / continuous delivery)” role - modernisation-platform-oidc-cicd.

This role has restricted access to your AWS account, with the minimum permissions needed to do things like push a new image to an ECR repo.

The application pipeline is the responsibility of the application owner, details on using the role are detailed here


Member CI/CD

This page was last reviewed on 28 June 2024. It needs to be reviewed again on 28 December 2024 by the page owner #modernisation-platform .
This page was set to be reviewed before 28 December 2024 by the page owner #modernisation-platform. This might mean the content is out of date.