SlideShare a Scribd company logo
1 of 10
Besturing 3.0 – B@M
AMQ
Automatic Merge Queue
Corstiaan Kamp
AMQ - Waarom
• 4 scrum teams die op hetzelfde tijdstip
spullen naar master willen brengen
• Tijdsdruk/groepsdruk voor degene die op
vrijdag de release gaat maken.
• Menselijke fouten waardoor master rood
wordt
• Tijd verlies
Besturing 3.0
AMQ - Doel
• Ontwikkel proces versnellen
• Origin/Master altijd releasebaar houden
• Verminderen menselijke fouten
Besturing 3.0
AMQ – Werkwijze pre AMQ
Besturing 3.0
AMQ – pre AMQ - regeltjes
Besturing 3.0
• Voor mergen eerst op de master rebasen. Voorbeeld:
    git rebase origin/master of git rebase origin/master_R3​
Hierdoor worden alle changes die op de master stonden onder de branch geschoven.
• Na rebasen een groene teampipe krijgen; daarvoor is het nodig om de changes op de origin van de
branche te krijgen.
Om de changes op de origin van de branch te krijgen, moet het volgende command worden uitgevoerd:
PAS OP! Dit commando herschrijft de git-historie. Doe dit commano nooit op de master, maar alleen op
een branch! Overleg bij twijfel met een integrator
    git push origin <BRANCHNAAM HIER> --force
Coordineer dit onderling, als nog meer mensen op de branch werken; zij zullen na deze actie moeten
pullen
• Als de teampipe groen is, dan kan in principe de branch gemerged worden naar de master. Om het
terugdraaien van merges te vereenvoudigen dient er ten alle tijden een “merge commit” te worden
gemaakt. Doe dit als volgt:
    git checkout master
    git merge --no-ff <BRANCHNAAM HIER> 
Uit deze merge zouden geen conflicts mogen komen. Als dat toch gebeurt, is iemand er tussendoor
gekomen met terugmergen naar de master, of heeft iemand direkt op de master gepusht.
• Push naar de master
AMQ - AMQ
Besturing 3.0
• Alleen via AMQ naar master
• Master altijd groen
• Geen lijstjes meer bijhouden wie mag
mergen
AMQ – Jenkins
Besturing 3.0
AMQ – no silver bullet
Besturing 3.0
AMQ – happy developers
Besturing 3.0

More Related Content

More from jstack (8)

Ignite docker
Ignite dockerIgnite docker
Ignite docker
 
Git branching strategies
Git branching strategiesGit branching strategies
Git branching strategies
 
Ionic
IonicIonic
Ionic
 
Gradle
GradleGradle
Gradle
 
Flyway - database migrations made easy
Flyway - database migrations made easyFlyway - database migrations made easy
Flyway - database migrations made easy
 
Domain driven design
Domain driven designDomain driven design
Domain driven design
 
Ignite es6
Ignite es6Ignite es6
Ignite es6
 
Software development terminology
Software development terminologySoftware development terminology
Software development terminology
 

Auto Merge Queue

  • 1.
  • 2. Besturing 3.0 – B@M AMQ Automatic Merge Queue Corstiaan Kamp
  • 3. AMQ - Waarom • 4 scrum teams die op hetzelfde tijdstip spullen naar master willen brengen • Tijdsdruk/groepsdruk voor degene die op vrijdag de release gaat maken. • Menselijke fouten waardoor master rood wordt • Tijd verlies Besturing 3.0
  • 4. AMQ - Doel • Ontwikkel proces versnellen • Origin/Master altijd releasebaar houden • Verminderen menselijke fouten Besturing 3.0
  • 5. AMQ – Werkwijze pre AMQ Besturing 3.0
  • 6. AMQ – pre AMQ - regeltjes Besturing 3.0 • Voor mergen eerst op de master rebasen. Voorbeeld:     git rebase origin/master of git rebase origin/master_R3​ Hierdoor worden alle changes die op de master stonden onder de branch geschoven. • Na rebasen een groene teampipe krijgen; daarvoor is het nodig om de changes op de origin van de branche te krijgen. Om de changes op de origin van de branch te krijgen, moet het volgende command worden uitgevoerd: PAS OP! Dit commando herschrijft de git-historie. Doe dit commano nooit op de master, maar alleen op een branch! Overleg bij twijfel met een integrator     git push origin <BRANCHNAAM HIER> --force Coordineer dit onderling, als nog meer mensen op de branch werken; zij zullen na deze actie moeten pullen • Als de teampipe groen is, dan kan in principe de branch gemerged worden naar de master. Om het terugdraaien van merges te vereenvoudigen dient er ten alle tijden een “merge commit” te worden gemaakt. Doe dit als volgt:     git checkout master     git merge --no-ff <BRANCHNAAM HIER>  Uit deze merge zouden geen conflicts mogen komen. Als dat toch gebeurt, is iemand er tussendoor gekomen met terugmergen naar de master, of heeft iemand direkt op de master gepusht. • Push naar de master
  • 7. AMQ - AMQ Besturing 3.0 • Alleen via AMQ naar master • Master altijd groen • Geen lijstjes meer bijhouden wie mag mergen
  • 9. AMQ – no silver bullet Besturing 3.0
  • 10. AMQ – happy developers Besturing 3.0

Editor's Notes

  1. Zo min mogelijk paaltjes in het project. Met zijn allen hetzelfde doel nastreven en geen sub optimalisatie. Bijvoorbeeld zeer efficiënte technische realisatie en moeizame implementatie.