Teads-Managed-Services-Workflow.md

Teads Managed Services 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_SWAT-3456_mybugfix master
$ git checkout master
$ git merge --no-ff hotfix_SWAT-3456_mybugfix
$ git checkout develop
$ git merge --no-ff hotfix_SWAT-3456_mybugfix
$ git checkout release_1.2
$ git merge --no-ff hotfix_SWAT-3456_mybugfix
$ git branch -d hotfix_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

About GRebaase

• Delphine is in charge of merges
• We need to know when to rebase our branches (please check regularely)

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

bon comme j'arrive pas à te faire une PR pour un Gist (première fois que j'utilise ça ^^)
modifier :

hotfix_EBZS-3456_mybugfix
par
hotfix_1.1_SWAT-3456_mybugfix

et puis peut être ajouter en proposition tout à la fin :

• mettre régulièrement à jour sa branche hotfix / feature par rapport à la branche parent pour éviter les conflits de dernière minutes et des tests non faussé (cf GRebase)

👍 👡

forker sur son propre compte?

non car deploy et QA

moins de commit par mep => aller vers le deploiement continue
mep swat plus fréquentes?
releases branches plus fréquentes

peut etre dissocier front back et api mais

• contraintes versions différentes
• complexe a mettre en place

Idée à étudier: scripts customs au client près

merger les FB testées sur develop plus rapidement

les PO et QA "débordés" 🍼 => met 1 à 2 semaines

release branch qui ne dure que quelques jours

tests auto sur release branch 🚕 mais surtout on la crée tard : on finit le sprint, on attend que tous les tickets soient mergés puis QA puis merge

=> cf problème d'avant, pas de prob avec la release branch

moins de hotfix et plus de features

peut etre plusieurs de mep par sprint?

note de julien

• base de données et deploiement
• deploiement sans coupure
• release indépendantes de chaque projet
• découpage des projets

release master qui tourne?
quelles limites au fait que delphine gere les merges