Back to Flutter Inner Source homepage
inner source

Multiple Teams SDLC

This software development lifecycle is optimised for a service with multiple teams contributing to it concurrently.

Overview

The branching model used in this SDLC is a derivative of GitFlow with each team having their own <team>/develop branch. The complexity of this model is only worthwhile when multiple teams are working on the same service concurrently. The Service SDLC provides similar features with a simpler branching model if a single primary team exists that just needs to accept external contributions.

Alpha, beta or production-ready builds are signalled by git tags which conform to our semantic versioning conventions. For example:

Development

The key concept in this SDLC is that each team with its own deployment has its own <team>/develop branch. The team follows its own development process around their <team>/develop branch, typically using short-lived feature branches like <team>/feature/xxx for each change.

Releases

Work from all the <team>/develop branches is integrated into a single production branch (main or master) through team major/minor releases. Only one major/minor release can occur at any time. The release changes are synchronised back into all <team>/develop branches before the next release.

The diagram shows an example release:

  1. The Porto (opo) team starts a release by creating the opo/release/v1.4 branch from their current opo/develop branch. They tag this branch as v1.4.0-opo.beta.0 which triggers a deployable beta build for QA.
  2. Beta testing results in 2 minor bug fixes that are committed to the release branch (or merged from a reviewed PR). After each the release branch is tagged to create an updated beta build.
  3. The release branch opo/release/v1.4 is merged into the main production branch via a PR and tagged as v1.4.0 to denote the final production build.
  4. The Leeds team are aware of the Porto release and may be actively involved, but can also continue unaffected in their lds/develop branch. Because 1.4 is now an active beta release, they increment their next alpha tag version to indicate the changes are now targeted at the 1.5 release.
  5. Once the Porto team have completed the v1.4.0 release by merging the changes into main, the Leeds team synchronise their develop branch by merging the changes from main back into their own lds/develop branch.
  6. The Porto team also synchronise their develop branch by merging the changes from main back into their own opo/develop branch.

Hotfixing

A hotfix is a change correcting a fault that needs to be released as quickly as possible (often under incident conditions). Hotfixes can be applied at any time as patch releases via a /hotfix/<name> branch which is merged directly into the production branch.

This diagram shows an example hotfix. A performance regression is detected on Friday by the Porto team in the latest v1.4.0 release which is expected to cause capacity problems on Saturday. They take the operational decision to fix forward:

  1. The /hotfix/sat-capacity hotfix branch is created.
  2. A mitigating fix is committed. This is tagged as v1.4.1-opo.beta.0 to allow beta testing and verification.
  3. The hotfix is merged (via reviewed PR) back into main and tagged as a patch release v1.4.1.
  4. Like a major/minor release, the Porto team will synchronise their opo/develop branch with main to integrate the hotfix.
  5. The Leeds team will also synchronise their lds/develop branch to integrate the hotfix. They may not do this immediately but must do this before starting their next release.

Hotfixes can be applied during a major/minor release. In such cases the relevant release branch must also be synchronised with main to ensure the hotfix is included during beta testing.

Support

This SDLC expects each team to own and manage their own deployment(s). The deployment process itself will vary by team based on their tools, infrastructure and desired topology. This SDLC simply promotes the use of semver tags to signal that a build should be created and made available for all teams for deployment if desired.

Not all teams will have the same version deployed. Older versions should not be the target of new features, but must be supported until a team has migrated to the latest release. To support older versions hotfixes can be applied to any previous version on a /support/<version> branch.

This diagram shows an example support hotfix. The Leeds team realises that the performance regression detected by the Porto team is also present in their currently deployed v1.2.2 service. As a precaution they decide to also apply the fix but are not yet ready to upgrade to the latest v1.4.1 version that includes it. So they apply a support hotfix:

  1. A support/v1.2 branch is created from the latest v1.2.x release tag (v1.2.2). This is the long-running support branch and will be used for all further v1.2.x releases.
  2. The /hotfix/sat-capacity-backport hotfix branch is created, and the mitigating commit is applied. This is tagged as v1.2.3-lds.beta.0 to allow beta testing and verification.
  3. The hotfix is merged (via reviewed PR) back into support/v1.2 and tagged as a patch release v1.2.3 which the Leeds team can now deploy to update their older version with an isolated fix.

Setup

This SDLC is setup using the git flutter init command. At this early point in its wider adoption the Inner Source Team are providing direct support for setup so please get in touch and we will go through the available options and help you get started.

git flutter Examples

This SDLC is supported by the git flutter CLI tool. Using this tool helps prevent common mistakes like starting concurrent releases and saves you time by shortening common commands in this workflow.

Starting a Feature

Two teams (opo and lds) are working with the multiple teams SDLC. As an engineer in the Leeds (lds) team I want to start a new feature. I use the feature command to create a new branch for my work, with my team automatically detected from my current branch. Once I've finished my feature I'll raise a pull request to merge it into my team development branch (lds/develop).

$ git flutter feature my-new-thing --yes
Creates a feature branch named 'lds/feature/my-new-thing' from the source branch 'lds/develop' and pushes it to remote

i Creating branch 'lds/feature/my-new-thing'

✔ The 'lds/feature/my-new-thing' branch was pushed to remote

✔ The feature branch 'lds/feature/my-new-thing' was successfully created

Develop Branches Ahead

Two teams (opo and lds) are working with the multiple teams SDLC. Engineers from both teams have now merged several features into their develop branches which are not yet released. As a member of the Leeds team I want to release our work. I use the status command to see the latest release tag on main, the state of all team development branches and whether any team has an existing release in progress.

$ git flutter status
lds/feature/my-new-thing

main
  i v1.3.2

opo/develop
  i v1.4.0-opo.alpha.3
  i 3 ahead of main

lds/develop
  i v1.4.0-lds.alpha.5
  i 5 ahead of main

Start a Release

Two teams (opo and lds) are working with the multiple teams SDLC. Engineers from both teams have now merged several features into their develop branches. As a member of the Leeds team I want to release our work so use the release command to start a release.

$ git flutter release 1.4 --yes
Creates a release branch named 'lds/release/1.4' from the current team develop branch 'lds/develop', and pushes it to remote

i Creating branch 'lds/release/1.4'

✔ The 'lds/release/1.4' branch was pushed to remote

✔ The release branch 'lds/release/1.4' was successfully created

You can now raise a PR to merge the release into main, or use 'git flutter tag' to create a beta build.

Tag a Beta Build

Two teams (opo and lds) are working with the multiple teams SDLC.As a member of the Leeds team I have started a release and want to create a beta build to deploy to our staging environment. I use the tag command to specify a semver tag on the release branch to trigger a CI build.

$ git flutter tag 1.4.0-lds.beta.0 --push --yes
An ERROR occurred:

✘ unknown flag: --push

Command help is available using the --help flag.
Support is available in Slack channel #inner-source.

Concurrent Releases Prevented

Two teams (opo and lds) are working with the multiple teams SDLC. The Leeds (lds) team have a release in progress so as a member of the Porto team I am prevented from starting another release until the Leeds release is completed or cancelled.

$ git flutter release a-named-release --yes
An ERROR occurred:

✘ there is 1 active release(s): 'lds/release/1.4'

Command help is available using the --help flag.
Support is available in Slack channel #inner-source.

Check Release Status (in-progress)

Two teams (opo and lds) are working with the multiple teams SDLC.As a member of the Porto team I want to release so I use the status command to check whether any other team has a release in progress. I see that the Leeds team are currently releasing so know to check with them when they will have completed as only one major/minor release can occur at any time.

$ git flutter status
main (current)
  i v1.3.2



opo/develop
  i v1.4.0-opo.alpha.3
  i 3 ahead of main

lds/develop
  i v1.4.0-lds.alpha.5
  i 5 ahead of main

lds/release/1.4
  i HEAD would be v1.4.0-lds.beta.5 (inferred)
  i 5 ahead of main

Start Latest Version Hotfix

Two teams (opo and lds) are working with the multiple teams SDLC.The Leeds team are testing a new minor release, but the Porto team need to publish an emergency fix for a production incident. As an engineer in the Porto team I use the hotfix command to start a hotfix.

$ git flutter hotfix perf-fix --yes
i Updating from origin
Creates a hotfix branch named 'hotfix/perf-fix' from the source branch 'main' and pushes it to remote

i Creating branch 'hotfix/perf-fix'

✔ The 'hotfix/perf-fix' branch was pushed to remote

✔ The hotfix branch 'hotfix/perf-fix' was successfully created

Check Release Status (merged)

Two teams (opo and lds) are working with the multiple teams SDLC.As a member of the Porto team I want to release so I use the status command to check whether any other team has a release in progress. Now the Leeds release has been merged into main I can see no release is in progress so I can start the next one myself.

$ git flutter status
main (current)
  i v1.4.0



opo/develop
  i v1.4.0-opo.alpha.3
  ! 6 behind and 3 ahead of main

lds/develop
  i v1.4.0-lds.alpha.5
  ! 1 behind main

Tag a Production Release

Two teams (opo and lds) are working with the multiple teams SDLC.As a member of the Leeds team I have completed testing the beta builds and merged the release branch into main to complete the release. I now use the tag command to increment a minor version tag to trigger a production build.

$ git flutter tag minor --push --yes
An ERROR occurred:

✘ unknown flag: --push

Command help is available using the --help flag.
Support is available in Slack channel #inner-source.

Sync a Develop Branch

Two teams (opo and lds) are working with the multiple teams SDLC.The Leeds team have just completed a release and merged it to main. As an engineer in the Porto team I need to sync the release back into my team develop branch to integrate the changes.

$ git flutter sync --force --yes
Merges the branch 'main' into branch 'opo/develop' and pushes it to remote


i Merging branches
i Pushing branch to origin

✔ Merged and pushed, all now up to date
Standard SDLCs
← Previous
Install Git Flutter