The Flutter-Global GitHub organisation is open to all Flutter employees. Its purpose is to help you collaborate technically with others across the entire Flutter group. These docs describe how to use it.
Our inner source portfolio is contained in the Flutter-Global GitHub organisation. GitHub recommends a flat single-org repository structure like this for inner source to simplify access control and team management. If you need information about divisional organisations see the support page.
Flutter-Global has thousands of repositories and GitHub does not have any in-built way to group or link them (e.g. like ‘projects’ in GitLab or Atlassian BitBucket) so the structure is not obvious in the GitHub user interface. You may already know a specific repository you need from colleagues or a work brief so can skip forward to start using that repo.
Alternatively you can browse the available applications in our internal service catalogue. These are organised into capabilities.
- A capability is a group of related repositories that does something meaningful (e.g. a product feature).
- Each GitHub repository is owned by a single capability.
- A capability has a named owner, and a single team of expert maintainers.
- Not all repositories in Flutter-Global are part of a capability, but it is a requirement of using the codebase governor.
Access & Branching
Your source code is stored in a repository within the
Flutter-Global organisation. The standard branching patterns are:
Ensures history is immutable and can be audited, but does not require changes to be pre-approved before release.
- Protected History
- Trunk-Based Development
Simple pull request based workflow where all changes are reviewed by expert code maintainers before release.
- Protected Code
- Simple "GitHub Flow"
- SemVer Support
Multiple Team Source
A derivative of GitFlow to provide each team with their own develop branch.
- Protected Code
- Flexible GitFlow Releases
- SemVer Support
Recommended branching model patterns explained in under 7 minutes!
Each pattern documents a default inner source contributor setup:
Internal repository visibility with all members of
Flutter-Global treated as contributors. This can be customised to use:
Requested Access requires you to maintain your own access request process. This can be effective when coupled with an automated team maintenance process or small contributor group. You will use [Codebase Governor] to configure contributor access for your custom contributor team instead of the
Closed Source requires the repository to be switched to
Private visibility to prevent any default read access. This is for sensitive content only. To change repository visibility you will need to contact the Inner Source Team. This access model usually also requires use of your own requested access process.
Inner Source CI
GitHub Action Workflows
Use GitHub Action Workflows to validate any proposed code change. This provides fast, automated and transparent feedback to the contributor.
SemVer Git Tags
Use SemVer git tags to trigger the CI pipeline. This is a concise, familar way to communicate release risk to your users.
An inner source application will typically have a single shared codebase and several deployments. A change will follow these steps to production:
- Source: A code edit is applied to a
Flutter-Globalrepository with access controls and a branching strategy: audited source, reviewed source or multiple teams source.
- Validate: Check proposed code changes by running a series of tests that must pass: use GitHub Actions for this.
- Package: Resolve any external dependencies to build a new version of the desired deployment package(s) e.g. binaries, docker, rpm, jar. You might need self-hosted runners if a build requires internal network access.
- Component Tests: Run available tests against the candidate deployment package with other dependent mocked packages: see this description of test types.
- Publish: Publish the tested deployment package to a registry so it is available to the system that needs to deploy it.
- Deploy: Configure the package and deploy it to a specific topology (e.g. AWS, on-prem VM, k8s).
- Integration Tests: Run available integration and non-functional checks.
- Release: Promote the deployment through the required environments to rollout to production traffic.
- Observe: Observe the release with heightened operational awareness to confirm success, with rollback invoked on suspicion of failure.
The standard patterns documented cover steps (1)-(5). For an inner source application step (6) onwards is regarded as team/division specific and dependent on local requirements.