Bernard explains the use of a deployment repository to separate shared application code from the infrastructure code for a specific deployment (7 mins):
Example
If you are a Flutter staff member and part of Flutter-Global
, you can access examples of this pattern on our internal developers site.
Why?
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.
How?
- 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
in:
tags: Branching Video
category: Story