Teads-manage-services-workflow.md

Teads manage services git workflow

The straight Git flow

The main branches

• master
• develop

Types of branches

• Feature branches
• Release branches
• Hotfix branches

Feature branches

• May branch off from: develop
• Must merge back into: develop
• Branch naming convention: feature_EBZS-XXX_description

$ git checkout -b myfeature develop
...
$ git checkout develop
$ git merge --no-ff myfeature
$ git branch -d myfeature
$ git push origin develop

Release branches

• May branch off from: develop
• Must merge back into: develop and master
• Branch naming convention: release_version

$ git checkout -b release_1.2 develop
...
$ git checkout master
$ git merge --no-ff release_1.2
$ git branch -d release_1.2

Hotfix branches

• May branch off from: master
• Must merge back into: develop and master, and possibly the release branch
• Branch naming convention: hotfix_version_SWAT-XXX_description

$ git checkout -b hotfix_1.1_SWAT-3456_mybugfix master
$ git checkout master
$ git merge --no-ff hotfix_1.1_SWAT-3456_mybugfix
$ git checkout develop
$ git merge --no-ff hotfix_1.1_SWAT-3456_mybugfix
$ git checkout release_1.2
$ git merge --no-ff hotfix_1.1_SWAT-3456_mybugfix
$ git branch -d hotfix_1.1_SWAT-3456_mybugfix

Teads manage services gitflow

Useful links

• Dev Workflow on confluence
• Branches on confluence

How it differs from gitflow

• all branches in the main repo, no developer's repositories
• merge of master into develop and into the release branch
• The release branch stays alive for long periods of time

Why it differs

• Our test coverage is very low and our applications are unstable
• We have a lot of hot fixes, and we have even urgent features developed on hotfix branches / master
• Our releases are tedious and incertain so we push to production many commits at once

So if we do a straight Giflow, it will result in

• Many more conflicts to resolve (HFB to master, HFB to release, HFB to develop)
• Many useless merge commits

Propositions

• forker sur son propre compte?
• moins de commit par mep => aller vers le deploiement continue
• mep swat plus fréquentes?
• releases branches plus fréquentes
• merger les FB testées sur develop plus rapidement
• moins de hotfix et plus de features
• tests auto sur les FB
• tests auto d'intégration pour une release branch qui ne dure que quelques jours
• mettre régulièrement à jour sa branche hotfix / feature par rapport à la branche parent pour éviter les conflits de dernière minutes (cf GRebase)