Deployment Repository

by: Rob Tuley

Bernard explains the use of a deployment repository to separate shared application code from the infrastructure code for a specific deployment (7 mins):


If you are a Flutter staff member and part of Flutter-Global, you can access examples of this pattern on our internal developers site.


A team responsible for building and running an application will manage 2 types of code:

  • Application code: the business logic and implementation of the service (e.g. Java, Javascript, C#).
  • Infrastructure code: the deployment topology and configuration (e.g. Terraform, Helm charts, AWS CDK).

When a single team manage both (DevOps culture), they will typically keep both in a single repository (example) because:

  • Atomic changes are possible across both application and infrastructure.
  • The same build, test and deploy pipeline is used for both application and infrastructure changes which reduces mistakes.

For an inner source application the situation is more complex:

  • Multiple deployments of the same shared application code to different topologies, so multiple sets of infrastructure code.
  • Infrastructure code is owned and maintained by the just team responsible for that deployment, a subset of the application code contributors.

These factors often mean that the application code and infrastructure code are kept in separate repositories. We call the infrastructure code repository a deployment repository.


  • The application code is stored in a GitHub repository in the Flutter-Global organisation where engineers from any division can contribute.
  • Build, test, scan and packaging CI jobs are defined in the application code repository and executed on Flutter-Global GitHub Action runners. This allows anyone who contributes to fully validate their work.
  • The application code release package(s) are published to Flutter-Global GitHub Packages and labeled using semantic versions. This allows any division to deploy these release packages.
  • The deployment repository is a GitHub repository in the divisional organisation which is integrated with the divisional deployment infrastructure. It references the desired release version.
  • The divisional CI/CD pipeline is a divisional technology choice and pulls and scans the release packages from Flutter-Global GitHub Packages. This pipeline then completes the deployment to the divisional infrastructure.

The division treats Flutter-Global application code or packages as a dependency in a similar way it would treat other open source dependencies.

by: Rob Tuley
tags: Branching Video
category: Story