This software development lifecycle is optimised for a service with multiple teams contributing to it concurrently.
developbranch with cross-team synchronisation during regular releases.
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:
v1.3.3is the latest production release. The last team feature release was
v1.3.0since which there have been 3 hotfixes.
v1.4.0-opo.beta.2is the next release driven by the
opoteam. Since the initial release build there have probably been 2 minor bugfixes.
v1.5.0-lds.alpha.3is the alpha version in the
lds/developbranch that is deployed to one of the Leeds team QA environments with 3 unreleased changes.
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.
alphareleases from their
<team>/developbranch for their local QA environment(s). In this way they can treat their
<team>/developbranch like an environment branch.
developbranches similar to their own feature branches: a set of changes that need awareness and timely review but don’t yet directly impact.
fd/developfor PPB and FanDuel teams. But the number of develop branches and the names used for teams depends on your context and do not need to relate to divisions.
Work from all the
<team>/develop branches is integrated into a single production branch (
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:
opo) team starts a release by creating the
opo/release/v1.4branch from their current
opo/developbranch. They tag this branch as
v1.4.0-opo.beta.0which triggers a deployable beta build for QA.
opo/release/v1.4is merged into the
mainproduction branch via a PR and tagged as
v1.4.0to denote the final production build.
1.4is now an active beta release, they increment their next alpha tag version to indicate the changes are now targeted at the
v1.4.0release by merging the changes into
main, the Leeds team synchronise their develop branch by merging the changes from main back into their own
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:
/hotfix/sat-capacityhotfix branch is created.
v1.4.1-opo.beta.0to allow beta testing and verification.
mainand tagged as a patch release
mainto integrate the hotfix.
lds/developbranch 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.
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
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:
support/v1.2branch is created from the latest
v1.2.xrelease tag (
v1.2.2). This is the long-running support branch and will be used for all further
/hotfix/sat-capacity-backporthotfix branch is created, and the mitigating commit is applied. This is tagged as
v1.2.3-lds.beta.0to allow beta testing and verification.
support/v1.2and tagged as a patch release
v1.2.3which the Leeds team can now deploy to update their older version with an isolated fix.
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.
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.
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
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
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.
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.
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.
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
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
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
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.
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